nesdev.com

One issue solved: I've been using [2000h] for ROM bank selection, that's working okay in MBC5 mode (eg. when mapping the MENU). But, it doesn't work stable in "MBC4" mode (when mapping WHOLE 1024K, activated via CMD_04h), in that mode, [2000h] does map the desired bank, but it does cause weird read errors at random locations. On the other hand, using CMD_04h combined with [2100h] for bank selection does work fine - I can now dump the entire cart without read errors.

For direct ROM writes, CMD_10h seems to disable writes to the ROM Bank register at 2100h (and instead, any writes to 2100h are probably directly going to FLASH memory address 2100h). There are probably two commands needed for direct ROM writes:
- CMD_10h disable writes to normal MBC registers (such like 2100h)
- CMD_08h disable writes/reads to/from special Nintendo Power registers (those at 0120h..013Fh)

Okay so far, but I can't figure out how to undo CMD_10h and re-enable writes to ROM bank register. Going by skaman's logged code shown above, CMD_01h would look like a good candidate, but it doesn't seem to work. I've also tried to reproduce the whole log (except the data write): Ie. using CMD_10h, CMD_08h, CMD_09h, CMD_0Ah, CMD_01h, CMD_02h (in that order), but the cart still doesn't react to ROM bank writes (and stays stuck in the most recently ROM bank).

Solved that issue, too. CMD_11h does re-enable writes to the ROM Bank register. Ie. the full procedure for recovering from direct ROM write mode should be:
- CMD_09h: re-enable access to port 0120h..013Fh
- CMD_11h: re-enable access to MBC registers like 2100h

The write to 2100h in the logged hidden-data-write sequence probably doesn't work since the log doesn't contain CMD_11h. But then, hidden-data-writes don't require any rom banks at all (except that, the bank must be 01h (or some other odd value) for writes to 5555h).
Writing the whole 1024K flash memory is a different thing: That does definitely require writing different values to the ROM bank register - so that would require using CMD_11h (or maybe one could work around it by issuing a /RESET to the cart instead of using that command). Would be (slightly) interesting if mootan's tool used CMD_11h for flash memory writing.

EDIT: And, two other details concerning clearing bit0 and bit1 in the status register at [0121h]:
CMD_03h does clear status bit1.
CMD_09h (the "Wakeup" command) does clear status bit0.

