SNES / Super Famicom Static Recompilation — State of the Art

A general survey of static/ahead-of-time recompilation for the Super Nintendo Entertainment System, independent of any specific game. Companion docs: psx-recomp.md, ps2-recomp.md, ps3-recomp.md, ps4-recomp.md, amiga-recomp.md.

CPU architecture: the WDC 65816 is the easy part

The SNES’s main CPU (Ricoh 5A22, built around a WDC 65C816 core) is a 16-bit extension of the 6502/65C02 family — the same lineage as the NES, Apple II, and (in genuinely-shared-silicon form) the Apple IIGS (WDC 65C816). Like m68k for Amiga (see amiga-recomp.md), it’s a single in-order core with no on-chip vector/SIMD analog to PS2’s VU1 or PS3’s SPUs, and it inherits decades of 6502-family tooling: mature disassemblers (DiztinGUIsh, Dispel), cross-assemblers, cycle-accurate emulator cores to validate against, and a C cross-compiler lineage via cc65. The 65816’s variable-width accumulator/index registers (8-bit vs. 16-bit, toggled at runtime via REP/SEP) are a real static-analysis wrinkle — a recompiler has to track M/X width state through control flow to know how wide a given LDA actually is — but this is solved, not a research question. As with m68k, if the SNES’s difficulty were “just the CPU,” this would already be an easy platform.

The real complexity: per-cartridge coprocessors

It isn’t, because the SNES took a different path than the Genesis or PS1: rather than expanding the console, Nintendo let publishers embed dedicated coprocessor silicon inside the cartridge itself when the base 5A22/PPU pair wasn’t enough (see the Super Famicom Dev Wiki’s expansion-chip list and jsgroth’s SNES coprocessor writeup). The major ones:

• DSP-1 (and DSP-1B/-2/-3/-4) — an NEC µPD7725 fixed-point DSP for vector math and 2D/3D coordinate transforms, e.g. the road-curve calculations in Pilotwings and Super Mario Kart.
• SuperFX/GSU — a genuine RISC chip, not a fixed-function accelerator, doing real polygon rasterization: Star Fox’s 3D wireframe/filled-poly rendering, Yoshi’s Island’s inflated-sprite effects, and the SNES port of Doom.
• SA-1 — a second, faster 65816 core sharing the cartridge, its own IRAM/DMA and bank-switching tricks (Super Mario RPG, Kirby Super Star).
• Compression/mapper chips — S-DD1 (Nintendo’s lossless decompressor for the huge sprite data in late titles like Star Ocean), SPC7110 (Epson decompression+banking, a handful of Hudson titles, sometimes paired with an RTC), and Cx4 (Hitachi math coprocessor Capcom used for wireframe/rotation in Mega Man X2/X3).

This is structurally the SNES’s version of “the hard part” that every platform in this survey has in some form — PS3’s SPUs, PS2’s VU1, Amiga’s Copper/Blitter — except the coprocessor here isn’t fixed console hardware a recompiler models once. It’s per-cartridge, chosen by the publisher, different title to title. A general SNES recompiler can’t write “the coprocessor” support once and be done; it has to accumulate chip-by-chip support, the way ps3recomp accumulates HLE modules (see ps3-recomp.md), except the variance axis is cartridge hardware rather than OS surface area.

The SPC700: a second, smaller processor problem

Layered on top is the S-SMP: an 8-bit SPC700 CPU (6502-like, its own tiny ISA) paired with an 8-channel BRR-sample DSP and 64KB of dedicated SRAM, running independently of the main 65816 and communicating only through four shared I/O ports (SNESdev S-SMP, SPC-700 programming reference, emudev.de walkthrough). It’s the same shape of complexity as Genesis’s Z80 audio coprocessor or Saturn’s dual-SH2-plus-audio split — a second CPU a recompiler must model or run alongside the main one — just smaller in scale, since it’s fixed console hardware (unlike the cartridge chips above) and its job (drive the DSP, mix 8 BRR channels, apply echo) is narrower than a general-purpose coprocessor’s.

