You can reprogram it 100.000 times.byemu wrote:Is this cartridge can only programming 10 times?
- For making cartridges of your Super NES games, see Reproduction.
But when I write flash command to my gameboy np cart,and always return 0xcd,sanni wrote:You can reprogram it 100.000 times.byemu wrote:Is this cartridge can only programming 10 times?
only flash id command return normal data : C2 89 00 , others always return cd cd cd...
I suggest you review BennVenn's posts along with my posts in response in this thread where we worked out of the GB flash commands.
To access the flash you need to use the NP commands. To read the flash ID, use what BennVenn numbered Function 1 (F1) and Function 2 (F2).
Code: Select all
Function 1:  <- 0F  <- Address Hi  <- Address Lo  <- Databyte [013F] <- A5 Function 2:  <- 09  <- AA  <- 55 [013F] <- A5
Use those two functions in the following manner.
Code: Select all
The standard flash command 0x90 can retrieve the flash ID C2/89: F2 F1: 5555, AA F1: 2AAA, 55 F1: 5555, 90
Over a year ago, I bought several 29F1601MC chips off a vendor on AliExpress (unfortunately the vendor no longer lists the part). The chips were used as part of my experiments that unlocked the hidden page that holds the mapping used by the NP carts. I always intended on soldering a chip to the PCB to increase the capacity to 6MB (48Mbit) but I never found the time to do it. I managed to find some time to work on it over the last couple weekends.
I programmed the new 3rd chip with some test patterns and soldered it (and a decoupling cap) to a SHVC-MMS-02 board. I ran tests trying to locate the flash but I could not find the test data anywhere. I thought that the 3rd flash might map to bank 0x40 like an ExHiROM but that didn't work. I ran extensive searches modifying elements of the NP commands to see if anything would map the 3rd chip but none of the changes made any difference in mapping the chip.
Since I hit a dead end software wise, I looked at sanni's SF Memory schematic and saw that there are a couple pins on the MX15001TFC that can be configured as pullup or pulldown. The MX15001 pins are Pin 38 and Pin 97 with both configured to pullup using R11 and R9, respectively.
I decided to test Pin 97 as a pulldown and moved the 10K resistor from R9 to R10. With R10 pulling Pin 97 down, the contents of the 3rd chip are now visible. The contents of the chip are interleaved with alternating bytes between the 1st MB and the 2nd MB. The chip appears to map at bank 0xA0 with a mirror at bank 0x20. Portions of the data also appear in banks 0x00 and 0x80. A side effect of the change is that the contents of the 1st (0xC0) and 2nd chip (0xE0) are no longer recognizable. Interestingly, the hidden mapping for both chips (0xC0 and 0xE0) still read out properly so that confirms where they sit. It appears that the game data written to the flash chips will need be modified in order to work in 6MB (48Mbit) mode.
After testing Pin 97, I decided to test Pin 38 and moved R11 to R12. The flash contents didn't seem to be affected. I'm not sure but I think it might be related to the SRAM? I'll be moving the resistor back to the original pullup configuration since it didn't appear to make a difference with the flash.
More testing to do...
EDIT: The flash chip data seems to be read 0xA0, 0xC0, 0xE0 when mapping to HiROM.
Can you explain the interleave a bit more detailed? Do you mean something like this...
SNES address A08000h = Chip3, offset 000000h
SNES address A08001h = Chip3, offset 100000h
SNES address A08002h = Chip3, offset 000001h
SNES address A08003h = Chip3, offset 100000h
If it's mapped in bank A0h..BFh, with 8000h bytes/bank, then you still get only 1Mbyte (half of the 2Mbyte chip) mapped, right?
And what happened at bank C0h...E0h...FFh? Is there still any data in there... from chip1/chip2?
The default mapping (without HIROM:ALL mode) for bank 00h might be also interesting, just to confirm that the cart can still load the boot menu after swapping the pin97 resistor. Which, you could simply test that by booting the cart in SNES, and check if it's displaying the menu... and also check if it's still allowing to play the games from chip1/chip2.
After moving the resistor on Pin 97, the contents of the chip appeared when dumping using the HIROM:ALL mode. The data showed up in Banks 0x00, 0x20, 0x80, 0xA0. The data showed up as 0x55, 0xAA, 0x55, 0xAA and so on followed by the ascending and descending bytes also interleaved. To use your example:
SNES address A00000h = Chip3, offset 000000h
SNES address A00001h = Chip3, offset 100000h
SNES address A00002h = Chip3, offset 000001h
SNES address A00003h = Chip3, offset 100001h
What's weird is that the Chip1 and Chip2 data doesn't match even if I check for interleaving. All of the chips report valid Flash IDs and I can see their individual hidden mapping data but the data for Chips 1 and 2 don't resemble the game data that was programmed to them.
One significant difference is that prior to the hardware change, valid flash IDs were reported only for Banks 0x40, 0x50, 0x60, 0x70, 0xC0, 0xD0, 0xE0, and 0xF0. After the hardware change, valid flash IDs are reported for all Banks 0x00 to 0xF0.
More testing to do...
More testing to do...
Oops, that isn't possible, at least not on a SNES console (which would map WRAM to that address). But if the HIROM:ALL mapping mode is supposed to be used ONLY by programming stations (which don't do that WRAM mapping), then it might work as, ie. mapping "HiROM" in banks A0h..FFh.skaman wrote:SNES address A00000h = Chip3, offset 000000h
But it as you said, it might confilict with SRAM. Maybe there's some command that can disable SRAM, ie. by writing something to port 2400h. I haven't spotted such a feature, but I've focused on FLASH mapping, and didn't check if/which commands affect SRAM mapping (and of course, didn't do any SRAM tests with pin97 toggled).
So it might be worth searching for commands that can disable SRAM. You could also try to toggle pin38, maybe that could solve the SRAM conflict in the HIROM:ALL mode (and hopefully still allow to access SRAM in normal mapping modes).
Apropos normal mapping modes, did you try if the card/games still worked on SNES after installing the extra chip & toggling pin97?
Here's what I found. R10 makes the flash chips visible in all banks.
With the resistor on R11 (original position), flash chip IDs are found in banks 40,50,60,70,C0,D0,E0,F0. We know that there are two chips at 0xC0/0xD0 (mirror 0x40/0x50) and 0xE0/0xF0 (mirror 0x60/0x70). The 3rd chip was nowhere to be found.
With the resistor moved to R10, flash chip IDs are found in all banks. I removed the 3rd chip to confirm that the first two chips are still in banks 40,50,60,70,C0,D0,E0,F0. So that means that the 3rd chip is found in 00,10,20,30,80,90,A0,B0. The 3rd chip becomes visible but the data in banks 40,50,60,70,C0,D0,E0,F0 is not correct. It appears that the contents between the 3rd chip and the other flash chips are combined.
What is interesting is that I replaced the third 1601 flash with a 1610 flash, the flash ID check showed C2F1 (1610) in all banks. There was no C2F3 flash ID in any bank and that was confirmed by the lack of mapping data.
I reprogrammed the third chip externally and confirmed that the data when read on the cart is interleaved as I mentioned previously.
All of my write tests have been using the HIROM:ALL mapping but it doesn't appear to be possible to properly write all 3 chips using this mode. I'm going to attempt to program each game slot individually and let the MX15001 handle the mapping. Hopefully involving the MX15001 will eliminate the problem with the data combining between flash chips.
Wish me luck!
And then change the resistor, theoretically, the cart should then still be able to read the menu from the 1st chip - if it doesn't work then there strange things happening.
Did you try the unknown Port[2400h] commands to see if they affect the mapping. And especially, did you try Port[2400h]=21h, since that command is known to disable ROM on a cart with 2 chips (and might thus activate the 3rd chip on a cart with 3 chips).
Might be best to try the above stuff with the resistor both at default & special locations (as by now, the special resistor setting didn't seem to do what it was expected to do, so maybe it's having some different purpose as expected, like activating a special mode with one large FLASH instead of 2-3 small FLASH chips, or whatever).
Are you sure that your 1610 chip outputs F1h as device ID? And what's its exact part number? The device IDs known to me are:
FAh = MX29F1610A ;\with sector_protect, suspend/resume, without sleep/abort
FBh = MX29F1610B ;/
F7h = MX29F1611 ;-with sector_protect, suspend/resume, sleep/abort
6Bh = MX29F1615 ;-without sector_protect, suspend/resume, sleep/abort
F3h = MX29F1601MC ;<-- undocumented, used in SNES nintendo power carts
If two chipselect's are triggered simultaneously, then you might get two ID's ANDed together.
On the other hand, with above values, that would never result in F1h. So yeah, I guess must have some chip that isn't in the above ID list.
I am not sure if I can follow you on the what-is-in-which-bank stuff. Having data in banks 40,50,60,70,C0,D0,E0,F0 makes sense to me - but didn't clearly say when there is no data in those banks.
Normal HiROM mapping should mirror the upper 32K-halves to those banks, or is that different in "HIROM:ALL" mode (with default resistor setting), and there's nothing mirrored to bank 00-3F and 80-BF in that case?
Btw. if you want to use the FLASH commands with port AAAAh and 5554h, did you recurse that bank 00-3F and 80-BF are only 32Kbyte in size? Ie. the FLASH commands would be then written to 01AAAAh and 0D554h. And chio ID would be read from 00800xh.
EDIT: Or as you said you get that weird interleaved mapping at A00000h and up when changing the resistor: That's apparently not following the normal 32Kbyte mapping. On the other hand, in that case, AAAAh and 5554h would need to be converted to interleaved addresses, which should be A05555h and A02AAAh (ie. divided by 2, plus A00000h). Hope that's right, the interleave effect is quite weird & confusing.
If everything doesn't help: Maybe nintendo has mis-wired the PCB (to me, FLASH_CS3 would look better at pin73 instead of pin71, but I hope that they knew what they were doing, and then pin71 should be okay).
For example - "Super metroid"
Code: Select all
copy s+u+p+e+r+space+m+e+t+r+o+i+d out_file
Archive contains only uppercase letters and a space
- (3.39 KiB) Downloaded 455 times
or MAP files for standalone ROMs up to 1024kB
Nope the information written on the SF Memory is very different from the GB Memory from what I've seen in earlier posts.allstone wrote: infinest does it also work with SF Memory as basically its the same chip ?
Somebody else would have to program another application for that.