Sega Saturn decomp guide

What this system is like

The Saturn has two main chips and two video chips. That made it hard to program in 1994. It also makes it hard to rebuild today. Still, Saturn work moved fast in late 2026.

Path A, a game running on PC, is real now. Three shared toolkits turn the game's SH-2 code into C++. They each add a stand-in for the console, called a runtime. Seven games reach menus and early play this way. None claims a full playthrough yet. All of these toolkits are only weeks old.

Path B, a full decomp, is not done for any Saturn game yet. The furthest one reviewed here is the Saturn build of Symphony of the Night, at about 36% on decomp.dev. Daytona USA CCE rebuilds one race module from split assembly, byte for byte. Turning that into C that the old compiler rebuilds exactly is slow. The exact compiler is often lost.

Plan on WSL for Path B and for some Path A tools. Plan on Windows for playing, emulators and most Path A builds.

Two paths

Path A: Get it running on PC

You turn each SH-2 program on the disc into C++ with a shared toolkit. The toolkit's runtime stands in for the two SH-2s, both VDPs, the CD drive and sound. An SH-2 interpreter checks the C++ function by function. An emulator such as Beetle Saturn is the reference for pictures and sound. You then fix one runtime gap at a time.

1. Scope the game and pick a toolkit

   Pin your exact disc by its product code and hash. Check if the game or its engine already has a port. Then pick one of the three toolkits. Write SCOPE.md so every session works toward the same goal.

   • Dump your own disc to .cue and .bin. Keep it outside the repo, for example D:/saturn-discs/.
   • Run certutil -hashfile "<DATA_TRACK>.bin" SHA256 in PowerShell and write the hash in SCOPE.md. Hash each data track: the ones marked MODE1 or MODE2 in the .cue.
   • Read the product code with python -m saturnkit.disc <DISC>.cue --info after step 2, or from the disc case.
   • Search GitHub for the game name plus recomp and decomp. Fighters Megamix reused engine routines from Fighting Vipers.
   • Pick saturnkit for a Windows-first flow, saturn-recomp for its game.toml and learn loop, or satrecomp for record-then-translate with a fallback.
   • If you pick satrecomp, read its docs/NEXT_GAME.md first. It lists what is still shaped by the one game it was built for.
   • Write SCOPE.md: the goal, the disc hash, the toolkit and its pinned commit, the first milestone and its check.
   Prompt for ClaudeCopy

   GOAL: Draft SCOPE.md for a PC port of <GAME> (Saturn, product code <PRODUCT_CODE>) by static recompilation.
   READ FIRST: https://github.com/vs-sr-dev/saturnkit , https://github.com/callumjenkins/saturn-recomp , https://github.com/tmcleroy/satrecomp (READMEs only).
   FENCE: Edit only `SCOPE.md` and `notes/prior-work.md`. Do not install tools. Do not touch any disc file.
   CHECK: Done means SCOPE.md names the disc hash <DISC_SHA256>, one toolkit with a pinned commit, the first milestone (title screen in a headless run) and its check command, and a list of what is out of scope. notes/prior-work.md lists every repo you found for this game or engine with its URL.
   BUDGET: Stop after 45 minutes of searching.
   IF BLOCKED: Stop. Do not work around it. Tell me what blocked you, what you tried, and what you need from me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the SCOPE.md text. 3) Files changed. 4) Open questions for me. 5) New parking-lot items.

   Done whengrep -c <DISC_SHA256> SCOPE.md prints 1 or more, SCOPE.md names one toolkit commit and the first milestone, and you approved it.

   Proof this works: Shining Force III Recomp (exact data-track SHA-256 profiles), Baroque (SaturnRecomp) (setup rejects any disc that is not T-33901G), Fighters Megamix Recomp (shared engine with Fighting Vipers)

2. Set up the repo and the one check

   Make a game repo with the toolkit as a pinned submodule. Install the compiler kit. Write one check script that builds and runs a short headless test. Write CLAUDE.md and PROGRESS.md now, not later.

   • Install MSYS2. In the MINGW64 shell run pacman -S make mingw-w64-x86_64-clang mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja mingw-w64-x86_64-sdl3 mingw-w64-x86_64-python. For satrecomp, add mingw-w64-x86_64-gcc and mingw-w64-x86_64-zlib.
   • For saturnkit: git submodule add https://github.com/vs-sr-dev/saturnkit.git saturnkit. It needs no Python packages.
   • For saturn-recomp, in WSL: git submodule add https://github.com/callumjenkins/saturn-recomp.git saturn-recomp, then pip install -e saturn-recomp inside a Python venv. The install must be editable.
   • For satrecomp: clone it, run make check with no game, then copy its example/ folder as your game repo.
   • Add iso/, build/ and work/ to .gitignore. No game bytes ever go in git.
   • Write tools/check.sh. It builds, runs build/recomp-build/saturn --cue <DISC>.cue --headless --vblanks 600 --shot 600, and copies the picture to build/shots/600.png.
   Prompt for ClaudeCopy

   GOAL: Set up the <GAME> port repo on <TOOLKIT> with one check command.
   READ FIRST: SCOPE.md, the <TOOLKIT> README, `<TOOLKIT>/docs` if it exists.
   FENCE: Edit only `.gitignore`, `.gitmodules`, `tools/`, `CLAUDE.md`, `PROGRESS.md`, `notes/`. Never edit files inside the toolkit submodule. Do not add features.
   CHECK: Run `bash tools/check.sh <ABSOLUTE_PATH_TO_CUE>`. Done means it builds with no errors, writes one PNG to `build/shots/`, and `git status` shows no disc-derived file.
   BUDGET: Stop after 3 failed builds on the same error, or 90 minutes.
   IF BLOCKED: Stop. Do not work around it. Tell me what blocked you, what you tried, and what you need from me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the last 20 lines of the check output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenbash tools/check.sh <ABSOLUTE_PATH_TO_CUE> exits 0 and writes build/shots/600.png, and git status --porcelain lists nothing under iso/, build/ or work/.

   Proof this works: pc-virtualhydlide (saturnkit submodule, clang 22 in MSYS2 mingw64), PAL-Saturn-Recomp (pinned upstream commit 086c372), satrecomp README (make check needs no game, read 2026-11-13)

