Game Gear on Mega Drive idea

Published on 2020-jul-13

One of the Mega Drive features is being able to run Master System games with an adapter. The Game Gear is mostly a handled Master System, but it has enough differences that playing those games on a Mega Drive isn't feasible (colors are all wrong, and also the Start button doesn't work so most games can't go past the title screen).

Some time ago krikzz revealed the Mega Everdrive Pro's features and one of the things is does is running NES games. It works by having part of the NES running on its FPGA and letting the Mega Drive handle video output. Now, this is just a "bonus" feature and it doesn't work great (CHR-ROM bank switching is a big problem), but for many games it should be good enough.

On the other hand this also got me wondering if it'd be feasible to take the same approach with the Game Gear. Its VDP is significantly less flexible than the NES PPU, so maybe the results could be better?

So here's an idea of how I think it could work (feel free to copy them). Note that the goal here is to try making most games work, but it's not gonna be 100% perfect unless take over the video output with a passthrough cable like the 32X.



The graphics would work as follows:

On VRAM/CRAM accesses:

On the tilemap layer:

On sprites:

On the palette:


68000 would be reading the controller every frame and passing its buttons to the Game Gear core. D-pad would be mapped as-is, B and C to buttons 1 and 2, and Start to… Start.

Probably nobody will bother with the Gear-to-Gear cable, but if you *really* insist, the port used by it is practically the same you can find on the Mega Drive itself (serial mode included!), so you could attempt to pass it onto the player 2 port… but you'd need a custom cable, another Game Gear or Mega Drive, and timing may make it unfeasible anyway.


Alternatively, you could implement a stereo PSG in the cartridge itself and push its output through the audio-in lines in the cartridge slot, which solves all the issues (but wouldn't be as fun :P).

Compatibility issues

Now obviously the above shows that compatibility isn't going to be perfect, and I'm not that well versed on the Game Gear catalog, but I can think of a few cases that are obviously problematic:

Super Game Boy approach

On the other hand we could take Nintendo's approach which was to put the entire hardware in the cartridge and treat the console as a glorified passthrough that just passes over controller inputs. Audio can go through the audio-in lines in the cartridge slot, so that isn't a problem.

Video is another issue. Display is 160×144, but Game Gear can output up to 31 colors (which won't fit in a single tile) so we need to send *two* screenfuls. That'd be 720 tiles to transfer. That'd require extending vblank to get all the bandwidth we can, which means the border will have to be a solid color. Assuming 320×224, that'd require 117 lines to transfer (ignoring overhead). With the extra vblank time we get from disabling display in the border we get… 112 lines (in NTSC). Oops.

Many Game Gear games push against the borders of the screen, so trying to remove lines is probably not an option, which means you'd need to get accustomed to tearing. You could try to optimize by avoiding sending tiles that haven't changed or don't need both palettes, though it only reduces the chance of it being an issue and would be harder to implement.

Oh, and don't forget about the palettes. Again, the above was all assuming the palette doesn't change mid-screen, which breaks some raster effects. Trying to transfer 31 colors per line is not easy. You could probably disable display mid-line (the borders to the sides really help here), but even then expect to still see a few CRAM dots on the sides of the screen.