Game Gear on Mega Drive idea

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.

Core

• Would work like the NES support in the Mega Everdrive Pro, with a Z80 core + I/O ports in the cartridge. Kinda wasteful when there's already a Z80 in the console itself, but I can't see any other way this could work.
• 68000 would be in charge of interfacing between the Z80 core and the rest of the Mega Drive. The core would convert some of the stuff on the fly (as well as some logging) so the 68000 can move around data directly as-is.

Video

The graphics would work as follows:

• Mega Drive VDP would run in mode 5.
• Game Gear sprites would be done with sprite layer (low priority).
• Game Gear tilemap would be done with plane B layer (both priorities).
• Plane A (high priority) would be used to draw a border around the Game Gear's viewport.

On VRAM/CRAM accesses:

• Game Gear doesn't have DMA and is slower than the Mega Drive at writing to video memory, so hopefully time isn't an issue. The 68000 can't really track all the writes being done so it may be best to make a log and then let the 68000 process them all at once.
• On the other hand, data in VRAM could be either a tile or part of a table, and trying to guess from the register values may not be a great idea (tile graphics may be written in a tilemap area where it doesn't display them), so we may need to write all VRAM data twice (once as tile, once as table).
• The above also implies that tables will need to be allocated separately from tiles. Thankfully the Mega Drive has more than enough VRAM for this (64KB vs. 16KB).
• Mode 4 (Game Gear) uses planar while mode 5 (Mega Drive) uses chunky, so tiles would need to be converted on the fly.
• Tables are also in different formats, so that would need to be converted as well. Tilemap writes probably can be converted and written as is (some bits are shuffled around), but the sprite table is another matter. May be better to buffer the sprite table in the cartridge and convert it all in one go to transfer to VRAM once a frame.

On the tilemap layer:

• Game Gear tilemap is 32×28, which is kind of an issue since Mega Drive's VDP only does powers of two. Probably the best idea would be to use 32×32, then do a raster effect where vscroll is changed mid-screen at the appropriate line in order to cut out the excess 32px.
• Game Gear's VDP can't change vertical scroll mid-screen (the write latches but doesn't take effect until next frame), only horizontal, so that makes things simpler. It'd be probably best to log writes to the horizontal scroll register and then let the 68000 take the log and load it to the horizontal scroll table. This requires horizontal scroll to be in line scrolling mode.
• Master System has a feature where the top and/or right of the tilemap can be fixed (instead of scrolling), but they're off screen in the Game Gear's case so we can ignore it.

On sprites:

• Mode 5's sprite capabilities should hopefully be enough. We need 64 sprites, and sprites can be either 8×8 or 8×16.
• Mode 5 would require 20 sprites to hit the sprite limit per line, while mode 4 only needs 8. This may result in some clipping effects not working. On the other hand, it'll also prevent flickering in many games, so whether it's a problem or not is up to you.
• MAG bit doesn't work at all on Mega Drive, so we probably can't support this feature. I don't think it's used much on Game Gear anyway? (only one game comes to mind that would suffer heavily, and that one has a workaround)

On the palette:

• Colors would need to be dropped to 3-bit per component (Game Gear does 4-bit). It looks worse, but it's the best we can do realistically and Game Gear can't display many colors on screen, so there shouldn't be too many issues over soft gradients.
• Changing the palette mid-screen may be a bigger problem, though I think that for most games you can get away with just delaying them until vblank anyway.

Input

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.

Audio

• 68000 would take the current volume and pitch of every channel and pass them to the Mega Drive's PSG once a frame. This means PCM playback won't work (though it's rarely ever done), but otherwise should be fine in practice.
• Stereo would be ignored, since the Mega Drive's PSG is mono only. Not nice but it's far from the worst problem we could have. Bear in mind that some games mute PSG channels by disabling both speakers (instead of setting volume to quietest), so you still need to check for that.

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:

• Sonic Blast uses raster effects to do the sky gradient in the first zone, so expect the sky to become a flat color instead.
• The lack of MAG sprite support means that Virtua Figther Mini won't look right unless you force the camera to be zoomed out.
• A few games do weird stuff with the tilemap address for HUD purposes which may or may not break. Not exactly common, but worth mentioning.

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.