3. Survey the disc

   Learn what is on the disc before you translate anything. Find each program, where it loads, and which ones swap at the same address. Write it down. Wrong load addresses break every later step.

   • Run python -m saturnkit.disc <DISC>.cue --info to read IP.BIN and the first file to load.
   • Run python -m saturnkit.disc <DISC>.cue --extract build/extract and --audio build/audio for CD music.
   • For each program run python -m saturnkit.sh2 <FILE>.BIN --find-base to guess its load address.
   • Check each guess against the program's start code. --find-base can pick a wrong base for a small program that calls into a big one.
   • Write notes/disc.md: every program file, its load address, its size, and its proof.
   • Mark overlay programs that load at one shared address. saturnkit tells them apart in memory by crc32.
   Prompt for ClaudeCopy

   GOAL: Write notes/disc.md: every SH-2 program on the <GAME> disc with its load address and proof.
   READ FIRST: SCOPE.md, the toolkit README section on `disc` and `sh2`.
   FENCE: Edit only `notes/disc.md` and `game.toml` (program list only). Read the disc only through the toolkit. Do not copy disc bytes into the repo.
   CHECK: Run `python -m saturnkit.sh2 <FILE> --base <ADDR> --at <ADDR> --count 32` for each program. Done means each listing starts with a sane function prologue, and each address in notes/disc.md names its proof (crt0, IP.BIN, --find-base or a loader call).
   BUDGET: Stop after 2 hours, or after 3 programs whose base you cannot prove.
   IF BLOCKED: Stop. Do not guess load addresses. List the programs you could not place.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the table of programs and bases. 3) Files changed. 4) Unproven programs. 5) New parking-lot items.

   Done whennotes/disc.md lists every program with a load address and a named proof.

   Proof this works: pc-dragonballlegend (IP.BIN, loader and seven programs surveyed first), pc-deepfear (--find-base 06004000 then discovery), pc-virtualhydlide (15 programs told apart by crc32)

4. Map functions and library code

   Run the toolkit's function finder on every program. Check its list against Ghidra. Mark SGL and SBL library code so nobody studies it by hand. Save the map as a ledger with a status column.

   • Run python -m saturnkit.recomp.discover <FILE>.BIN --base <ADDR> --report for each program.
   • Install Ghidra 12.0 with JDK 21. Add the Ghidra-SegaSaturn-Loader 12.0.0 release zip through File, Install Extensions.
   • Unzip a Mednafen save state with gunzip, then load it in Ghidra with the loader. You see code as it sits in memory.
   • Copy ApplySig.py into a ghidra_scripts folder. Run it from the Script Manager with CyberWarriorX's Saturn library signatures to name SGL and SBL functions.
   • Export Ghidra's function list with a small script, as pc-deepfear does with its ExportFuncs.java. Compare counts. Deep Fear matched 1,250 of 1,252.
   • Write notes/functions.csv with address, size, program, name, proof and status.
   Prompt for ClaudeCopy

   GOAL: Build notes/functions.csv for <PROGRAM> and explain every gap between the toolkit's discovery and Ghidra.
   READ FIRST: notes/disc.md, the discovery report at `build/<PROGRAM>.report.txt`, the Ghidra export at `build/ghidra/<PROGRAM>.funcs.txt`.
   FENCE: Edit only `notes/functions.csv`, `notes/discovery-gaps.md` and the seeds list in `game.toml`. Do not edit the toolkit. Do not edit generated C++.
   CHECK: Run `python -m saturnkit.recomp.discover <ABSOLUTE_PATH_TO_FILE> --base <ADDR> --report`. Done means every function Ghidra finds is either in the report or listed in notes/discovery-gaps.md with a reason (shared tail, data, library).
   BUDGET: Stop after 2 hours or 20 unexplained gaps.
   IF BLOCKED: Stop. Do not add seeds you cannot prove. List them.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both function counts and the gap count. 3) Files changed. 4) Open gaps. 5) New parking-lot items.

   Done whennotes/functions.csv exists, and every Ghidra function is either found or explained.

   Proof this works: pc-deepfear (1,250 of 1,252 Ghidra functions matched), pc-virtualhydlide (571 of 576; the other 5 are shared tails), Daytona USA CCE (Ghidra with Saturn loader and SBL/SGL signatures)

5. First light: translate, self-test, boot

   Turn every program into C++ and build it. Run the self-test against the SH-2 interpreter. Then boot the game with no window and take a picture. This is your first proof the chain works end to end.

   • saturnkit: python -m saturnkit.recomp --out build/recomp A=<FILE>.BIN@<ADDR>, then the cmake and ninja lines from its README.
   • saturn-recomp: python -m saturnrecomp.build game.toml --recompile.
   • satrecomp: make, then make record ARGS="--headless --frames 3000", then make again.
   • Self-test vectors: python -m saturnkit.recomp.selftest --out build/vectors.txt --image A=<FILE>.BIN@<ADDR> --test A --auto. Add --optest to the recomp line for the instruction test.
   • Run them: build/recomp-build/selftest build/recomp/selftest/optest.txt build/vectors.txt. Expect zero differences.
   • Boot headless: build/recomp-build/saturn --cue <DISC>.cue --headless --vblanks 600 --shot 300,600.
   Prompt for ClaudeCopy

   GOAL: Recompile all programs of <GAME>, pass the self-test, and boot to the first screen headless.
   READ FIRST: SCOPE.md, notes/disc.md, notes/functions.csv, the toolkit README sections on recomp and selftest.
   FENCE: Edit only `game.toml`, `tools/` and `notes/`. Never edit generated C++ under `build/`. Never edit the toolkit.
   CHECK: Run `bash tools/check.sh <ABSOLUTE_PATH_TO_CUE>`. Done means the self-test prints 0 differences and `build/shots/600.png` shows a logo or title, not a black frame.
   BUDGET: Stop after 3 failed tries on one error, or 2 hours.
   IF BLOCKED: Stop. If the run stops on a call to a non-entry, report the address. Do not stub it.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: self-test summary line and the PNG path. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe self-test shows 0 differences and a headless run saves a picture of the first logo or title.

   Proof this works: pc-virtualhydlide (51,532 vectors, 0 differences), pc-dragonballlegend (30,261 of 30,261 vectors; boot to first battle), Fighters Megamix Recomp (record, translate, make check)

