Sega Saturn Static Recompilation Landscape

A general survey of native-code static reconstruction (in the N64: Recompiled / Zelda 64: Recompiled sense) for the Sega Saturn, not tied to any specific game. Companion docs: ps3-recomp.md, ps2-recomp.md, psx-recomp.md, amiga-recomp.md, ps4-recomp.md.

1. Architecture: a fractured, asymmetric multi-processor design

“Fractured” fits the hardware. The Saturn is built from at least six independently-clocked, independently-programmed units rather than one dominant CPU with helper coprocessors (Copetti, Umbra Dynamics):

• Two Hitachi SH-2 CPUs (~28.6 MHz) in master/slave configuration. SH-2 itself is clean, well-documented RISC — Ghidra/IDA support it natively, and a modern GCC toolchain still targets it (Saturn-SDK-GCC-SH2). The hard part isn’t decoding opcodes; the two cores share one external bus and main RAM, so throughput doesn’t double, and efficient code has to hand-partition work and manage cache/bus contention between them — a real synchronization problem with no single-core analog.
• The SCU (System Control Unit), per Sega’s own SCU User’s Manual, arbitrates the SH-2 bus against the cart/CD-block A-bus and the VDP/SCSP B-bus, with its own DMA controllers and an onboard fixed-point DSP for matrix/geometry offload, backed by 32KB local SRAM. Retail titles used it mainly for matrix transforms; developer notes confirm even Sega’s official SCU-DSP documentation contained known errors (SegaXtreme).
• VDP1 (sprite/quad/polygon rendering) and VDP2 (background/tilemap, up to four rotating/scaling 2D planes plus one 3D-capable plane — five simultaneous planes — rendered scanline-by-scanline with no frame buffer) (Copetti).
• A dedicated Motorola 68EC000 running sound drivers for the Yamaha SCSP, a 32-channel PCM/FM chip with its own onboard effects DSP.

That’s two general CPU ISAs, two more programmable/semi-programmable DSPs, and two unrelated video paradigms on segmented buses built to avoid contention. This is a more fractured, heterogeneous design than PS3’s Cell — Cell is one PPU plus up to six architecturally-identical SPUs under one design philosophy; Saturn’s units differ in kind (two ISAs, two DSPs, two incompatible rendering models), not just count.

Why VDP1 resists the RSX/GCM-style “translate the command stream to a modern API” approach: RSX and GCN both speak triangles, so retargeting their command buffers to Vulkan/D3D12 is a same-primitive translation. VDP1 is built around quads as its native primitive, with hardware-specific rasterization rules (both the right and bottom edges of a quad are drawn, unlike the top-left-only rule standard GPU rasterizers use) and forward, unfiltered texture mapping. Splitting each quad into two triangles for a GPU visibly breaks: texture interpolation distorts across a seam VDP1 never had, and single-pixel edge/gap errors invisible at native resolution become obvious once upscaled. This is a live, current problem, not historical — as of mid-2026 the Yaba Sanshiro emulator rewrote VDP1 to use compute shaders, running one GPU thread per output pixel to replicate VDP1’s exact rasterization rule directly rather than using the GPU’s built-in triangle rasterizer at all (Yaba Sanshiro writeup, coverage); Kronos independently reached the same conclusion earlier with its own compute-shader “CS core” (libretro). The primitive model itself is the mismatch — a GCM/RSX-style command-stream retarget doesn’t carry over.

2. Why accurate emulation itself took unusually long

Saturn’s reputation for lagging PS1/N64/Genesis emulation by years traces directly to the architecture above: two CPUs to keep synchronized, a DSP whose own manual has known errors, and a GPU whose rendering model doesn’t map onto a conventional rasterizer, all under tight real-time timing many titles depended on (GenerationAmiga, Ggwp Academy). Where the community landed:

• Yabause — the original open, cross-platform baseline (early-2000s). Broadly compatible but historically the least accurate actively-used option; its SH-2 core originally used a dynamic recompiler purely for speed, not static translation (wiki).
• Kronos — an actively maintained Yabause fork (since ~2018) adding compute-shader rendering specifically to exceed OpenGL’s fixed-rasterizer accuracy ceiling (release notes).
• SSF — closed-source, Windows-only, single-developer (“Shima”). For most of Saturn emulation’s history, widely regarded as the most accurate and fastest option available — notable given it’s closed freeware, not a community project (Emulation Wiki).
• Mednafen’s Saturn core (“Beetle Saturn”) — now generally the accuracy reference, but explicitly still under active development and, per its own docs, “extremely CPU intensive” (officially wants a >=3.3GHz quad-core Haswell-class chip), and deliberately narrow — one BIOS revision per region (Mednafen docs).

