SNESRecomp: A Static Recompiler That Turns SNES ROMs Into Native Code

The Problem: Emulation Overhead vs. Native Ports

Full-system emulators for the SNES interpret or dynamically recompile the 65816 CPU on every frame. That approach is flexible, but it leaves the game code running inside a virtual machine, which makes deep modifications like true widescreen rendering or custom camera logic awkward. SNESRecomp takes a different path: it statically translates the game's 65816 machine code into C, then compiles that C into a native executable. The result is game logic that runs as native code, not inside an emulator. The intended audience is developers who want to produce a playable, distributable port of a specific SNES game, with modern features like widescreen, save states, and MSU-1 audio. It is not aimed at people who just want to play a ROM on their PC; it is a toolchain for building a port.

The Four-Stage Pipeline: From ROM to Native Executable

The README describes a four-step process. First, an analyzer discovers code in the ROM. It follows control flow, tracks the 65816 M/X width state (the CPU's accumulator and index register widths), and resolves direct and indirect dispatch where it can. Second, an emitter translates the discovered 65816 functions into portable C. Third, a normal C compiler builds that C output together with a shared runner and game-specific integration code. Fourth, at runtime, any code that could not be resolved statically falls through to an interpreter tier. That interpreter is a safety net: it prevents unresolved or dynamically reached code from becoming a correctness hole. This hybrid design means the original game logic remains the source of truth, but the CPU portion runs natively. The runtime models the PPU, APU, DSP, DMA, cartridge mapping, and supported enhancement chips.

Getting Started: What You Need to Build a Port

The repository is a framework, not a single binary you run. The v0.2.0-alpha release is described as a self-contained ROM-to-source CLI, which suggests you can point it at a ROM and get C source out. But the README is clear that each game needs its own analysis configuration and integration code. The companion game repositories (SuperMarioWorldRecomp, ZeldaAlttPSNESRecomp, MegaManXSNESRecomp) pin a known framework revision and ship their own ROM-free releases. To build a new game, you would clone one of those as a template, or start from the framework and write the integration layer yourself. The exact commands are not in the provided material, so you must read the game repositories for build instructions. The framework accepts headerless .sfc and copier-headered .smc images for standard LoROM and HiROM, which is useful for testing with your own dumps.

Supported Hardware: What the Runtime Actually Models

The cartridge mapping and enhancement chip support is the heart of the project. Standard LoROM and HiROM, with FastROM variants, are supported, including battery-backed SRAM mapping. The Capcom Cx4 chip (used in Mega Man X2 and X3) has instruction-level support, and its internal data ROM is synthesized, so no separate firmware file is needed. The Super FX / GSU chip is supported, with Star Fox as the current development validation target. The DSP-1 / DSP-1B is supported for Super Mario Kart, with a firmware-free command model. The SA-1 chip is supported for Super Mario RPG, with a long list of implemented features: ROM-bus arbitration, Super MMC banking, IRAM/BW-RAM, timers, DMA, and variable-bit reading. MSU-1 is supported but opt-in: the extension's registers and data channel are implemented, but a game must integrate its own MSU-1 driver. This is a significant amount of hardware modeling, but it is not universal.

The Long List of Unsupported Chips and Mappings

The README is unusually honest about what does not work. ExLoROM, ExHiROM, and other custom mappings are not supported yet. The DSP-2, DSP-3, and DSP-4 chips are not supported, even though they use the same NEC family interface as the DSP-1. The S-DD1 decompression chip is not supported, which rules out games like Star Ocean and Street Fighter Alpha 2. The SPC7110 and its RTC are not supported. OBC-1, ST010, ST011, ST018, and S-RTC are all absent. BS-X, Sufami Turbo, and Super Game Boy adapters are outside the current mapper model. Worse, the README warns that some unsupported cartridges may load as plain LoROM or HiROM images because header detection gets that far, but their unmodeled register windows will still prevent correct execution. This is a real failure mode: you might think a game is running, but it will crash or behave incorrectly because a coprocessor is silently ignored.

Validation and Quality: What the Tests Actually Prove

The project does not rely on vague claims. For the DSP-1, the README mentions unit and differential command gates, a deterministic one-player race that matches Snes9x WRAM/DSP behavior and framebuffer output within renderer rounding, and a canonical 36,000-frame LLE/HLE attract qualification. For the SA-1, an 18,000-frame attract-loop qualification passes without runtime, logic-activity, video-activity, or audio-activity failures. These are concrete, reproducible validation methods. However, the game status table is more cautious. Super Mario World is believed playable end to end. A Link to the Past is playable through the early dungeon. Mega Man X is fully playable, with experimental true-widescreen mods. The difference between a 36,000-frame attract test and a human playing through the entire game is significant. Attract loops exercise the CPU and hardware deterministically, but they do not cover every player input path. The status table reflects that gap.

Game-Specific Integration vs. Framework Improvements

A key architectural decision is that the framework is game-agnostic, but each game supplies its own analysis configuration and integration code. The README states that improvements to the CPU and hardware model benefit every project. That is the upside: fix a bug in the SA-1 core, and Super Mario RPG benefits, but also any future SA-1 game you port. The downside is that the heavy lifting for a new game is not just running the analyzer. You must configure the analysis for that game's specific code layout, handle any game-specific quirks in the integration layer, and validate the result. The companion repositories pin a known framework revision, which means you cannot just pull the latest framework and expect your game to build. You must track which revision your game was built against. This is a maintenance cost that the README acknowledges by calling the projects alpha.

The Alternative: Full-System Emulation and Dynamic Recompilation

The obvious alternative is a full-system emulator like Snes9x, which uses dynamic recompilation or interpretation. The difference in approach is fundamental. An emulator models the entire console in software, so it can run almost any SNES game without per-title work. It does not need to statically resolve code paths, and it handles unsupported chips by either implementing them or refusing to run. But an emulator runs the game as a guest, which makes deep modifications like true widescreen rendering much harder. SNESRecomp's static approach gives you native code and the ability to change the game's logic, but it requires per-game analysis and integration. Another alternative is manual decompilation or reverse engineering, where you rewrite the game's logic in C from scratch, which gives total control but is far more labor-intensive. SNESRecomp sits between those: it automates the translation but still requires human configuration and validation.

Licensing and Legal Caveats

The repository license is listed as NOASSERTION, which is not a standard open-source license identifier. That means you cannot assume any particular usage rights. The README says the projects are ROM-free, meaning the releases do not include the original game ROM, but the recompiled source is derived from the game's machine code. That derivation raises copyright questions that the project does not address in the provided material. If you plan to distribute a port, you need to understand the legal status of the original game and the generated code. The license situation is a genuine obstacle for commercial use. The project is part of the R.A.I.D. community, which may have its own norms, but the NOASSERTION license gives you no formal permission. Treat this as a research and hobby tool unless you get legal advice for your specific case.

Editorial conclusion

Adopt SNESRecomp if you want to build a native, moddable port of a SNES game that uses one of the supported cartridge mappings (LoROM, HiROM, SA-1, Cx4, Super FX, DSP-1) and you are comfortable with alpha-quality tooling. Do not adopt it if you need a drop-in emulator for arbitrary SNES titles, or if your target uses S-DD1, SPC7110, DSP-2/3/4, or any of the listed unsupported chips. Before starting, verify that your specific ROM revision is covered by the companion game repository's validation status, because the framework's mapper support does not guarantee a playable port. Check the game repositories for current build instructions and known limitations, and review the runner notes for your chip (for example, runner/src/snes/CX4_NOTES.md or SA1_NOTES.md) to see what is qualified.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes