Previous Thread
Next Thread
Print Thread
Joined: Jan 2021
Posts: 45
Likes: 28
R
Member
OP Offline
Member
R
Joined: Jan 2021
Posts: 45
Likes: 28
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?

Joined: Feb 2004
Posts: 2,416
Likes: 129
Very Senior Member
Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,416
Likes: 129
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.

Joined: Feb 2004
Posts: 2,416
Likes: 129
Very Senior Member
Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,416
Likes: 129
BTW the Pro Action Replay ROM is already in the gameboy.xml as “par” IIRC, it just doesn’t work.

Joined: Jan 2021
Posts: 45
Likes: 28
R
Member
OP Offline
Member
R
Joined: Jan 2021
Posts: 45
Likes: 28
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.

Last edited by Revenant; 09/12/22 10:47 PM.
Joined: Feb 2004
Posts: 2,416
Likes: 129
Very Senior Member
Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,416
Likes: 129
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.

1 member likes this: Revenant
Joined: Mar 2006
Posts: 1,074
Likes: 5
L
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,074
Likes: 5
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


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Joined: Jan 2021
Posts: 45
Likes: 28
R
Member
OP Offline
Member
R
Joined: Jan 2021
Posts: 45
Likes: 28
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.


Link Copied to Clipboard
Who's Online Now
2 members (Vas Crabb, Olivier Galibert), 22 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,131
Posts119,647
Members5,029
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com