Home Page Forums MAME MAME GB/GBC carts with a passthrough slot

Earlier today I dumped a used GBC GameShark Pro and started working out some basics about its custom mapper. By coincidence, right after that it looks like the GB cart system just got overhauled, so I'm trying to figure out how I should go about adding a new cart type that can have a second cart attached to it.

My initial instinct would be to override device_start for the new cart class and then install a view over 0x0000-7fff at startup time (rather than at load time) to make sure that the view is installed after the other cartridge installs its normal read/write handlers, but I'm not sure if that's totally correct/necessary. Is there a generally recommended way to do this sort of thing?

It’s kind of messy due to the way the bootstrap gets mapped in. The LR35902 CPU core is screwing us over in two ways. It effectively implements GBC fast/slow mode as a multiplier rather than a divider (internally dividing the cycles per opcode), and it does bootstrap accesses via the program space. This means we can’t properly expose the phi clock to cartridges for things that depend on it, and bootstrap accesses are exposed to the bus when they shouldn’t be.

The most obvious side effect of the latter is that taps don’t work right at boot time. An address space tap on the program space shouldn’t see bootstrap ROM accesses, but it does, so cartridges need to use trampolines rather than taps for monitoring bus accesses during boot.

Then you add to this the mess of how start, load and reset work. All the devices besides the root machine are started before media images are loaded, but reset happens after everything has started, and hence after all the loads complete.

Whichever way you do it, you’re likely going to end up with your view interfering with the view used to map in the bootstrap ROM, which of course shouldn’t be using a view because it isn’t accessed through the address space in the first place, but doing it properly without going through the address space and also not having to do a test on every memory access (hence tanking performance) would require substantial work on the LR35902 core.

Then you have to consider whether the cartridge in the piggypack slot can see accesses when the GameShark has its own ROM mapped in, so taps work correctly.

TL;DR I don’t think it’s going to be easy.

BTW the Pro Action Replay ROM is already in the gameboy.xml as “par” IIRC, it just doesn’t work.

If that's the case, then I might just do a partial implementation that leaves out the additional slot for now, just for the sake of documentation/experimentation and getting the menu itself to run. (edit: or maybe not - I briefly forgot that the GS needs to be able to pass through the other cartridge's header in order to actually boot)

I also have some old research notes about SNES cheat devices and copier hardware that I'd like to try implementing at some point, hopefully that'd be a little more feasible.

There’s a machine configuration option for the Game Boy to patch out the header check that should get it to boot at least. It only works with the regular Game Boy with the default BIOS, but it should be enough to get started with.

The action-replay-derived Gameboy/GBC gameshark had several hardware revisions, I'm not sure which ones are dumped and which are not; the v3 and v4 gameshark hardware use internal flash rom to both hold its own firmware and allow 'saving state', as well as uploading the internal saved state to a windows 95/98 machine via a parallel port and saving new ones back to the cart. it is surprisingly easy to brick the device by using a gameshark v3 savestate on a gameshark v4 cart or vice versa!

LN

The one I've dumped is the v3.0 cart with the black shell, I don't know of any (good) dumps for it. I'll upload the ROM and some basic mapper notes soon.

The older "gameshrk" ROM (v2.1?) in the GB softlist also needs redumped, the current ROM just repeats the initial 16kb.