nesdev.com

You can reprogram it 100.000 times.

But when I write flash command to my gameboy np cart,and always return 0xcd,
only flash id command return normal data : C2 89 00 , others always return cd cd cd...

byemu,

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).



Use those two functions in the following manner.


Good Luck!

skaman,
I see,thank you.

I finally got around to soldering a 3rd Flash chip to empty location on the SF Memory Cassette PCB.

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.

Are you using the HIROM:ALL mapping mode when doing that tests? Normally that should be the "best" mapping mode to access all memory, at least for normal carts with 2 chips.

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.

I programmed the new 3rd chip with different data patterns for the 1st MB and 2nd MB using an external programmer board before soldering it to the PCB. The 1st MB was programmed with an initial 0x100 bytes of 0x55 followed by a repeating block of ascending bytes 0x00 to 0xFF. The 2nd MB was programmed with an initial 0x100 bytes of 0xAA followed by a repeating block of descending bytes 0xFF to 0x00.

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...

Hmm... I tried to erase the chips and it worked for the most part. Chips 1 and 2 erased to 0xFF. Chip 3 also erased to 0xFF BUT when I read back the contents starting in Bank 0xA0, I see unique data at 0xA06000-0xA07FFF, 0xA16000-0xA17FFF, 0xA26000-0xA27FFF, 0xA36000-0xA37FFF and that data repeats at addresses +0x10000. I assume that this must be SRAM data. When I checked the other banks, the data mirrors in Banks 0x20, 0x30, 0xA0, and 0xB0. The Chip 3 data must need to be read from Bank 0x80 (Bank 0x00 returns the Port Status bytes at 0x2400-2407).

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.

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?

Still trying to figure the 3rd chip out.

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!

Yes, test the normal mapping apart from the HIROM:ALL stuff! Basic test would be to just program the cart with the menu on 1st chip and with normal resistor setting. That should supposedly work even if the 3rd chip is installed (?)
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).

Hello everybody! I drew letters for the menu using the tile molester. To compose a bitmap with the name I use the command line
For example - "Super metroid"

Then I use the HEX editor, copy the contents of the final file, excluding the last byte and paste it into the menu at 0x6203f

Archive contains only uppercase letters and a space

For anyone interested, I started working on a little application for quickly creating a ROM + MAP for the menu and additional games
or MAP files for standalone ROMs up to 1024kB

https://github.com/Infinest/GB-Memory-Binary-Maker

infinest does it also work with SF Memory as basically its the same chip ?

Nope the information written on the SF Memory is very different from the GB Memory from what I've seen in earlier posts.
Somebody else would have to program another application for that.