GB & GBC Games Likely to Fail in your Emulator or Flash Cart

I have attached a list of games, currently numbering 70, that are likely to fail in your flash cart or emulator. Some may boot, some may be partially playable but all are likely to fail sooner or later. These >32KB games do use one of the common MBCs (1, 2, 3, & 5) or do not use them in a typical manner.

There are three issues with games like these. First, some of them have hardware that is difficult (camera, accelerometer, flash memory, eeprom) or impractical (infrared, noise making when powered down) to emulate or simulate. Second, there is scant documentation for the hardware in these cartridges because the games are in Japanese or extremely obscure. Third, testing real hardware can be difficult because the cartridges are either rare or in Japanese or Chinese.

Essentially this list shows that emulation of not just unlicensed but licensed games cannot likely be completely done without a mapper assignment system. The internal header can't always be trusted, I believe it fails with MMM01 games for example. Maybe only 16 assignments should be required this time

The way I handle unique mappers that can't be ID'd via the header is to have the user manually specify which one they want to use before my emulator runs via a simple drop-down list. For example, MBC1M (the multicart variants of the MBC1) and MMM01 carts are done like this in GBE+. Most recently, I've added the MBC1S (sonar variant of the MBC1) to that list.

A lot of people scratch their heads when it comes to handling exotic carts that aren't well detected via the header or other metadata. To me, the solution is simple: don't automate the process. Just tell the user to decide things manually. The mappers outside the current "read the header" method are so small in number, they're edge cases where I'd expect a user to do some prior research (especially since GBE+ comes with a manual detailing such edge cases and how to deal with them)

On a separate note, it's actually not that hard to automatically detect MMM01 carts, it's just not as straightforward the other MBCs. An emulator need only verify that a valid cart header is in the last 32KB of the ROM when reading in that file (e.g. check for Nintendo logo just to be sure, maybe even do the checksums to be safe). If so, odds are it's an MMM01 cart (or some really tricky homebrew designed to fool the emulator). But this is not as simple as reading a single byte from a fixed location, so emudevs tend to make a fuss about MMM01

Anyway, great list! It's perfect for those looking to expand past the basic MBCs. It's useful too to have a list of all of the unofficial carts. Naturally, I have a couple of suggestions to add:

Gyogun Tanchiki: Pocket Sonar - I've informally called this the "MBC1S". It's mostly MBC1; if you treat it as a normal MBC1 cart, you can browse the menus and play the mini game. But sonar functionality will not work. You'll either get a black screen or a white screen depending on what values an emulator returns for unaddressable cart RAM. It's still possible to emulate the sonar via a static image (or other external input, like your own sonar device). Still working on finishing the documentation.

Battle Space and Monster Maker: Barcode Saga - Normal MBC1 carts, but they absolutely require a working Barcode Boy to communicate with. At the start, before being able to enter any play mode, the game pings the Barcode Boy. This isn't a problem with a flash cart as long as you hook it up to a real Barcode Boy, but most emulators will get stuck on a screen asking the user to power on the Barcode Boy. The other 3 Barcode Boy games play just fine without a Barcode Boy, you just can't scan cards for extra stuff.

Zok Zok Heroes - Normal MBC5 cart, but needs the Full Changer accessory for battles. Without the special IR input, the game will get stuck during the first battle/tutorial waiting forever. Even getting past that, every other fight is almost impossible without using the Full Changer to change into different heroes. Not a problem for flashcarts, but definitely an issue for emulators.

GB Mobile Trainer - Not exactly a "game" but it requires the GB Mobile Adapter. Once again, no issue for flashcarts since it's a normal MBC5 cart, but it's tricky for emulation.

Chee Chai Alien - Normal MBC5 cart, but it's the one GBC game that extensively uses the IR receiver. Not tricky from an emulation standpoint (it's enough to return 0 every time the game reads the IR register to get the game to "work" as a hack) but on a real GBC, you better have that plastic clip-on. I tried playing with and without the clip-on, and it seemed to make a world of difference. At least, it took the frustration levels down a couple notches. It's hard to properly "capture" light input without the clip-on, and still finicky when you have it attached. Maybe not the best candidate for the list, but it's one to be aware of at least.