6. Build the reference runs

   A reference run is the same input played in an emulator. You need it to say what right looks like. Record pad input as a text file. Replay it in your build and in Beetle Saturn. The emulator's frames drift from your VBlanks, so line pictures up by the game's own frame counter.

   • Play in your build with build/recomp-build/saturn --cue <DISC>.cue --record-input movies/intro.txt.
   • Replay headless: build/recomp-build/saturn --cue <DISC>.cue --headless --input @movies/intro.txt --vblanks 9000 --shot 7760.
   • Make reference pictures: python -m saturnrecomp.reference <CORE> --bios <BIOS_DIR> --cue <DISC>.cue --frames 3600 --input <PRESSES> --shot <FRAMES> --out refs/.
   • Build the Beetle Saturn core with -D_LOW_ACCURACY_ taken out of its Makefile. US and European discs need your own mpr-17933.bin. Japanese discs need sega_101.bin.
   • Line up shots with saturnrecomp.reference.play_synced. The real BIOS boots first and CD reads take time, so frame numbers alone do not match.
   • pc-deepfear does the same with its own tools/oracle.py, which drives RetroArch with timed presses like --at 36:START,39:START,60:START,66:shot.
   • Store pictures in refs/ outside git, and their hashes in refs/hashes.txt inside git. Movies may replay only on the machine that recorded them, so test each one twice there.
   Prompt for ClaudeCopy

   GOAL: Make three golden runs for <GAME>: boot to title, title to first control, first <N> minutes of play.
   READ FIRST: SCOPE.md, the toolkit README sections on --input, --record-input and the reference emulator.
   FENCE: Edit only `movies/`, `refs/hashes.txt`, `tools/golden.sh` and `notes/`. Do not change the runtime. Do not change game code.
   CHECK: Run `bash tools/golden.sh <ABSOLUTE_PATH_TO_CUE>`. Done means each run replays twice with the same picture hashes, and each run has emulator reference pictures taken at the same value of the game's own frame counter.
   BUDGET: Stop after 90 minutes or 3 runs that will not repeat.
   IF BLOCKED: Stop. Do not loosen the compare. Tell me which VBlank first differs.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the hash lines from both replays. 3) Files changed. 4) Runs still missing. 5) New parking-lot items.

   Done whenThree recorded runs replay with the same hashes twice, and each has reference pictures.

   Proof this works: pc-dragonballlegend (scripted presses, CD-DA correlation 1.00 against Beetle Saturn), Fighting Vipers Recomp (input movies replay with the same per-frame hashes), saturn-recomp README (saturnrecomp.reference and play_synced, read 2026-11-13)

7. Grind: one runtime gap at a time

   Now play forward until something breaks. Each break is one unit of work. Find the first wrong frame, then the first wrong memory write. Most Saturn breaks were runtime gaps, not game bugs.

   • Find the first VBlank where your picture differs from the reference.
   • Watch writes: build/recomp-build/saturn --cue <DISC>.cue --headless --watch <START>:<END> --watch-vblanks <A>:<B>.
   • Check the known gaps first: DMA burst size, CD read speed and seeks, the division unit, VDP1 frame change timing. On saturn-recomp, try --accurate-drive for real drive timing.
   • Fix it in the runtime or as a numbered patch on the pinned toolkit, never in generated code.
   • Add the run that showed the bug to movies/. Write the cause in notes/findings.md.
   Prompt for ClaudeCopy

   GOAL: Find and fix the cause of <SYMPTOM> at VBlank <N> in movie <MOVIE>.
   READ FIRST: notes/findings.md (dead ends), PROGRESS.md, the two pictures `build/shots/<N>.png` and `refs/<N>.png`.
   FENCE: Edit only `<RUNTIME_PATH>`, `patches/` and `notes/`. Never edit generated C++. Never add per-game hacks to the runtime. No stubs and no faked events.
   CHECK: Run `bash tools/golden.sh <ABSOLUTE_PATH_TO_CUE>`. Done means the movie passes the frame where it failed, every other golden run still passes, and notes/findings.md names the proven cause.
   BUDGET: Stop after 3 failed fix ideas, or 2 hours with no new evidence.
   IF BLOCKED: Stop. Do not work around it. Report the first wrong write you found and what you need.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: golden.sh output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe failing movie passes the old failure point, and every older golden run still passes.

   Proof this works: pc-deepfear (DMAC 16-byte transfers, division unit shadow register, drive speed), PAL-Saturn-Recomp (black screen was a DMA burst bug, not VDP2), Baroque (SaturnRecomp) (CD block GetSectorInfo and DMA interrupt blockers)

