Skip to content

Sega Genesis / Mega Drive Recompilation Landscape

Companion docs: ps3-recomp.md, ps2-recomp.md, psx-recomp.md, amiga-recomp.md, ps4-recomp.md. This doc complements amiga-recomp.md’s m68k coverage and corrects/expands the Genesis aside it made in passing.

1. CPU: the same 68000, a different neighborhood

Section titled “1. CPU: the same 68000, a different neighborhood”

The Genesis’s main CPU is a Motorola 68000 running at ~7.6MHz — the same core family covered in depth in amiga-recomp.md §1: clean, orthogonal, decades of GCC/Ghidra/IDA support, no ISA-level obstacle to lifting. That analysis carries over directly; it isn’t repeated here.

What differs is the platform around the CPU. Amiga games fight the chipset — Copper and Blitter running in lockstep with video timing, which is the actual hard part of Amiga recompilation (see amiga-recomp.md §2). The Genesis’s video/DMA hardware (the VDP) is comparatively closer to a conventional memory-mapped device — programmed through command/data ports rather than a beam-synchronized microprogram — so it doesn’t impose the same “must model a second timing-critical processor just to draw a frame” tax. Genesis’s equivalent complexity isn’t chipset timing, it’s a literal second CPU: the Z80, covered next. (Copetti: Mega Drive/Genesis architecture)

2. The second processor: Z80, plus the one-off SVP exception

Section titled “2. The second processor: Z80, plus the one-off SVP exception”

Alongside the 68000, the Genesis carries an independent Zilog Z80 at ~3.5MHz with its own 8KB RAM, primarily driving the YM2612 FM synth and the SN76489 PSG (the latter inherited from the Master System, which is also why the Z80 is what makes Genesis-hosted Master System backward-compatibility mode work). The two CPUs have no inherent awareness of each other: the 68000 writes a program into the Z80’s RAM and asserts the Z80’s reset line to start it running, and a bus arbiter stalls one side or the other since both can’t own the shared bus simultaneously. (Copetti)

This is real second-execution-context complexity for a recompiler — an independent instruction stream, its own memory space, its own timing relationship to the main CPU — but it’s narrower in scope than the SNES’s SPC700+DSP audio subsystem or the vector units on PS2/PS3 (see ps2-recomp.md, ps3-recomp.md): one small 8-bit CPU running a comparatively short driver, not a DSP with its own instruction set doing general audio synthesis in software, and not a processor asymmetry that blocks CPU-side gameplay logic the way SPU code can on PS3.

The one real analog to SNES’s “coprocessor per cartridge” problem is the SVP (Sega Virtua Processor) — a rebranded Samsung SSP1601 16-bit fixed-point DSP bolted onto the Virtua Racing cartridge to compute 3D polygon math the base hardware couldn’t, direct competition for the SuperFX chip on SNES’s Star Fox. It shipped in exactly one game (cost made it a one-off — Genesis Plus GX and other high-accuracy emulators had to implement dedicated SVP support to run it at all) and otherwise the Genesis library has no per-cartridge-coprocessor problem to speak of. (HandWiki: SVP, Time Extension on SVP cost)

3. Prior art: a mature disassembly scene, and — now — a real recompiler

Section titled “3. Prior art: a mature disassembly scene, and — now — a real recompiler”

Genesis has the deepest m68k disassembly scene of any retro platform, anchored by Sonic Retro’s labeled, byte-identical-reassembling disassemblies: s1disasm, s2disasm, and similar community projects for Sonic 3 & Knuckles and other titles. It’s important to be precise about what these are: annotated assembly disassemblies, not decompilations. They convert ROM bytes to labeled 68k mnemonics that reassemble byte-for-byte, not to human-authored-looking C. That said, this is a smaller gap than it sounds — most commercial Genesis games (Sonic titles included) were hand-written in 68k assembly to begin with, since usable C compilers for the 68k didn’t arrive in the homebrew scene until much later (see SGDK). There is no lost “original C” for a decompiler to recover; a complete, labeled disassembly is close to the ceiling of what reconstruction can offer for these titles, unlike PS1/PS2 games compiled from C where decompilation targets a genuinely higher representation (psx-recomp.md, ps2-recomp.md).

Static recompilation proper — 68k lifted to native/C code, not reassembled 68k — is thinner but real, and the picture has moved since the earlier pass on this topic. matiaszanolli/aerobiz-disasm and matiaszanolli/sega-vr-disasm (Virtua Racing on 32X, 164 stars) both carry GitHub’s static-recompilation topic and repo descriptions using that term, but their own READMEs describe the work as disassembly-and-reassembly to a byte-identical ROM — the labeling is aspirational, worth flagging rather than taking at face value.

The more consequential find is SegaGenesisRecomp (Matthew Stanley, part of the “R.A.I.D.” AI-assisted retro decomp/recomp Discord community — see his 1379.tech writeup), a genuinely general-purpose Genesis static recompiler: it decodes 68k instructions and emits equivalent C, one function per subroutine over an M68KState/memory model, with per-instruction cycle accounting for VBlank timing and an experimental Z80-to-C backend documented separately. Sonic 1 (Green Hill Zone fully verified), Sonic 2, and Sonic 3 & Knuckles are playable, with later zones filled in progressively; it optionally reassembles Sonic Retro’s disassemblies as input for widescreen builds, then recompiles that. It’s young (530+ functions discovered so far, 16 stars, PolyForm Noncommercial license) and Sonic-specific today, but it is a real “Genesis: Recompiled”-shaped tool, not disassembly relabeled.

No general m68k-ISA recompiler spanning both Amiga and Genesis turned up — despite the shared CPU, all effort stays platform-siloed (memory map, VDP/Z80 model, and cycle timing differ enough from Amiga’s chipset that nobody has tried a shared translation core).

The dynamic-emulation baseline is mature and well ahead of any static effort: BlastEm is the accuracy-and-speed reference (cycle-accurate CPU sync, passes all 122 of Nemesis’s VDP FIFO tests alongside Exodus, excellent YM2612 timing including channel “leakage” on real hardware), Genesis Plus GX is the broad-compatibility standard used across libretro/RetroArch with dedicated SVP support, and Exodus was an early cycle-accurate effort whose YM2612 research Genesis Plus GX has since absorbed.

Genesis is ahead of Amiga here, but by less than the disassembly scene’s fame suggests once the tiers are separated correctly. Sonic Retro’s work is the best-in-class disassembly corpus of any 8/16-bit platform — arguably at or near the ceiling for hand-written-assembly titles, since there’s no lost C source underneath to make disassembly a lesser substitute for — but disassembly is not recompilation, and conflating the two (as the static-recompilation-tagged aerobiz/sega-vr repos do) overstates the field. What actually moves the comparison to Amiga is SegaGenesisRecomp: a real, general, actively-developed C-lifting static recompiler with multiple playable titles exists for Genesis and has no Amiga counterpart at all (amiga-recomp.md §3 found essentially nothing on-platform). It’s early — closer to PS3’s “early but real” tier than PS2’s OpenGOAL polish, and narrower than N64Recomp’s generality — but unambiguously further along than Amiga, where WHDLoad and UAE-family JIT dominate and no static recompiler for any title exists. The head start from Sonic Retro’s disassembly corpus, plus a smaller “second processor” surface (a Z80 audio driver vs. Copper/Blitter racing the beam), appear to be exactly what let Genesis reach a working general recompiler first.