Gameboy Development Forum

Interesting. So, as expected, the current emulation implementation for are done to make games work, not to emulate the exact behavior. I might have a go at MBC7... at some point. (Famous last words.)

For reference: These are the only games (in GoodGBX) that use MBC7 according to the ROM header. And the F1 versions are just "fixed" versions, probably for emulator/flashcart use, so that leaves a total of 3 distinct titles. Japanese Kirby TNT, international Kirby TNT, and Command Master. The fix is at 05:6857 where a ret opcode is inserted. Otherwise, the routine would wait in a loop for bit 0 of $A080 to become 1. This is after setting CS high, so maybe waiting for a pullup to settle?

MBC7    -       2048R   0A      YESBATT command_master_(j)_[c][!]
MBC7    -       1024R   0A      YESBATT kirby's_tilt_'n'_tumble_(u)_[c][!]
MBC7    -       1024R   0A      YESBATT kirby's_tilt_'n'_tumble_(u)_[c][f1]
MBC7    -       1024R   0A      YESBATT koro_koro_kirby_(j)_[c][!]
MBC7    -       1024R   0A      YESBATT koro_koro_kirby_(j)_[c][f1]

I've been writing a Python utility for bitbanging the serial protocol over parallel port for use with the GBlinkDL ROM, and I wrote some support code for MBC7 operations, including save game dumping: https://github.com/endrift/gblinkpy

Will be writing up my findings in a few hours, as well as possibly adding more MBC7 stuff. I'll probably add MBC1, 3 and 5 later on, assuming I have cartridges with all of those (I think I do). I also want to fix up my writeup to align more with what Tauwasser says, as I've confirmed that the EEPROM is actually only 128x16 bits. (I haven't opened up my cart yet to confirm the model, but the command protocol aligns.)

Last edited by endrift (2017-05-25 15:24:04)

Great work! About time we got this kind of documentation. Almost everything out there (for emulators) relies on the same codebase, mine too. But literally nothing in the original codebase was explained, even if it wasn't totally accurate (I had to add comments myself just to make heads or tails of it).

Really looking forward to rewriting my MBC7 code based on this new info

Didn't know that there was a controller called MBC7. Why did they skip number 6 in the counting, is that another bad number like number 4?

kikiwunder wrote:

Super awesome that you're hacking away on this!

Dunno if you saw this, but Command Master has a hidden MBC7 test screen you can access with a game genie:
https://tcrf.net/Command_Master

The stuff you've marked as "unknown" might be what they list as ”けいしゃ”　which translates to inclination. On that page it lists inclination as "0 / neutral / neutral".  I wonder if there's some way to write to the MBC to make it register the current orientation as neutral?

Hope that helps, if you hadn't seen it.

Turns out Command Master was broken in my previous implementations. Thanks!

As for re-centering the accelerometer, this is done by software, not hardware. Whenever the game starts it asks you to hold the GBC flat before pressing A. This is used by the calculations as a baseline, but is not stored back into hardware.

Got the MBC7 EEPROM reading and writing successfully on my cart reader.  I ended up writing to A080 using 0x00, 0x80/0xC0, and 0x82/0xC2 like the cart does.

Nice to finally pull the Kirby TNT 100% save off the cart.

Anyone tested Command Master saves?

The EEPROM on my Command Master cart is always FFs.  I've only played the game to the first part of the tutorial and I fail the first challenge every time.  Maybe I need to reach further before it saves data to the EEPROM.  At least on the cart reader, I can write and read the Command Master EEPROM.  If anyone has a good save, then I'd love to get a copy to test on my cart. 

EDIT:  I finally got past the tutorial and was able to save my game.

I'm moving on to finish the TAMA5 save code.

Last edited by skaman (2018-02-11 08:55:40)

Command Master and Kirby use different PCBs, DMG-A40 and DMG-A47, but both have options to populate 2k or 4k EEPROMs (as per silkscreen), so the only reliable way is to know which save type is populated beforehand. IIRC RAM sive is set to zero in both game's headers, because apparently only SRAM size is tracked there, not EEPROM size. You cannot even accurately know whether 8-bit or 16-bit organization is selected as there are ROMs with the same footprint that have ORG not connected and have a fixed organization.

The configuration is done using a hardware pin, which is left unconnected on the boards. I was just mentioning it, because the save type/EEPROM type have nothing to do with the size of the ROM, really. It's kind of like the Game Boy Advance situation where people resort to reading string from ROM in order to determine the save type.