Nintendo Power Directory for Gameboy version
Located at ROM offset 1C000h (aka 7:4000h in gameboy memory).
Entries are 200h bytes in size, the GUI supports max 8 entries at 7:4000h..7:4FFFh.
The first entry is a dummy entry for the menu, the other entries are for game(s), unused entries are FFh-filled.
The format is almost exactly same as in SNES version (but using only 200h bytes per entry, using a smaller bitmap, and without the SNES's weird overlapping bitmap tiles, and with different granularity for the ROM/SRAM values).

For the SRAM sizes, the "xx" means that the GUI ignores those 8bit fragments. And no matter of what values that bits have, it does support only four different SRAM sizes: 0, "MBC2", 8K, 32K. Anyways, the "xx" should be probably set to some specific values - skaman, did you check which games use which SRAM size settings in the directory?

News Ticker
Aside from the directory, the programming stations are also updating data at bank 6:4000h (ROM offset 18000h). Which contains the scrolling text that is shown at the bottom of the menu. There are at least two variants, one found in blank carts (with only the menu installed), and one other variant found in my cart with Puyo Puyo 2 installed.
Don't know how often that text has been updated. Skaman, if you compare the ROM offsets at 18000h..1BFFFFh from your cartridge collection, are there lots of different variants?

Selftest Function
The Menu contains some selftest function which seems to be activated when pressing all four buttons plus all four DPAD directions (which normally isn't mechanically possible). The test is barely testing the MENU's memory mapping, not testing the mapping or checksums of the other installed games. And, the test is working ONLY on blank carts, for two reasons:
The checksum in cart header isn't adjusted for changed data at 6:4000h (news ticker) or 7:4000h (directory).
The bank test expects 7:4000h to contain 07h (whilst non-empty carts are storing the menu index (00h) in that location).

Nocash, no need to lock out bank select registers when flashing as writing to bank0 at $6000 is the same as $2000 and the mbc won't trap the write.

Your earlier question regarding writing a dummy byte to actually write to the flash. Yes you must do it every byte written unless using the write buffer then its just once per 32bytes written.

That's working? You can write data to any FLASH address using "[2100h]=(Addr/4000h)" combined with "[4000h+(Addr AND 3FFFh)]=Data"? That would be neat - but it doesn't seem to work for me. Did you test that on a real Nintendo Power cart? If it would work, then it should be possible to access the 2AAAh/5555h addresses using the same technique, ie. for requesting the FLASH chip ID, one could do either this (tested/working):or this (tested, but not working for me):One possible issue is that 4000h..5FFFh is the MBC5 SRAM Bank register, so writing to that area won't ever reach the FLASH chip... unless the cart is passing the write both to SRAM Bank register and to FLASH chip, or unless there's some way to disable the SRAM Bank register(?)


Uh, I lost track of what I was asking about which dummy byte.
There's a dummy byte needed every byte written? And there's a 32-byte write buffer in nintendo power carts? Was that already mentioned anywhere? Maybe I haven't followed the gameboy-stuff too carefully before getting my own cartridge (I've tried to review the gameboy related posts last week though).

Sorry, I misread. Yes, issue it 128 times.

Here's the News Ticker text that I've found:

I've found some ways for writing data to the gameboy cart. Nothing really new, but just some notes about how to do writes in practice, and notes about possible problems.

First of, issue the chip erase command. BennVenn has been right about needing to unprotect sector 0 first (some macronix datasheet sounded as if the protect flags would be don't care when /WP=HIGH, but that seems to have been wrong, or doesn't apply for the chip used in the gameboy cart; the first 128Kbyte will remain unerase without the unprotect). Also as BennVenn mentioned, the chip erase command does erase only the 1024-Kbyte area (not the 256-byte hidden sector).

For writing 128-byte fragments:
- Use CMD_09h + CMD_11h to enable I/O access
- Use CMD_0Ah + CMD_02h to get /WP=HIGH
- Set Bank 01h and use CMD_0Fh to send the FLASH write command to 5555h/2AAAh/5555h
- Set Bank (addr/4000h) for the write destination
- Do the 128-byte data write (see below, method 1 and 2)
- Read status and wait until bit7=1
Then repeat for next 128-byte fragment.
Bank 0 must be written to 0000h..3FFFh. Trying to write bank 0 to 0:4000h..7FFFh doesn't work (at least not when using CMD_04h to map the entire FLASH memory; it might work in MBC5 mode, but that won't help since CMD_04h doesn't use MBC5 mapping).

Data Write Method 1 - direct writes:
- Send CMD_10h + CMD_08h to disable I/O ports and get direct FLASH write access
- Send 128 bytes, then terminate by writing FFh to the last written address
Normally: That method is best & fastest. It should be also the easiest way if you have direct access to the gameboy cartridge bus.
With Bung hardware: It can be a bit difficult when squeezing the data through the Bung parallel port device: Transferring address+data through parallel port works, but it's rather slow. Better would be using Bung's auto-incrementing address mode (done setting bung's mode byte to 81h, 82h, or 83h). Write+Increment is normally done by using 82h or 83h, but that didn't seemed to work at all, the Nintendo Power cart totally ignored all written bytes (and instead it did eventually write the following control bytes like 55h and AAh to unintended addresses). The mode value 81h is normally used for Read+Increment, but for some reason that value does work well for writing to Nintendo Power carts. And, another issue with Bung+DirectWrites (with or without auto-increment) is that the programming does occassionally start before writing all 128 bytes (so the last bytes of that area stay FFh-filled), that's probably some timing issue where the cart believes to have received two /WE pulses at the same address. I've got around that effect by inserting an extra OUT opcode: The SPP-mode write_data is: OUT port+0,data; OUT port+2,03h; OUT port+2,01h. Inserting a OUT port+2,00h at the begin of that sequence fixed the problem (that extra OUT would temporarily set read-direction, which appears to avoid wrong /WE signals). Only way around that problem seems to be to retry writing in case of verify errors (there should be no erase required on retry since the missing bytes are still FFh). Anyways, that issues are all bung-related. Don't care if you have a different hardware setup.

Data Write Method 2 - indirect writes via CMD_0Fh:
- Send 128 bytes via CMD_0Fh, then terminate by writing FFh to the last write address also via CMD_0Fh
That's just endless slow (with the bung hardware in SPP mode it's taking about 5 seconds per 16Kbyte). And, it turned that CMD_0Fh can't write to 0120h..013Fh (so any cart programmed that way won't boot due to invalid Nintendo logo in cart header); in MBC5 mode it might be possible to write that area via 0:4120h..413Fh, but that would require the mapping info in hidden sector to be (re-)programmed to use MBC5 mapping for file 0. So essentially, CMD_0Fh would be painfully slow and overcomplicated.