8. Harden and package

   Make sure old fixes stay fixed. Drive the interpreter fallback count down. Add saves, settings and a launcher. Check that no game data can leak into git or a release.

   • Run all golden runs on a clean checkout: git clone, then bash tools/golden.sh <DISC>.cue.
   • Report coverage. satrecomp counts every fallback. saturn-recomp has --coverage cov.txt.
   • Add an audit step like Fighters Megamix's make audit that fails on game data or personal paths.
   • Write saves outside the app folder, as Baroque does with game/backup.bin.
   • On Windows, link statically, or a stray libstdc++-6.dll can stop the exe.
   Prompt for ClaudeCopy

   GOAL: Make the <GAME> port pass every golden run from a clean checkout and add an audit that blocks game data.
   READ FIRST: PROGRESS.md, `movies/`, `refs/hashes.txt`, notes/findings.md.
   FENCE: Edit only `tools/`, `.github/`, `docs/` and `PROGRESS.md`. Do not change the runtime or game.toml. Do not change any reference hash.
   CHECK: In a fresh clone at `<ABSOLUTE_TEMP_DIR>`, run `bash tools/golden.sh <ABSOLUTE_PATH_TO_CUE>` and `bash tools/audit.sh`. Done means both pass and the coverage report shows the fallback count.
   BUDGET: Stop after 2 hours.
   IF BLOCKED: Stop. Do not work around it. Tell me what blocked you, what you tried, and what you need from me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both outputs and the fallback count. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenA clean clone passes every golden run and the audit, and the fallback count is written in PROGRESS.md.

   Proof this works: Fighters Megamix Recomp (make audit, CI smoke start), Shining Force III Recomp (62 synthetic test files, check-source-package.py), PAL-Saturn-Recomp (static link fixes 0xC0000139)

Path B: Full decomp for porting

No Saturn game has a full decomp yet. The route that works so far has three tiers. First rebuild every program as assembly that matches byte for byte. Then turn code into C that the period compiler rebuilds exactly, one translation unit at a time. Code that will not match can be checked against an SH-2 oracle instead. Last, you swap the console parts for PC parts.

1. Scope: find the compiler family

   You must know which compiler built the game. SHC and GCC leave different marks. Check what others found for the same engine. Write down how sure you are in SCOPE.md.

   • Look for marks in the code. SHC games built with its -pic option use bsrf and braf calls. GCC games show GCC switch tables.
   • Name library code first with ApplySig.py and CyberWarriorX's SGL and SBL signatures.
   • Read atolm's docs/FINDING_THE_COMPILER.md to see how one team fingerprinted SHC.
   • Check sotn-decomp and saturn-splitter for a GCC game built with the Cygnus DOS compiler.
   • Write SCOPE.md: game hash, compiler family, the candidate compiler and flags, and the first target program.
   Prompt for ClaudeCopy

   GOAL: Decide which compiler family built <PROGRAM> of <GAME> and write it into SCOPE.md with evidence.
   READ FIRST: https://github.com/blythos/atolm (README and docs/FINDING_THE_COMPILER.md), https://github.com/sozud/saturn-splitter , notes/functions.csv.
   FENCE: Edit only `SCOPE.md` and `notes/compiler.md`. Do not install compilers. Do not touch disc files.
   CHECK: Done means notes/compiler.md lists at least five code addresses with the idiom each shows (SHC or GCC), and SCOPE.md names one family, one candidate compiler and its flags, and how sure you are.
   BUDGET: Stop after 2 hours.
   IF BLOCKED: Stop. If the signs disagree, say so. Do not pick one to look tidy.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the address table. 3) Files changed. 4) Open questions. 5) New parking-lot items.

   Done whennotes/compiler.md has a table of five or more code addresses, each with its idiom, and grep -E 'SHC|GCC' SCOPE.md finds the chosen family.

   Proof this works: atolm (Hitachi SHC 5.0 Release31 chosen by fingerprinting), pc-dragonballlegend (SHC -pic code: bsrf, braf, mova), pc-deepfear (GCC switch tables and SGL handlers)

2. Set up WSL, Docker and the byte check

   Build a repo where one command rebuilds a program and compares its hash. The old compilers run in Docker inside WSL. Keep disc files and extracted programs in ignored folders. The byte check is your judge from now on.

   • In WSL run sudo apt install binutils-sh-elf make python3-yaml and install Docker.
   • Fetch the period compiler only through a project script, such as atolm's make setup or saturn-splitter's scripts/get_gccsh.sh.
   • Write make extract to pull programs from your disc into extracted/. It must refuse a wrong dump.
   • Write make check to compare each rebuilt program with sha256sum against the extracted one.
   • Put expected hashes in config/ and block edits to them with a Claude Code hook.
   Prompt for ClaudeCopy

   GOAL: Set up the <GAME> decomp repo so `make check` rebuilds <PROGRAM> and compares its sha256.
   READ FIRST: SCOPE.md, notes/compiler.md, https://github.com/blythos/atolm (Makefile targets in the README).
   FENCE: Edit only `Makefile`, `toolchain/`, `tools/`, `config/`, `.gitignore`, `CLAUDE.md`, `.claude/settings.json`. Disc files stay in `ISOs/` and `extracted/`, both ignored.
   CHECK: In WSL run `make extract && make check`. Done means make check prints the hash of the extracted <PROGRAM>, and a deliberately broken rebuild makes it fail.
   BUDGET: Stop after 3 failed toolchain builds, or 3 hours.
   IF BLOCKED: Stop. Do not swap in a different compiler to get a green check.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the passing and the deliberately failing output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenmake check passes on the original and fails on a deliberately broken build.

   Proof this works: atolm (make setup, make extract, make, make check), Daytona USA CCE (./setup.sh, make validate 8 of 8 identical), Castlevania: Symphony of the Night Decompilation (make VERSION=saturn)