I don't mean to toot my own horn, but I spent a lot of time getting the above examples working in GBE+ Hopefully I'll be diving into the HuC-1 and HuC-3 stuff next year since I have everything necessary to emulate IR communications.

At least one user in the GBDev Discord server discourages homebrewers from creating new mappers because they will not work in the big 3 accuracy-focused emulators (BGB, Gambatte, and SameBoy), and therefore developing games for them will be prohibitively difficult even if you have wire-wrapped your own prototype board.

A couple weeks ago, I explained the process through which I led the design of the Action 53 mapper for NES:

1. Spec, reference implementation of banking function in two different languages, and manual test ROM designed to also work on no mapper
2. One emulator adds preliminary support
3. Automated test ROM
4. Multiple emulators add full support
5. Someone writes Verilog for a CPLD

In the case of a coding competition for Game Boy that receives 14 entries, this user recommended without detectable sarcasm that shipping a 14-pack of individual cartridges would be preferable to shipping a multicart with a custom mapper loaded onto a CPLD.

I had not considered the "needs peripheral to work" category of games outside the Camera, I didn't know the ROMs for those had been dumped. To your list I could add Mario Family, a normal MCB5 cart that works with the Singer Izek sewing machines and doesn't do much without one.

I could also mention other odd peripherals like the GameShark MX, which included a modem in the large cart and had software you could use to read your email, if you had a subscription for the service.

Beware mentioned that the MMM01 games work in his emulator, bgb, just fine if you transpose the first 32KB of data in the No-Intro ROMs to the last 32KB.

If transposing data banks or adding headers doesn't get your blood pumping with enthusiasm, might I suggest automating the process by use of different file name extensions for the obscurer carts. You could do something like this :