Prior art: a mature disassembly scene, one real general recompiler

SNES has one of the most mature disassembly scenes of any retro console — but it’s worth being precise about what that means here, more so than for N64/PSX. Most commercial SNES games were hand-written in 65816 assembly, not compiled from C, so the N64/PSX-style “decompile to C that re-compiles byte-identical” paradigm doesn’t really apply — there’s no original compiler output to match. What exists instead is reassembling-exact disassembly: SMWDisC and galaxyhaxz/smw-src (both archived, both assemble to the byte-exact Super Mario World ROM), and comparable efforts for Super Metroid (strager/supermetroid, metroidret). A Link to the Past went a step further: snesrev/zelda3 (4.7k stars) is a from-scratch C reimplementation built with reference to spannerism’s ALttP disassembly — a native, cross-platform port that can optionally run the original 65816 code alongside its C for frame-by-frame RAM verification — but it’s not a byte-identical-recompiling decompilation in the strict sense, and it needs ROM assets extracted at build time. Chrono Trigger has no comparably complete public disassembly. decomp.me has no 65816 target, consistent with the “mostly hand-assembled, not compiler output” point above.

A genuine general-purpose static recompiler does exist: SNESRecomp (part of “R.A.I.D.” — Retro AI Development — a community also running psxrecomp, nesrecomp, and Game Boy/N64 recomp forks) statically analyzes a ROM’s control flow, tracks 65816 M/X width state, emits C, and falls back to an interpreter tier for anything it can’t prove. It’s alpha software (repo created March 2026) with three public game ports — Super Mario World (“playable end to end”), A Link to the Past (early dungeon), Mega Man X (fully playable) — and explicit per-chip coverage: LoROM/HiROM/FastROM, Cx4, SuperFX/GSU (validation target: Star Fox), DSP-1/1B, and SA-1 are supported; S-DD1, SPC7110, OBC-1, ST010/011/018, and BS-X/Sufami Turbo adapters are not. A separate, complementary project, sp00nznet/snesrecomp, takes the ps3recomp-style approach of packaging a real emulator’s hardware backend (a fork of LakeSnes) as a linkable “drop-in hardware” library, rather than shipping an analyzer/emitter itself. No independent, outside-any-emulator SuperFX/GSU reimplementation turned up beyond a Ghidra SLEIGH module for disassembly and its native support inside SNESRecomp and FPGA SNES cores (MiSTer, Analogue Pocket) — it hasn’t been extracted as a standalone project the way an N64 RSP microcode has been.

Reference emulators

bsnes/higan (Near) is the field’s reference implementation, in the same role RPCS3 and PCSX2 play for PS3/PS2: bit-perfect to a real SNES’s digital output before the DAC, and the first emulator to reach 100% catalog compatibility including SuperFX, SA-1, and DSP-1 titles — born from chasing a Der Langrisser bug that only manifested on real hardware. Snes9x and Mesen-S are the mature, practical alternatives — faster and more widely deployed, with Mesen-S oriented toward debugging tooling, neither claiming bsnes’s hardware-verified accuracy.

Honest maturity assessment

SNES sits closer to the PS3 end of this survey’s spectrum than any other companion doc: early but real, with a working general framework and multiple playable titles — not “essentially unstarted” (Amiga), not “categorically HLE-only” (PS4). It’s arguably ahead of PS3 in breadth of validated per-title coprocessor coverage relative to project age (SNESRecomp shipped three titles spanning three coprocessor classes within months), precisely because a SNES cartridge carries at most one active coprocessor versus PS3’s up-to-six general-purpose SPUs — but it inherits PS3’s same open question of whether “general” ever means any game, given the long tail of unsupported chips (S-DD1, SPC7110, the ST-01x DSPs). Unlike PSX, SNES’s disassembly scene, however mature, mostly stops at reassembling-exact disassembly or from-scratch reimplementation rather than compiler-matching decompilation — because most SNES games were never compiled from C to begin with.