3. Split and rebuild as assembly

   Cut each program into one file per function with a boundary list. Rebuild it from that assembly. It must match byte for byte. This gives you a full map and a safe base for C work.

   • Keep a boundary database like Daytona's config/race.bin.yaml with 757 pieces and 100% coverage.
   • Write a splitter like Daytona's tools/splitter.py. saturn-splitter is an example in Rust.
   • Turn raw .byte lines into real SH-2 instructions so branches can move later.
   • Run make then make check after each batch of boundaries.
   • Classify doubtful function starts five at a time in an append-only CSV.
   Prompt for ClaudeCopy

   GOAL: Rebuild <PROGRAM> from per-function assembly so it matches byte for byte.
   READ FIRST: SCOPE.md, notes/functions.csv, `config/<PROGRAM>.yaml`.
   FENCE: Edit only `config/<PROGRAM>.yaml`, `tools/splitter.py` and `notes/`. Never hand-edit the split output in `asm/`. Regenerate it.
   CHECK: In WSL run `make && make check`. Done means <PROGRAM> is byte-identical and the yaml covers 100% of its bytes.
   BUDGET: Stop after 3 hours or 5 failed rebuilds on one boundary.
   IF BLOCKED: Stop. List the addresses where the boundary is unclear. Do not guess.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: make check output and the coverage number. 3) Files changed. 4) Unclear boundaries. 5) New parking-lot items.

   Done whenmake check shows the program byte-identical, and the boundary file covers 100% of its bytes.

   Proof this works: Daytona USA CCE (757 subsegments at 100% coverage), Daytona USA CCE (eval-midentry skill, 5 addresses per run), saturn-splitter README (read 2026-11-13)

4. Prove the code can move

   A byte match can hide hard-coded addresses. Build a copy with all code moved a few bytes. If it still boots, every pointer is real. Only then can you change code size safely.

   • Add a build target that inserts 4 bytes at the start, like Daytona's make 4shift.
   • Write the shifted program into a bootable disc image, as Daytona's make disc and tools/inject_disc.py do.
   • Boot it headless in mednafen-saturn-debug with ./mednafen --sound 0 --automation <IPC_DIR> <CUE>, and screenshot attract mode at 40 seconds.
   • Compare the shot with a golden picture, as Daytona's tools/screenshot_test.py does.
   • Each failure is a missed pointer. Turn it into a label and rebuild.
   Prompt for ClaudeCopy

   GOAL: Make the +4 byte shifted build of <PROGRAM> boot to the same attract-mode picture as the original.
   READ FIRST: CLAUDE.md, `config/<PROGRAM>.yaml`, notes/shift-misses.md.
   FENCE: Edit only `asm/` label lines through the generator, `config/`, `tools/` and `notes/shift-misses.md`. Do not change the golden picture.
   CHECK: Run `make check && make 4shift && python3 tools/screenshot_test.py build/4shift.cue`. Done means make check passes and the screenshot matches the golden one.
   BUDGET: Stop after 10 missed pointers fixed, then report.
   IF BLOCKED: Stop. Report the address where the shifted build first goes wrong.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both outputs. 3) Files changed. 4) Pointers still missing. 5) New parking-lot items.

   Done whenThe shifted build boots and its screenshot matches the golden picture, while make check still passes.

   Proof this works: Daytona USA CCE (make 4shift, screenshot test, 26 missed refs fixed in result2p), mednafen-saturn-debug README (--automation file interface and screenshots, read 2026-11-13)

5. Mark libraries and group functions

   Library code from SGL and SBL needs no new C. Name it and set it aside. Then group the rest into translation units. A translation unit is one original source file. On Saturn you usually match a whole unit, not one function.

   • Apply SGL and SBL signatures in Ghidra and set those rows to library in notes/functions.csv.
   • Group functions that sit next to each other and either call each other with bsr or share a literal pool. Those must sit in one unit.
   • Write each group to config/units.csv with the signal that joined them.
   • Do not join two functions just because one calls the other through jsr.
   Prompt for ClaudeCopy

   GOAL: Mark library code and group the rest of <PROGRAM> into translation units.
   READ FIRST: notes/functions.csv, `config/<PROGRAM>.yaml`, the Ghidra export `build/ghidra/<PROGRAM>.sigs.txt`.
   FENCE: Edit only `notes/functions.csv` and `config/units.csv`. Do not write C. Do not edit assembly.
   CHECK: Done means every function has a status, every unit names its joining signal (bsr link or shared pool), and `make check` still passes.
   BUDGET: Stop after 2 hours.
   IF BLOCKED: Stop. List the groups you are not sure of. Do not merge on a guess.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: counts per status and per unit. 3) Files changed. 4) Unsure groups. 5) New parking-lot items.

   Done whenEvery function has a status and every unit names the signal that joined it.

   Proof this works: atolm (about 77.5% of sampled functions need their whole unit), Daytona USA CCE (tu-detection skill rules), atolm (15 exact SBL and CPK library placements)

6. First match: one small unit

   Match one small unit end to end with the period compiler. This proves the compiler, the flags and the build. Start with a leaf function that calls nothing. Write down every flag you used.

   • Get a draft with m2c --target sh2-gcc-c <FILE>.s for GCC games. For SHC games, use it only as a hint.
   • Compile in the toolchain container with the flags in SCOPE.md, for example atolm's -optimize=1 -speed.
   • Compare with asm-differ set up for SH2, or sh-elf-objdump -d on both files.
   • Record the address, size, exact compile line and hash in notes/matches.md.
   Prompt for ClaudeCopy

   GOAL: Match unit <UNIT> (functions <ADDRS>) of <PROGRAM> byte for byte with the period compiler.
   READ FIRST: SCOPE.md (compiler and flags), `asm/<UNIT>/`, notes/matches.md (one finished example), notes/findings.md (dead ends).
   FENCE: Edit only `src/<UNIT>.c` and `notes/`. No inline assembly, no embedded bytes, no new compiler flags without my approval.
   CHECK: In WSL run `make check`. Done means the unit is built from C and <PROGRAM> stays byte-identical.
   BUDGET: Stop after 8 attempts or 90 minutes.
   IF BLOCKED: Stop. Paste the smallest remaining diff and name its likely cause (register choice, scheduling, constant).
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: make check output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenmake check passes with that unit built from C.

   Proof this works: atolm (three leaf functions matched with SHC 5.0), m2c README (sh2 target, read 2026-11-13), asm-differ README (SH2 support, read 2026-11-13)

