Retro Porting Toolkit · Bring classic console games to modern hardware

Lineage and credit

How the projects in this fleet descend from each other: the framework the others were modelled on, the CPU cores several toolchains share, and the commit each game port pins.

The toolchains here are not independent projects. One of them is the model the others were built from. Two CPU frontends were pulled out of one framework and are now shared repositories. Every game port records the exact framework commit it was built against. Those are the lines of descent inside the fleet, and each one can be checked in the repositories themselves.

psxrecomp is the model the others name

psxrecomp is the PlayStation toolchain. The others name it as their model, by name, in their own documents.

- snesrecomp calls its accuracy scorecard "modeled on the psxrecomp ACCURACY_BURNDOWN.md 7-axis methodology", ports its timing plan from psxrecomp's, and cites psxrecomp's co-simulation document as the "proven PSX reference impl". - nesrecomp models the same scorecard "1:1". It also refused part of the design and wrote down why. psxrecomp has several execution tiers for code that only arrives while the game is running. A NES cartridge is complete before the build starts, so those tiers would have nothing to do. - segagenesisrecomp mirrors psxrecomp's co-simulation harness, counts guest cycles the psxrecomp way, and injects widescreen the PSX way. - gbarecomp takes the same scorecard, the same co-simulation design, and the idea of treating the console BIOS as an ordinary program. - ndsrecomp models its dispatch tiers on psxrecomp and lists itself in the same family. The copying is not only design. Every PlayStation game port builds its releases from a workflow copied out of psxrecomp, and the copy says so in its first line.

Two CPU cores are shared repositories now

m68k-recomp-core is the Motorola 68000 frontend. It did not start as a shared repository. The Genesis toolchain wrote it, the CD-i toolchain copied it, and the copy then went its own way.

From PROVENANCE.md:

PROVENANCE.md
The author-owned frontend originated in `segagenesisrecomp`. CD-i copied the
frontend from `segagenesisrecomp` commit `5aa0c4f` on 2026-05-28 and developed
SCC68070/OS-9 behavior independently afterward.

Both now consume the extracted repository, at external/m68k-recomp-core. The shared decoder and validator are byte-identical between the two pins. All the difference sits in the Genesis profile, which is the split the README asks for.

z80-recomp-core does the same for the Zilog Z80, a chip that turns up in two different roles. On the Master System and Game Gear it is the console's main CPU. On the Genesis it drives the cartridge sound. Both toolchains pin the identical commit, which is also that repository's only commit.

recomp-ui, the launcher and settings screen, began the same way, inside one console's project.

From README.md:

README.md
It is the reusable extraction of the SNES-recomp "launcher_ng" launcher,
generalized behind a small C ABI.

Today many game ports pin it across several consoles.

Small parts that travelled

Two components moved between projects and are credited at every stop.

The screen colour table in snesrecomp is adapted from psxrecomp, and snesrecomp's attribution file records the exact revision it was taken from. DKC2Recomp then vendors that psxrecomp-derived component under third_party/psxrecomp_color_lut/, carrying all three of its license texts.

The ShadowVerifier and the colour science core came from outside the fleet, from JRickey/gba-recomp, with the author's permission. gbarecomp and snesrecomp implemented it first. segagenesisrecomp credits it as ported "through the gbarecomp/snesrecomp implementations with permission". psxrecomp and vbrecomp carry their own versions in C.

Every game port pins a commit

A game port is a thin repository over one framework, joined by a git submodule pinned to a single commit. That pin records which version of the framework the port was built against.

The pins are not uniform. The recomp-ui gitlinks point at many different commits. Two ports point the submodule URL at a fork instead of the original, and three pin a named feature branch. Two other repositories have left the submodule mechanism and carry a snapshot of a framework as an ordinary directory, so a fact about a framework should be read in the framework repository, never in one of those copies.

Source