.ws - Wisdom Tree Mapper (Uses a 74'377)
.rg - Rocket Games Mapper
.rgc - Rocket Games Color Mapper
.rgm - Rocket Games Multi-cart Mapper
.mmm - MMM01
.m1m - MBC1 Multi-cart
.m1s - MBC1 Sonar
.m30 - MCB30
.man - Mani Discrete (Uses a 74'161)
.sxx - Sachen Mapper xx (unsure how many are needed)

The Analogue Nt Mini does something like this for its Atari 2600 Core because it does not have the capabilities to detect some of the more unusual 2600 mappers and there is no header standard for 2600.

If someone wants to develop a game they wish to put on a cartridge and sell to the public, then a new mapper might be a good idea to prevent casual piracy. But for non-commercial development, just use an MCB5.

Would "Wisdom Tree" collide with WonderSwan?

Is there a better way to include multiple independent executables in one ROM than a custom mapper?

I have added a few more ROMs and made a few corrections. I used an ancient emulator called DreamGBC to assist me. This emulator has a loader program which will show the header information in a convenient format. It helped me catch a few HuC-1 games.

The No-Intro MMM01 dumps may match the physical configuration of the ROM, but not the logical configuration as the cartridge hardware presents it to the Game Boy. On bgb, these games must be fixed by cutting the final 32KB bank and pasting it before the first 32KB bank. Additionally, the Mani games must have their header fixed to indicate the MMM01 instead of the MBC3.

I think .wst could be used for Wisdom Tree games

It seemed there were two hardware approaches to doing the official multi-carts without rewriting the program during the GB's lifetime. One approach was to use the MMM01, the other was to use the MCB1M method, which rewires the MCB lines on the PCB so that the RAM Bank acts as game select register. It works so long as no single game is larger than 256KB in size, at least in the way Nintendo implemented it. The MMM01 is a complex extension of the MBC1 which never appeared to be used outside of multicarts.

MBC1M technique becomes wasteful when you want to include compo entries of varying size, such as 16K, 32K, or 64K. Is "ROM Bank #WE/Mask" in MMM01 supposed to control the size of the game?

I'm honestly unclear how exactly the mapper works to wall in a game to its own space within the ROM, but masking bits seems to have something to do with it. That MMM01 page is the only page with hard information about the chip, but while the information on that page seems technically more precise than say on gbdev, it is also a lot more obtuse.

In other interesting things, the Mani 4 in 1 (China) (DMG-601 CHN) has no more data in it after the 160KB mark, although I'm quite sure that there is a 256KB ROM inside the cart with padding. It is structured as 32KB for the menu + 4 x 32GB games.

All the Mani games were distributed in China using MBC chips from Nintendo. The boards seem to be manufactured by Mani and are designed to accept bonded ROMs coated with epoxy. Here are some samples :

http://datomatic.no-intro.org/index.php ... =46&n=1545

http://datomatic.no-intro.org/?page=sho ... =46&n=1160

Ironically, the Chinese version of Tetris does not use epoxy ROMs whereas it frequently did elsewhere in the world.

The Mani multicarts do a form of poor man's colorization and some of the Collection multicarts support SGB functions.

Now I think I am clear on how the MMM01 works.

It is clear that the Mask Bits in the MMM01's Mode Register remap the physical location of a game on the cartridge's logic chip to the logical location the game expects itself to be in the GB's memory map. It does this by controlling which address lines will be active. You can individually set whether bits A15-A18 will be enabled or disabled. That allows you to have 15 x 64KB games, 7 x 128KB games, 3 x 256KB games or any combination thereof so long as each game has its exclusive space within the ROM and starts on a 64KB boundary. Then you set the MMM01 to MBC1 mode and turn control over to the game. The MMM01 zero-adjusts the bankswitch writes as well so the game thinks it is the only game on the cartridge and it starts at $0000 within the ROM.

Why 15, 7, & 3 games and not 16, 8, and 4 games? Well, the multicart menu needs to reside somewhere do fiddle with these mask bits and set the appropriate mode for each game. It is physically placed at the end of the cartridge ROM in its last 32KB bank. I believe one of the first things that all known MMM01 carts do when they are booted up is to write to the multiplexer bit in the Mode Register. This switches control from the first 32KB bank to the last 32KB bank by outputting ROM A19-20 to CPU A13-A14. I think this is why an emulator like bgb needs the multicart menu at the beginning of the ROM, it relies on the header value to determine what memory control scheme to emulate and it "sees" the memory controller specified by the first header, namely the header for the first game on the multicart.

It should allow 32KiB games also...

I think it does: set all four game size bits to 0.

Here's how I understand the MMM01 docs:

The big problem is that leaving supervisor mode appears to be one-way, preventing anything like "exit to multicart menu on A+B+Select+Start" or "exit to multicart menu from game's main menu".

Reset. It's not a big deal to watch the Nintendo logo.

That's what EverDrive X series does when starting a game or when the player presses the microswitch under the front of the cartridge's chassis: it asserts the reset line in the cartridge to cause the Game Boy CPU to reset. It does this in part to allow switching between Game Boy and Game Boy Color modes. But MMM01 doesn't expose a port to let a program send such a signal.

By the user turning the console off and on.

Rocket Games single game GBC releases use an MCB1 clone, but it's header needs to be fixed to work with most emulators and flash carts. Designate them as MCB1 (Cartridge Type 01), make sure the ROM and RAM size is correct (never any RAM), restore the Nintendo logo and fix the header checksum.

One curious thing however is that Rocket Games would display "ROCKET®", not "Nintendo®" on the bootup screen. The GBC checks some of these bytes to ensure that your ROM was displaying the correct name. Rocket Games presumably found a way to bypass the check, but when you replace the logo, the games work but now display Nintendo®.

BennVenn's analysis of Datel's Game Boy Modem indicated that the logo was stored in the MBC itself, and the MBC knows when to switch between the external ROM (for the desired logo) and the internal ROM (for the TMSS circumvention).

Unfortunately, BennVenn's apparently taken down his old analysis pages.

Fortunately the Internet Archive has saved that page : https://web.archive.org/web/20150106134 ... l_MBC1.htm

Unfortunately it looks like someone is going to have to get out the logic analyzer to figure out what the Datel chip does. For the Shark MX, the extra features make sense, but for these simple games, its overkill. Moreover, I think the use of the pure Nintendo logo would have been covered by Sega v. Accolade.

Here is an iNES-like mapper scheme which could be useful for unlicensed games and licensed games which cannot be detected by internal header alone : http://hhug.me/gbx/1.0

Actually, not quite. I forgot to highlight a crucial detail on the wiki page... In general the VHDL code should describe the complete behavior and the text is kind of supplementary: in unmapped mode, the high-order ROM address lines are all forced to 1 regardless of the actual register contents. That's why the last two 16kB ROM banks need to contain the menu. And because BGB doesn't know that before it inspected the header, it needs the menu up front.

The multiplex bit part is weird, because the additional #WE bit for the MBC1 mode seems pretty useless, unless the multiplex would be able to switch with the MBC mode somehow :-/

I have attached the latest version of the List. I observe that bgb v1.5.7 can run all but three of the licensed mappers, even if it cannot do much with the Camera and the Sonar. I don't know of any emulator that can touch the Mani 74'161, MCB6 or TAMA5.

KiGB, higan, mGBA, and GBE+ can all emulate the MBC6, at least enough to play the only game that uses it (Net de Get: Minigame @ 100). The Flash chip is only used for downloading games, and only GBE+ currently emulates enough of GB Mobile Adapter + the download servers to get that far. Flash itself isn't emulated, but I can get Flash related error screens as it concerns the downloads. At any rate, the MBC6 is partially (mostly) emulated.

higan and mGBA (and to some extent, even VBA-M) support the TAMA5 as well. I don't believe the RTC is emulated just yet though.

Feel free to ask specific questions. The function of the MMM01 mapper isn't that hard to comprehend. I think what confuses people the most is the way the data is packed into the registers and the multiplex bit.



The DMG-601 CHN multicart is a special cartridge that does not use a regular MBC chip but rather an off-the-shelf counter 74HC161A used as a flip flop. This particular multicart comes in two flavors: regular mask ROM SSOP (DMG-M161-M01 PCB) and COB (DMG-M161-M12 PCB). The SSOP version is a 2 MBit mask rom (256 KiB, marking 23C2001), and dumping confirms that, because if it was just a 1 MBit mask rom, I would have read the lower ROM contents twice.

I only know of one other case involving odd ROM sizes and that's a 3 MBit mask rom that actively outputs 0x00 when reading past the actual ROM (Sachen Street Heroes). Of course I can't rule out that this is somehow a special 1 MBit with 2 MBit addressing ROM chip that outputs 0x00 in a similar manner, but I doubt it. The PCB/mapper itself can address up to 2 MBits as well.

Is this the same as Wisdom Tree's mapper? (GB.A14 = 161./LatchEnable ; GB./WR = 161.↑Clock)

As far as I'm aware the Wisdom Tree games use SN74LS377N, which is an octal flip flop. However, the M161 games can disable the mapping by writing the most significant bit to 1. The Wisdom Tree games all fit within 8 MBit with the exception of the NIV Bible, which is 16 MBit. I don't know what PCB the NIV Bible uses or if other Wisdom Tree games use different PCBs and/or mappers. However, pictures from DAT-o-MATIC show SN74LS377N on all PCBs dumped so far, which isn't a lot.

Spiritual Warfare PCB (1992 Color Dreams Inc.):


DMG-M161-M01 PCB:

Yes, but the functional differences between the '161 and '377 are: 161 has: 4 bits, asynchronous clear, increment, carry output; '377 has 8 bits, none of the rest.

Are you certain it's A15? There's both a timing hazard with A15's timing relative to /WR, and another (low-quality) source claims that it's A14.

edit: I managed to finally figure out how to navigate Dat-O-Matic to find what is probably the same PCB that was used above, and yes, it's definitely A15.

Oh, I see, there's a diode OR gate there to let it lock out subsequent bankswitching.