7. Grind: unit loop with many workers

   Now repeat the unit loop. A lead session hands out units, easy and small first. Each worker has its own worktree. Every merge must pass the full byte check.

   • Sort config/units.csv by size. Leaf units go first.
   • Give each worker one unit card, one finished example and the dead-end list.
   • Run make check in the worker's worktree, and again on the main branch after merge.
   • Log near misses as attempted with the remaining diff. Never count them as matched.
   Prompt for ClaudeCopy

   GOAL: Hand out the next <N> unattempted units of <PROGRAM> to workers and merge only proven matches.
   READ FIRST: config/units.csv, notes/matches.md, notes/findings.md, PROGRESS.md.
   FENCE: Edit only `PROGRESS.md` and merge commits. Workers edit only their own `src/<UNIT>.c`. Nobody edits hashes, asm or the Makefile.
   CHECK: After each merge run `make check` on the main branch. Done means every merged unit passes there, and PROGRESS.md shows matched, attempted and unattempted counts.
   BUDGET: Stop after <N> units or 4 hours.
   IF BLOCKED: Stop. Report which merge broke the check and revert it.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: make check output on main. 3) Files changed. 4) Units left. 5) New parking-lot items.

   Done whenEvery merged unit passes make check on the main branch, and PROGRESS.md shows the full status split.

   Proof this works: atolm (status table with eight states, CI-checked), Castlevania: Symphony of the Night Decompilation (asm-differ per version, make diff_saturn)

8. Check code that will not match

   Some units may never match, because the exact compiler is lost. For those, prove the C does the same thing. Run the original code in an SH-2 interpreter and diff it against your C. Keep these in a separate column.

   • Build an oracle: run the original SH-2 code in an interpreter such as python -m saturnkit.sh2emu or Sega Rally's tools/sh2.py. saturnkit's runs one function: --call <ADDR> --regs r4=<VALUE>.
   • Record inputs and outputs for each unit from real play.
   • Run the C on the same inputs and compare memory after each call or each frame.
   • Mark the unit equivalence-verified. Never add it to the matched count.
   Prompt for ClaudeCopy

   GOAL: Prove unit <UNIT> behaves the same as the original, with an oracle diff.
   READ FIRST: notes/findings.md entry for <UNIT>, `src/<UNIT>.c`, the oracle docs in `docs/oracle.md`.
   FENCE: Edit only `tests/oracle/<UNIT>/`, `src/<UNIT>.c` and `notes/`. Do not change the oracle or the recorded traces.
   CHECK: Run `python3 tools/oracle_diff.py <UNIT> --traces <ABSOLUTE_TRACE_DIR>`. Done means 0 differing calls across all recorded traces.
   BUDGET: Stop after 3 fix ideas or 2 hours.
   IF BLOCKED: Stop. Paste the first differing call with both memory dumps.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: oracle_diff summary. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe oracle diff shows 0 differing calls on every recorded trace, and the unit sits in its own column.

   Proof this works: Sega Rally PSP (141 drive traces with 0 differing passes), atolm (equivalence-verified state, never summed into matched)

9. Port: swap the console parts

   Put SH-2 hardware access behind small functions. Replace VDP1, VDP2, sound and CD with PC code. Fix big-endian data reads. Then run the same golden runs on the new system.

   • Read game tables through helpers like Sega Rally's g16 and g32, since data is big-endian.
   • Replace drawing with a modern library, as Azel does with bgfx and SDL.
   • Play Saturn sound data with a library like aosdk, or keep a 68000 and SCSP model.
   • Run your golden runs on the port and compare against the emulator pictures.
   Prompt for ClaudeCopy

   GOAL: Move <SUBSYSTEM> of <GAME> from Saturn hardware calls to the port layer in `port/`.
   READ FIRST: PROGRESS.md, `src/<SUBSYSTEM>/`, notes/hardware-calls.md.
   FENCE: Edit only `port/` and the call sites listed in notes/hardware-calls.md. Do not change matched units except their hardware calls behind a define.
   CHECK: Run `make check` (Saturn build still byte-identical) and `bash tools/golden.sh --port <ABSOLUTE_PATH_TO_DATA>`. Done means both pass.
   BUDGET: Stop after 3 hours or 3 failed golden runs.
   IF BLOCKED: Stop. Report the first frame that differs and the call behind it.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both outputs. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe Saturn build still matches, and the port passes the same golden runs.

   Proof this works: Sega Rally PSP (g16 and g32 helpers, real PSP tests), Azel (bgfx, SDL, SoLoud and aosdk)

Tools you need

Skills and add-ons

Read any skill before you install it. A skill is a set of instructions that Claude will follow. See Tools and Skills for the full list and safety notes.

Claude setup for this system

Cut Saturn work by program, by address and by recorded run. On Path A, one unit is one runtime gap seen in one golden run, or one discovery miss. On Path B, one unit is one translation unit, or a batch of five boundary checks. Every unit has one check: the self-test, a golden run hash, or make check. Pass disc paths as absolute paths.

Which model and effort for each job

The model and effort names come from one shared table, so they stay the same on every guide. See Claude Setup for the reasons.

How many sessions at once

Lines for this project's CLAUDE.md

- Read `SCOPE.md`, `PROGRESS.md` and `notes/findings.md` at the start of every session.
- Never edit generated C++ under `build/` or `work/`. Fix `game.toml`, a discovery seed or the runtime, then regenerate.
- Never edit the toolkit copy in this repo. Toolkit fixes go upstream or into `patches/` as numbered patches on the pinned commit.
- No stubs and no faked hardware events. If the game waits on hardware, find the missing behavior and report it.
- The one check is `bash tools/check.sh <ABSOLUTE_PATH_TO_CUE>` (Path A) or `make check` in WSL (Path B). No pasted output means not done.
- Do not edit `refs/hashes.txt`, `config/*.sha256`, golden pictures or check scripts. A change needs my approval in the same commit as its cause.
- Disc images, BIOS files and anything extracted stay in `iso/`, `extracted/` and `build/`. Never commit or paste their bytes.
- A unit is matched only when `make check` is byte-identical. Close or equivalent is reported as attempted or equivalence-verified, never matched.
- Report the interpreter fallback count with every Path A result. Fallback is not recompiled code.
- In a worktree, use absolute paths for the disc and the tools. From Git Bash, set `MSYS_NO_PATHCONV=1` before calling `wsl`.
- Propose commits. Do not commit on your own.
- Write side issues in `notes/parking-lot.md` and dead ends in `notes/findings.md`. Start every report with DONE, PARTIAL or BLOCKED.

