And, tested some software stuff, too. I've been using an old parallel port cart reader from Bung, getting that thing to do what it should was a bit difficult (bung seems to have used a MODE byte that can be 00h,80h,81h,82h,83h, bit7 seems to control the /RESET line, and bit1 seems to be auto-incremented on write, and bit0 auto-increment on read - sending nintendo power commands seems to work best with those two bits cleared, and bit7 set to release /RESET). Some of the nintendo power commands take over control of the databus - but seems to be no problem with the bung hardware (ie. it seems to disable its databus output shortly after each writing).
The command values for port 0120h-013Fh known so far:
Code: Select all
[0120h]=00h, ... ;-?
[0120h]=01h, ... ;-?
[0120h]=02h, [013Fh]=A5h ;-Wrpot.Step2 (set stat.bit1)
[0120h]=03h, [013Fh]=A5h ;-EDIT: Undo.Step2 (clr stat.bit1)
[0120h]=04h, [013Fh]=A5h ;-Map Entire
[0120h]=05h, [013Fh]=A5h ;-Map Menu
[0120h]=06h, ... ;-?
[0120h]=07h, ... ;-?
[0120h]=08h, [013Fh]=A5h ;-Undo Wakeup
[0120h]=09h, [0121h]=AAh, [0122h]=55h, [013Fh]=A5h ;-Wakeup (EDIT: and, clr stat.bit0)
[0120h]=0Ah, [0125h]=62h, [0126h]=04h, [013Fh]=A5h ;-Wrpot.Step1 (set stat.bit0)
[0120h]=0Bh, ... ;-?
[0120h]=0Ch, ... ;-Undo Wakeup, too
[0120h]=0Dh, ... ;-?
[0120h]=0Eh, ... ;-?
[0120h]=0Fh, [0125h]=hi, [0126h]=lo, [0127h]=dta, [013Fh]=A5h ;-Write Byte
[0120h]=10h, [013Fh]=A5h ;-EDIT: Disable writes to MBC registers
[0120h]=11h, [013Fh]=A5h ;-EDIT: Re-Enable writes to MBC registers
[0120h]=12h..7Fh ... ;-?
[0120h]=80h..BFh, [013Fh]=A5h ;-Map 0..3Fh with RESET (for CGB/GBA) (set stat.bit2-7 to 0..3Fh)
[0120h]=C0h..FFh, [013Fh]=A5h ;-Map 0..3Fh without RESET (for DMG/SGB) (set stat.bit2-7 to 0..3Fh)
CMD_09h (Wakeup) is probably needed before sending any other commands, and, more eye-catching: It's activating read-access to port 0120h..013Fh. That's making it impossible to read normal ROM data from that locations, unless using CMD_08h (Undo Wakeup), or CMD_0Ch (seems to act same/similar as CMD_08h).
CMD_0Ah and CMD_02h seem to be both required for switching /WP to HIGH. They seem to be working only when sending them in order first CMD_0Ah, followed by CMD02h.
CMD_80h..BFh and CMD_C0h..FFh are used for mapping a selected game. The menu contains three different mapping methods (depending on what console it's running on):
For CGB and GBA consoles: Mapping is done via CMD_8xh, this selects game "x", and issues a /RESET to the gameboy. The advantage is that /RESET does reinitialize everything, AND, allows to switch between color gameboy and monochrome gameboy mode (which possible only after /RESET or power-up). The downside is that it's displaying the "Nintendo" logo another time after game selection.
For classic gameboy and gameboy pocket consoles: Mapping is done via CMD_Cxh, that selects game "x", but doesn't issue a /RESET (maybe because the /RESET pin doesn't work as input on older consoles). Instead, the menu is reinitializing some stuff by software, and does then jump to 0100h (the game entrypoint).
For SGB and SGB consoles: These are using CMD_Cxh, too, ie. without /RESET issued by the MX15002 chip, but instead doing some special SGB stuff: Uploading some code to SNES memory, and then executing that code on the SNES cpu (and that code does issue a /RESET to the gameboy cpu (via SNES port 6003h) and does restart the SNES (via jump to [FFFCh] on SNES side)).
In all three cases, for CMD_8xh/CXh, the final write to [013Fh] is done by code in the gameboy's High RAM at FF80h and up, followed by a short delay also executed in High RAM - that allows the MX15002 chip to read mapping info from the FLASH chip via databus without running into conflicts with the gameboy cpu's opcode fetches.
CMD_0Fh allows to write a single byte to FLASH memory. From the older posts, my impressions has been that it's needed only for writing to 5555h and 2AAAh, and that it's main purpose would be to access those two addresses regardless of the current ROM bank setting...
But, I seem to have been wrong on both. Using CMD_0Fh to write to 5555h is getting redirected to "RomBank*4000h+1555h", ie. the RomBank must be previously set via [2000h]=01h (or actually and ODD value written to [2xxxh] appears to be working).
And, after sending a data write command via CMD_0Fh, the actual data seems to be needed to be written via CMD_0Fh, too. skaman? BennVenn? Is that right?
When writing 128 bytes of data, does one NEED to issue CMD_0Fh 128 times? Or is there some way to write the data part directly?
CMD_04h (Map Entire) does map the whole 1024Kbyte of FLASH memory, and CMD_05h (Map Menu) restores the normal mapping. The menu is using CMD_04h to "preview" the cartridge header of the different games (namely, checking header entry 143h via reading "Bank(N):4143h", if the byte is C0h=CGB only, then it's supposedly preventing to select that games on non-CGB consoles).
Theoretically, CMD_04h should be also nice for dumping the whole 1024Kbytes of FLASH memory. But somehow, I am having problems
to get that working, CMD_04h is in fact mapping the MENU and GAME and unused sectors on my cart. But, it appears to be also causing the cart to return several FFh-filled 100h-byte blocks at random locations.
Am I doing something wrong, or is that happening to other people, too?
And is there some way around it? My overall dumping code seems to be okay, ie. dumping only the MENU (without CMD_04h) does work without problems.
Oh, and reading ports 0120h..13Fh returns these values (when enabled via CMD_09h):
Code: Select all
0120h Fixed 21h
0121h Stat (bit0=/WP.step1, bit1=/WP.step2, bit2..7=Slot)
0122h..0124h Mapping (eg. A8,00,00 for MENU: MBC5 with 128K ROM at block 0, no SRAM)
0125h Fixed 87h
0126h Fixed 78h
0127h Unknown, varies (3Eh or FFh or 5Ah)
0128h..013Eh Fixed Zero
013Fh Fixed A5h
4120h..413Fh Mirror of above (but only in SOME rom banks?)
Whereas, when using CMD_04h (Map Entire), the mapping bytes at 0122h..0124h are changing to 9A,80,00 = Whole ("MBC4", 1024K ROM at block 0, whatever SRAM). Note that the 3bit mapper type is "4", which should probably mean "MBC4". The problem is that nobody seems to know how a "MBC4" is working, and there don't seem to be any gameboy titles known to be using a "MBC4" mapper - so maybe MBC4 didn't exist at all, or it did exist only as prototype. Anyways, maybe that "MBC4" mapping mode is causing the problems that I am having when trying to dump the whole 1024Kbytes.
Oh, and skaman, what did you mean by saying that the program uses CMD_CFh? The MENU program doesn't seem to use it... or did you mean mootan's tool using it... for dumping the whole 1024Kbytes?
The way how CMD_CFh is affecting the status bits at 0121h makes me think that it's just selecting "game 15" using the mapping data at hidden sector address 0Fh*3, which would be normally FFh-filled since the menu uses only entry 0..7. The FFh-filled values would probably map the biggest possible ROM size (ie. all 1024K), starting at the LAST 128K-block (and then wrap to the first block at higher ROM bank numbers), so CMD_CFh could be probably really used to dump the whole memory (when reordering the 128K blocks accordingly).
The only issue would be when the corresponding mapping bytes aren't FFh-filled (eg. the cartridges WITHOUT menu are having ASCII strings in that location, so one should avoid using CMD_CFh on such carts; instead one could just leave the default mapping mode for file 0, which should map all 1024Kbytes for menu-less single-game carts).