Oh, and the above japanese text translated via google, just to get an idea what the scrolling text is about:

I've also tested reading/writing/erasing the hidden data on the gameboy cart. It's just working as seen in skaman's logs, so I can only confirm that everything works as expect, and that the hidden stuff isn't more difficult than normal FLASH access.

For reading hidden data, send 55-AA-55-77 twice, then read 100h bytes from 0000h..00FFh (though that 100h bytes seem to be mirrored to all other FLASH addresses, too).

For erasing hidden data, send AA-55-60, then AA-55-04h.
In skaman's log, that's preceeded by AA-55-60 and AA-55-40h, that command is somewhat required for unprotecting the first 128Kbytes, but it isn't directly related to erasing hidden data (unless, maybe it's also unprotecting the hidden data, but anyways, there's no need to use that command as prefix right before sending the hidden erase command).

For writing hidden data, send AA-55-60, then AA-55-E0, followed by 128-byte data (transferred the same way as normal writes mentioned two posts earlier).
In skaman's log, that's preceeded by AA-55-A0h-FFh-FFh, ie. writing FFh (=nothing) to some FLASH address, which really isn't required.

Alltogether, everything seems to be working. Except, I should spend some more time on making my transfer program more stable, and write some documentation that summarizes all the NP commands and FLASH commands and data structures. And, just for curiosity, test if there some more hidden commands, like [0120h]=12h..7Fh. And of course write/erase is still needed for the SNES cart (although skaman seems to have already managed to get a SNES cart erased via some relative simple looking command sequence, and writing is hopefully not much more complex).

Got the hidden write/erase working on the SNES cart. The code that skaman used when he got a chip erased looked as so, with only two unknown variables:

Based on that, I made my own brute force program, testing all combinations for "x" and "y". Aside from the official macronix commands, I've found only two undocumented commands:

The sharp-style leading 38-D0-71-72 turned out to be not required for writing/erasing.

Great work!

My search code on the SF cart must be faulty. I'll have to modify my code with your findings and get it working.

Thank you for all of your help!

Thank you for all your work, too! To be honest, I've given up on writing/erasing the SNES cart about 3 months ago, the nonstandard sharp-style commands in a nonstandard macronix chip made me think that's almost impossible to find the correct commands. Probably it would have remained impossible - if you wouldn't have continued searching until actually finding a way to erase the hidden data.

Also thanks to sanni (especially for the initial databus log with the 38h-D0h values), and to BennVenn for details on the gameboy cart (especially the don't-write-F0h part), and credits to mootan for originally hacking the gameboy cart (which doesn't have the confusing sharp-style commands, but looks even more difficult than the SNES cart in other aspects).

Simply amazing, big thanks to all of you.

The code I'm using right now seems to be doing something wrong though but strangely it only affects the first flashrom.
While all works perfectly fine with the second flashrom(0xE0 when in HiRom All mode) for me the first flashrom(0xC0) always locks up when I try to erase/write the hidden mapping information.
Even weirder I got the same issue with the sector protection. I can set/remove the sector protection byte for the 0xE0 chip just fine but the 0xC0 chip always locks up.
I tested two different NP carts, both behave the same.

I was getting the same results. The 0xE0 chip could be erased and programmed using the commands but the 0xC0 chip refused to be programmed.

I switched the code to use Bank 0xD0 and the 1st chip can be erased and programmed.



Thanks nocash!