Read honestly: Saturn emulation is mature but still expensive and still moving at the accuracy frontier — VDP1’s rasterization was still being re-engineered (the compute-shader rewrites) in 2026, three decades post-release. That’s a later maturity curve than PS1, N64, or Genesis all reached years earlier.

3. Recompilation/decompilation prior art: essentially nothing found

• No Saturn-specific static recompiler exists. GitHub’s static-recompilation topic — the same list containing PS2Recomp, sega-vr-disasm (32X), and aerobiz-disasm (Genesis) cited in the companion Amiga doc — has no Saturn, SH-2, SuperH, or Hitachi entry.
• No generic SH-2 static-recompilation tooling was found, on-Saturn or off. SH-2 is a real automotive/embedded ISA (Renesas still sells SH-2/SH-2A parts for ECU work), but tooling there is conventional embedded development — Renesas’s own compiler package, disassemblers like sh2dis (built for Mitsubishi Evo ECU reversing) — nothing resembling a binary-to-native-executable recompiler. Nothing suggests automotive SH-2 work is adaptable beyond “the instruction decoder is solved,” which is the easy part of any recompilation effort regardless (see the Amiga doc’s identical conclusion about m68k).
• Reverse-engineering exists but is early and narrow. Reverse-Engineer-Azel is an active single-developer decompilation of Panzer Dragoon Saga (individual files 8–74% decompiled) but is explicitly archival/educational, not aimed at a runnable port. sotn-decomp nominally targets Castlevania: SotN across PSX/PSP/Saturn, and RecompOne (surveyed in psx-recomp.md) partly bootstraps from it — but the repo’s progress tracking is PSX-file-centric, with no comparable Saturn completion metrics published.
• Tooling exists for reading Saturn binaries, not translating them. A community Ghidra Saturn loader and Ghidra’s upstream SH-1/SH-2 processor module make disassembly practical but are purely analytical. VDP1/VDP2 command-list documentation exists for homebrew authors writing new code for real hardware (e.g. saturn-libs), not for lifting or translating existing command streams independent of a full emulator.

Nothing found rises to a general SH-2-to-native static recompiler, a VDP1/VDP2 command-stream translator independent of a full emulator, or a single-game project pursuing static recompilation rather than decompilation or dynamic JIT emulation. That absence is real, reported plainly, not padded.

4. Honest maturity assessment, ranked against the other five docs

1. PS2 (OpenGOAL/jak-project) — mature and shipping, but franchise-specific; works because Naughty Dog’s GOAL bytecode is unusually decompilation-friendly.
2. PSX — a mature, broad decompilation scene plus an emerging 2026 wave of general binary-level static recompilers (ps1-recomp, RecompOne); no single dominant tool yet, but real momentum both ways.
3. PS3 (ps3recomp) — early but real: an active general static recompiler with several partial playable ports, pre-1.0 but demonstrably more than a proof of concept.
4. PS4 — categorically different problem; recompilation isn’t the right frame given the x86-64 target and encrypted/signed executable model, so HLE emulation is the only viable approach.
5. Amiga — essentially unstarted for static recompilation specifically; WHDLoad (patch-and-load) and UAE-family JIT (dynamic, not static) already deliver near-native results through non-recompilation means, so no chipset-aware static translator exists for any title.
6. Saturn — at or arguably below Amiga’s level, for a related but distinct reason. SH-2, like m68k, isn’t the obstacle — it’s clean, documented, well-tooled RISC. But Saturn lacks even Amiga’s saving graces: no WHDLoad-equivalent patch-and-load ecosystem, and more importantly, accurate dynamic emulation itself is still a live, unsettled problem (VDP1’s rasterization was being fundamentally re-architected via compute shaders in 2026; Mednafen’s reference core remains CPU-intensive and actively developed). Static recompilation presupposes a solid, frozen understanding of correct hardware behavior to translate against; Saturn’s chipset hasn’t been fully nailed down even for emulation. Where Amiga’s problem is “the technique hasn’t been attempted despite a well-understood target,” Saturn’s compounds that with “the target itself is still being pinned down.” No evidence of any static-recompilation attempt was found — the honest read is unstarted, and arguably further from ready than Amiga, because the prerequisite groundwork (a settled, accurate hardware model) that Amiga already has from UAE’s decades of maturity, Saturn does not yet fully have even in emulation form.