Keep the context small

• Never read a generated C++ file whole. Search for the address, then read 30 lines.
• Give Claude the first differing VBlank and both pictures, not a whole trace log.
• Pass program names and addresses. Let Claude disassemble just that range with saturnkit.sh2 --at --count.
• Add Read deny rules for iso/**, extracted/**, build/** and work/**.
• Use a subagent to read a big discovery report and return only the gaps.
• Clear the chat after each unit. The ledgers carry the state.

More prompts for this system

Each step above has its own prompt. These extra prompts cover the rest of the work. Fill in the parts in <ANGLE_BRACKETS>.

GOAL: Tell me if <GAME> (Saturn, product code <PRODUCT_CODE>) can be ported to PC by static recompilation, and draft SCOPE.md.
READ FIRST: https://github.com/vs-sr-dev/saturnkit , https://github.com/callumjenkins/saturn-recomp , https://github.com/tmcleroy/satrecomp , https://github.com/blythos/atolm (READMEs only).
FENCE: Edit only `SCOPE.md` and `notes/prior-work.md`. Do not install anything. Do not open disc files.
CHECK: Done means SCOPE.md names the toolkit, the first milestone and its check, and notes/prior-work.md lists every repo for this game or engine with a URL and its status.
BUDGET: Stop after 1 hour.
IF BLOCKED: Stop. Say plainly if a path is not realistic and why.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the repo list. 3) Files changed. 4) Risks you see. 5) New parking-lot items.

GOAL: Map <PROGRAM> loaded at <ADDR>: functions, library code and gaps.
READ FIRST: notes/disc.md, `build/<PROGRAM>.report.txt`, `build/ghidra/<PROGRAM>.funcs.txt`.
FENCE: Edit only `notes/functions.csv` and `notes/discovery-gaps.md`. Do not edit game.toml, the toolkit or generated code.
CHECK: Done means every function has address, size, name or `FUN_` placeholder, proof and status, and every Ghidra-only function has a reason in notes/discovery-gaps.md.
BUDGET: Stop after 2 hours.
IF BLOCKED: Stop. List addresses you cannot classify.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: counts by status. 3) Files changed. 4) Open gaps. 5) New parking-lot items.

GOAL: Fix the hang at VBlank <N> in movie <MOVIE> of <GAME>.
READ FIRST: notes/findings.md, the last 200 lines of `build/run.log`, `build/shots/<N>.png`, `refs/<N>.png`.
FENCE: Edit only `<RUNTIME_FILE>` and `notes/`. No stubs, no skipped waits, no generated-code edits.
CHECK: Run `bash tools/golden.sh <ABSOLUTE_PATH_TO_CUE>`. Done means this movie passes VBlank <N> and all others still pass.
BUDGET: Stop after 3 fix ideas.
IF BLOCKED: Stop. Show the loop the game waits in and the hardware register it reads.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: golden.sh output. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Match unit <UNIT> of <PROGRAM> byte for byte.
READ FIRST: SCOPE.md, `asm/<UNIT>/`, one matched example `src/<EXAMPLE>.c`, notes/findings.md.
FENCE: Edit only `src/<UNIT>.c`. No inline asm, no `.byte`, no new flags, no edits to hashes or the Makefile.
CHECK: In WSL run `make check`. Done means the program is byte-identical with this unit built from C.
BUDGET: Stop after 8 attempts. Save each attempt as `scratch/<UNIT>/try-<K>.c`.
IF BLOCKED: Stop. Paste the smallest remaining diff and mark the unit attempted in notes/findings.md.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: make check output. 3) Files changed. 4) Remaining diff if any. 5) New parking-lot items.

GOAL: Pick the next <N> units and give each worker one task card.
READ FIRST: PROGRESS.md, config/units.csv, notes/findings.md.
FENCE: Edit only `PROGRESS.md` and `notes/assignments.md`. Do not write C. Each worker gets its own worktree at `<ABSOLUTE_WORKTREE_ROOT>/<UNIT>`.
CHECK: Done means notes/assignments.md lists each unit, its worker, its worktree path and its card, and no unit is given twice.
BUDGET: Stop after <N> units are assigned.
IF BLOCKED: Stop. Say which units are not ready and why.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the assignment table. 3) Files changed. 4) Units left. 5) New parking-lot items.

GOAL: Prove the cause of <SYMPTOM>. Do not fix it yet.
READ FIRST: notes/findings.md, `movies/<MOVIE>.txt`, `build/shots/` and `refs/` around VBlank <N>.
FENCE: Edit only `notes/debug-<SYMPTOM>.md`. Read-only everywhere else. Use `--watch`, `--peek` and `--trace` runs only.
CHECK: Done means the note names the first wrong memory write, its address, the function that made it, and a second run that shows the same thing.
BUDGET: Stop after 6 runs.
IF BLOCKED: Stop. List what you ruled out and the next run you would make.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the watch output lines. 3) Files changed. 4) Proposed fix, not applied. 5) New parking-lot items.

GOAL: Check that the work in commits <FROM>..<TO> is real.
READ FIRST: CLAUDE.md, PROGRESS.md, `git diff <FROM>..<TO> --stat`.
FENCE: Read-only. Write only `notes/verify-<DATE>.md`.
CHECK: Rerun `bash tools/check.sh <ABSOLUTE_PATH_TO_CUE>` and `bash tools/golden.sh <ABSOLUTE_PATH_TO_CUE>` (or `make check`). Done means you pasted the output and checked the diff for: edited hashes or refs, edits under build/ or the toolkit copy, stubs, skipped waits, inline asm or .byte in src/, and fallback counted as recompiled.
BUDGET: Stop after 1 hour.
IF BLOCKED: Stop. Report what you could not run.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) PASS or FAIL. 2) Proof: check output. 3) Each suspect change with file and line. 4) What to redo. 5) New parking-lot items.

GOAL: Write a status report from the ledgers only.
READ FIRST: PROGRESS.md, notes/functions.csv, config/units.csv, notes/findings.md, notes/parking-lot.md.
FENCE: Edit only `notes/status-<DATE>.md`. Do not run builds.
CHECK: Done means every number in the report comes from a ledger file, with the file named next to it.
BUDGET: Stop after 20 minutes.
IF BLOCKED: Stop. Say which ledger is missing or stale.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Golden runs passing, fallback count, units matched, attempted, equivalence-verified and unattempted. 3) Top 3 blockers. 4) Parking-lot items I must decide.

GOAL: Save everything the next session needs into the repo.
READ FIRST: PROGRESS.md, notes/findings.md, `git status`.
FENCE: Edit only `PROGRESS.md`, `notes/findings.md` and `notes/next-session.md`. Do not change code.
CHECK: Done means notes/next-session.md lists the current unit, the last check output, the next command to run, and open questions, and a fresh session could start from it alone.
BUDGET: Stop after 15 minutes.
IF BLOCKED: Stop. Say what you could not record.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the text of notes/next-session.md. 3) Files changed. 4) Uncommitted work. 5) New parking-lot items.

GOAL: Tell me plainly whether <TASK> can be done with what we have.
READ FIRST: notes/findings.md entries for <TASK>, the last three reports on it.
FENCE: Read-only. Write only `notes/blocked-<TASK>.md`.
CHECK: Done means the note says YES, NO or NOT YET, the exact reason, the evidence, and two or three options with their cost.
BUDGET: Stop after 30 minutes.
IF BLOCKED: Stop. Say what evidence is missing.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) YES, NO or NOT YET. 2) Proof. 3) Options. 4) What you need from me.

GOAL: Ask me before leaving the fence for <CHANGE>.
READ FIRST: SCOPE.md, CLAUDE.md.
FENCE: Do not make the change. Write only `notes/scope-request-<CHANGE>.md`.
CHECK: Done means the request says what change, which files, why the current task needs it, the risk, and how we would check it.
BUDGET: Stop after 15 minutes.
IF BLOCKED: Stop and ask.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) The request. 2) What happens if I say no. 3) Files that would change.

Keep Claude on task

These are the detours Claude tends to take on this system, and the rule that stops each one. The full method is on Stay on Task.

Problems other projects hit

How long it takes

What makes it faster or slower

• Whether a toolkit already handles your game's compiler and libraries. SHC or GCC patterns new to the toolkit add days each.
• How the game uses the CD. Streaming movies and CD music need careful drive timing.
• How many overlay programs the disc has. Virtual Hydlide has 15. Each needs its own load address.
• For Path B, whether the exact compiler survives. Without it, some units may never match.
• Your review time. Each fix needs a look at its proof, and that is your 10 to 15 hours a week.

The facts behind these numbers

Projects reviewed (13)

Fewer than 10 games on RecompLauncher: it lists only 2 Saturn games, and both were reviewed. 11 more projects came from outside it, one per game, for 13 games in all. Most are young and have 1 to 5 stars.

What each project teaches

What we could not check

• Which compiler the Symphony of the Night Saturn build matches with. The saturn-splitter README names a Cygnus DOS compiler run under dosemu, but the sotn-decomp files we read do not say.
• Whether ApplySig.py, a 2020 script, runs in Ghidra 12. Daytona used it, but its Ghidra version is not stated.
• Whether the loader's 12.0.0 zip installs in Ghidra 12.0.1 to 12.0.4. Its file name says 12.0.
• Where the saturn runtime saves --shot pictures. The saturnkit README does not say, so the check script in Path A step 2 copies them.
• Whether saturnrecomp.reference works with Japanese discs. Its README names only mpr-17933.bin for US and European discs.
• Whether mednafen-saturn-debug builds with a plain ./configure && make. Its README says so, but SaturnAutoRE builds it with a GCC 4.9.4 cross script.
• Whether objdiff reads Hitachi SHC object files. Its README lists SuperH, but no reviewed Saturn project used it.
• AI use in most reviewed projects. Only Baroque, Daytona and the saturn-recomp toolkit state it. Others only hint at it.
• Whether any reviewed port is playable from start to end. None claims a full playthrough.
• The licence status of the period compilers that project scripts fetch. This guide does not name a download source.
• Whether Ghidra 12.0, JDK 21, the Saturn loader and GhidrAssistMCP 2.8.0 work together. Each version comes from a README or release name. None of the tools in this guide was installed or run for this check.
• How long the Path A projects worked before their first commit. Repo dates can hide earlier work.

Sources

• saturnkit README
• saturn-recomp README
• satrecomp README
• SaturnRecomp README
• atolm README and CLAUDE.md
• saturn-splitter README
• Ghidra Sega Saturn Loader README
• Ymir README
• Mednafen Saturn documentation
• SaturnAutoRE README
• mednafen-saturn-debug README
• GhidrAssistMCP README
• m2c README
• asm-differ README
• objdiff README
• Saturn-SDK-GCC-SH2 README
• Ubuntu package binutils-sh-elf (noble)
• MSYS2 package mingw-w64-x86_64-sdl3
• Rodrigo Copetti, Sega Saturn architecture
• Retro Reversing, official Sega Saturn SDK
• Sega Saturn FAQ, GNU development environment
• Sega Saturn documentation list (antime)
• decomp.dev page for sotn-decomp
• decomp.dev page for the sotn-decomp Saturn version
• Beetle Saturn libretro README (BIOS names)
• Ghidra 12.0 README (JDK 21)
• GhidrAssistMCP releases (Ghidra version per zip)
• Ghidra Sega Saturn Loader releases
• splat README (supported platforms)
• Claude Code MCP docs (`claude mcp add --transport http`)