Gameboy Development Forum

In principle. it should be fairly doable.

First you need a specification of how to interface with a mapper like that. One such specification is TPP1. It's supported in some emulators, but has as far as I'm aware never been implemented in hardware. I personally have a gripe with this specification because it doesn't even try to be backward compatible with regular MBCs in cases where it could be. MBC5 officially supports up to 512 banks, by using allowing you to write to the 3000-3fff range to set a ninth address bit. A reasonable way of extending this would be to consider (up to) all 8 bits of writes to this register, for up to 65536 ROM banks.

Then you need an implementation. This would be easy in an emulator, where you can pretty much just do whatever you want. As for hardware, you could easily add the extra addressing in a FPGA implementation of a MBC. There are other issues in implementing it in hardware. If you want to use DRAM in place of either flash or SRAM, you need to take into account the DRAM refresh time. The Gameboy needs the data back in less than 1 much less than 1 microsecond whereas DRAM refresh can take multiple microseconds. The cartridge has no way of signalling back to the Gameboy that it should wait, so you need some way around this issue if you go that route.

The idea of TPP1 is great. My aforementioned gripe with TPP1 is with the choice of addresses for its control registers, as well as some of the aspects of the header information. Basically, I would've loved if TPP1 was equivalent to MBC5 for any ROM that didn't use RTC, or extended memory, so that a hypothetical TPP1 flashcart would be mostly backward compatible if you wanted to run regular ROMs on it.

As for MBC5, I guess the limiting factor was, as you said, money. But more specifically the number of pins on the MBC chip. More address bits would need more pin, and the MBC chip would have to be bumped up from QFP32 (32 pin quad flat package) to the next standard size of QFP44, adding 12 more pins. This would cost more to manufacture, and take up more board area, so they probably decided against it. Other than the physical changes, just adding more address bits would be a trivial change to the design.