Nintendo 64 decomp guide

What this system is like

The Nintendo 64 has some of the most finished tools of any console. A free tool called N64Recomp turns the game's code into C. A runtime and a renderer then run that C on your PC. Five of the fifteen projects we read used this road.

The other road is a full decomp. You write C that the game's own compiler turns back into the exact same bytes. The compilers are known, and community builds of them run on Linux today. Many big N64 games already have a finished decomp, so check first.

AI helps a lot here, but it does not do the job alone. One developer matched a whole N64 game with agents in 84 days. He was already an expert, and other experts still helped with about one match in twenty. The upstream recomp teams refuse AI-written code. They also ask that AI not be used to study their code. So use their tools as released, and keep your own work in your own repo.

Recomp builds run on Windows. Matching builds run best in WSL. Your ROM never goes in the repo.

Two paths

Path A: Get it running on PC

You give N64Recomp the ROM and a list of functions. It writes C for every function. You build that C with N64ModernRuntime and RT64 into a Windows program. Then you fix one crash or missing call at a time. You fix the config, never the made code.

1. Scope the game and look for prior work

   Pick one game and one exact ROM version. Check if a decomp, symbol list or recomp exists. A decomp saves weeks, because it names the functions for you. Write it all in SCOPE.md.

   • Dump your own cartridge. Get its SHA-1 with sha1sum baserom.us.z64 in WSL, or certutil -hashfile baserom.us.z64 SHA1 in Windows.
   • Search GitHub for <GAME> decomp and <GAME> recomp. Look at the n64decomp and zeldaret groups.
   • Check the RecompLauncher list for a recomp of the same game.
   • Write SCOPE.md: game, region, SHA-1, goal, technique, first milestone and its check.
   • Make notes/parking-lot.md and PROGRESS.md as empty files.
   Prompt for ClaudeCopy

   GOAL: Write a one-page `SCOPE.md` for a static recomp of <GAME> (<REGION>, SHA-1 <HASH>).
   READ FIRST: `notes/prior-work.md` (my search results). Do not open the ROM.
   FENCE: Edit only `SCOPE.md` and `notes/prior-work.md`. Everything else is read-only. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `grep -c "^## " SCOPE.md`. Done means it prints 7 or more, for these headings: Goal, ROM and hash, Technique, Prior work, Milestone 1 and its check, Out of scope, Never edit. Every heading has real content and every prior-work claim has a URL.
   BUDGET: Stop after 30 minutes or 3 drafts.
   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 headings. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whengrep -c "^## " SCOPE.md prints 7 or more, and you approved the file.

   Proof this works: WinBack Recompiled, Marchwind64, Donkey Kong 64: Recompiled

2. Set up the repo and the tools

   Copy the layout of a recent recomp. WinBack Recompiled is a good model, and it was built with Claude Code. Banjo: Recompiled is thinner, but its team asks that AI not be used on it, so read that one yourself. Install the build tools on Windows and build N64Recomp from source. Keep the ROM and all made code out of git.

   • Install Visual Studio 2022 with "Desktop development with C++", "C++ Clang compiler for Windows" and "C++ CMake tools for Windows". Also install Ninja, Python 3 and Git. WinBack used a separate LLVM install for clang-cl; either works.
   • Run every cmake command inside the Visual Studio x64 build setup. Copy WinBack's tools\vsenv.cmd: it calls vcvars64.bat, puts LLVM on the path, then runs your command.
   • Clone the recompiler: git clone --recurse-submodules https://github.com/N64Recomp/N64Recomp deps/N64Recomp.
   • Build it as WinBack does: tools\vsenv.cmd cmake -S deps/N64Recomp -B deps/N64Recomp/build -G Ninja -DCMAKE_BUILD_TYPE=Release, then tools\vsenv.cmd cmake --build deps/N64Recomp/build. This makes N64Recomp and RSPRecomp.
   • Add N64ModernRuntime and RT64 as git submodules, pinned to one commit each.
   • Make a Python venv: python -m venv .venv, then .venv/Scripts/python -m pip install "splat64[mips]".
   • Put rom/, generated/, build/ and deps/ in .gitignore.
   • Write one check script, for example tools/check.ps1, that regenerates and builds.
   Prompt for ClaudeCopy

   GOAL: Lay out the repo for a <GAME> recomp so one command regenerates and builds, even if the build is still empty.
   READ FIRST: `SCOPE.md`, the WinBack layout notes at https://github.com/RetroPulse03/WinBackRecomp/blob/main/docs/DEVELOPMENT.md, the `N64Recomp` README.
   FENCE: Edit only `CMakeLists.txt`, `tools/`, `config/`, `.gitignore`, `CLAUDE.md`, `PROGRESS.md`. Never copy the ROM or anything made from it into git. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `powershell -File tools/check.ps1`. Done means it exits 0 and `git status` shows no file from `rom/` or `generated/`.
   BUDGET: Stop after 3 failed tries, or 45 minutes with no progress.
   IF BLOCKED: Stop. Do not work around it. Tell me what blocked you, what you tried, and what you need from me. Do not install anything system-wide; ask me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the check output and `git status`. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whentools/check.ps1 exits 0 on a fresh clone, and git status lists no ROM-derived file.

   Proof this works: WinBack Recompiled, Banjo: Recompiled, https://github.com/N64Recomp/N64Recomp

3. Decompress and split the ROM

   Some games pack their code. Unpack it first, or the recompiler reads noise. Then split the ROM with splat so you know where code and data sit. This gives Claude a map of small pieces.

   • If the game uses compression, use the unpacker its decomp uses. Zelda used z64decompress. Banjo used bk_rom_compressor.
   • Make a first config: .venv/Scripts/python -m splat create_config rom/baserom.us.z64. It writes a .yaml file named from the ROM header into the current folder.
   • Move that file to config/<game>.us.yaml and fix the paths inside it, as WinBack did.
   • Split it: .venv/Scripts/python -m splat split config/<game>.us.yaml.
   • List every overlay: where it sits in the ROM and where it loads in RAM.
   • Hash the unpacked ROM and write that hash in SCOPE.md too.
   Prompt for ClaudeCopy

   GOAL: Produce a `splat` config for <GAME> that splits the ROM with no errors and lists every code segment and overlay.
   READ FIRST: `SCOPE.md`, `config/<game>.us.yaml`, the `splat` wiki pages on segments.
   FENCE: Edit only `config/<game>.us.yaml` and `notes/segments.md`. The ROM and everything in `generated/` are read-only. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `.venv/Scripts/python -m splat split config/<game>.us.yaml`. Done means it ends with no error and `notes/segments.md` lists each segment with ROM start, RAM address and size.
   BUDGET: Stop after 5 failed tries, or 60 minutes with no progress.
   IF BLOCKED: Stop. Do not work around it. If the code looks compressed, say so and stop. Tell me 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 split output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done when.venv/Scripts/python -m splat split config/<game>.us.yaml exits 0 and notes/segments.md lists every code segment and overlay with addresses.

   Proof this works: WinBack Recompiled, Zelda 64: Recompiled, Banjo: Recompiled

4. Name the library code and write the symbols file

   N64Recomp swaps libultra functions for its own versions by name. A missed name means the old code pokes hardware that is not there. So find and name every library function first. Then write the symbols file the recompiler reads.

   • Scan with n64sym rom/baserom.us.z64 -s -f splat -o config/n64sym_addrs.txt.
   • Check each hit by hand. The tool warns that ROM scans can be wrong.
   • Keep hand-made names in config/symbol_addrs.txt.
   • Write a small script that turns the split plus names into the N64Recomp symbols TOML. WinBack calls it tools/gen_recomp_syms.py.
   • Point the main config at it with symbols_file_path. You need no ELF file; Banjo leaves elf_path out.
   • If a decomp exists, take its names instead, like Zelda and Banjo did.
   Prompt for ClaudeCopy

   GOAL: Build `config/<game>.syms.toml` with every function's name, address and size, with all libultra functions named.
   READ FIRST: `notes/segments.md`, `config/n64sym_addrs.txt`, `config/symbol_addrs.txt`, `tools/gen_recomp_syms.py`.
   FENCE: Edit only `config/symbol_addrs.txt`, `tools/gen_recomp_syms.py` and `notes/library.md`. Never edit files in `generated/`. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `.venv/Scripts/python tools/gen_recomp_syms.py` then `deps/N64Recomp/build/N64Recomp config/<game>.us.toml`. Done means both exit 0 and `notes/library.md` lists each libultra function with how you confirmed it.
   BUDGET: Stop after 5 failed tries, or 60 minutes with no progress.
   IF BLOCKED: Stop. Do not guess a name you cannot confirm. Mark it UNCONFIRMED in `notes/library.md` and tell me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste both command outputs. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whendeps/N64Recomp/build/N64Recomp config/<game>.us.toml exits 0 and every libultra function in notes/library.md is named and checked.

   Proof this works: WinBack Recompiled, Marchwind64, https://github.com/shygoo/n64sym

5. First light: boot to the first frame

   Run the recompiler on the whole game. Recompile the audio microcode too. Build it all with the runtime and the renderer. The goal is one window with the game's first picture in it.

   • Run deps/N64Recomp/build/N64Recomp config/<game>.us.toml to write the C into generated/.
   • Run deps/N64Recomp/build/RSPRecomp config/aspMain.us.toml for the audio microcode.
   • Configure: tools\vsenv.cmd cmake -S . -B build -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_BUILD_TYPE=RelWithDebInfo.
   • Build: tools\vsenv.cmd cmake --build build.
   • Run the game and save a screenshot of the first frame.
   Prompt for ClaudeCopy

   GOAL: Build <GAME> with `N64Recomp`, `N64ModernRuntime` and `RT64` and show the first frame (the logo).
   READ FIRST: `SCOPE.md`, `config/<game>.us.toml`, `config/aspMain.us.toml`, `CMakeLists.txt`.
   FENCE: Edit only `config/`, `src/main/`, `src/game/` and `CMakeLists.txt`. Never edit `generated/` or `deps/`. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `powershell -File tools/check.ps1`, then start the game for 20 seconds. Done means the build exits 0 and a screenshot shows the logo. A build that only compiles is not done.
   BUDGET: Stop after 5 failed tries, or 90 minutes with no progress.
   IF BLOCKED: Stop. Do not stub a call to fake progress. Tell me the exact error and what you tried.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: build output tail and the screenshot path. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe built program opens a window and a saved screenshot shows the game's first logo.

   Proof this works: Zelda 64: Recompiled, Banjo: Recompiled, WinBack Recompiled

6. Build a way to run the game with no person

   Claude cannot hold a controller. Add switches that press buttons at set times, jump to a level and save screenshots. Then every fix can be checked by a script. This is the golden run from the method.

   • Add environment variables for scripted input, like WinBack's WINBACK_AUTOPRESS and WINBACK_JUMP.
   • Write tools/capture_test.ps1 that runs the game for N seconds and saves screenshots and a log.
   • Print plain log lines for key events, like scene loaded or save written.
   • Optional: expose the same controls as an MCP server, like Super Robot Wars 64 did.
   • Write three golden runs: boot to title, start a new game, reach the first level.
   Prompt for ClaudeCopy

   GOAL: Add a scripted run mode so `tools/capture_test.ps1 <SCRIPT>` boots <GAME>, plays a fixed input list, and saves screenshots and a log.
   READ FIRST: `src/main/`, `src/game/`, `notes/runs.md`.
   FENCE: Edit only `src/main/`, `src/game/debug_*`, `tools/capture_test.ps1` and `tests/runs/`. Never edit `generated/`. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `powershell -File tools/capture_test.ps1 tests/runs/boot_to_title.txt`. Done means it exits 0, saves at least 3 screenshots, and the log shows the title scene line.
   BUDGET: Stop after 4 failed tries, or 60 minutes with no progress.
   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 log lines and list the screenshots. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whentools/capture_test.ps1 tests/runs/boot_to_title.txt exits 0 and its log shows the title scene.

   Proof this works: WinBack Recompiled, Marchwind64

7. Grind: one crash or one bad frame at a time

   Now play through the game in small steps. Each card fixes one crash, one hang or one wrong picture. Fix it in the config, a hook or a C patch. Check drawing against a trusted emulator, not by eye.

   • Log each bug in PROGRESS.md with the run that shows it.
   • Fix odd code in the TOML: stubs, ignored, manual_funcs, function_sizes, [[patches.hook]].
   • Write game changes as C in patches/ and run them back through N64Recomp.
   • For a hang, look for loops that wait on another thread. The runtime only switches threads inside libultra calls.
   • Compare frames with the ares emulator or ParaLLEl-RDP output.
   • Write each root cause to notes/bugs/<topic>_<date>.md.
   Prompt for ClaudeCopy

   GOAL: Fix bug <BUG_ID> (<ONE-LINE SYMPTOM>) so golden run `<RUN>` passes.
   READ FIRST: `PROGRESS.md` entry <BUG_ID>, `notes/bugs/`, the log from `tools/capture_test.ps1 <RUN>`.
   FENCE: Edit only `config/`, `patches/`, `src/game/`. Never edit `generated/`; change the config and regenerate. Fix drawing bugs in the renderer patches, never by changing game code. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `powershell -File tools/check.ps1` and then `tools/capture_test.ps1 <RUN>`. Done means both pass and all older golden runs still pass.
   BUDGET: Stop after 3 failed fixes, or 60 minutes with no progress.
   IF BLOCKED: Stop. Do not stub the failing call. Tell me the cause you proved, what you tried, 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: paste all golden run results. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe golden run for the bug passes, and every older golden run still passes.

   Proof this works: WinBack Recompiled, Donkey Kong 64: Recompiled, Marchwind64

8. Harden: regression runs, pins and a clean release

   Make sure old fixes stay fixed. Pin every tool to one commit. Keep your fixes to other people's code as patch files. Ship a build with no game data, and have it check the player's ROM hash.

   • Run every golden run after each change, using one script: tools/run_all.ps1.
   • Pin N64Recomp, N64ModernRuntime and RT64 commits in a file, like WinBack's pinned list.
   • Keep changes to them as numbered files in patches/ with one reason each.
   • Make the game refuse any ROM whose SHA-1 is wrong.
   • Build from a clean clone and run all golden runs before you call it a release.
   Prompt for ClaudeCopy

   GOAL: Make <GAME> rebuild from a clean clone and pass every golden run, with pinned deps and no ROM data in the output.
   READ FIRST: `PROGRESS.md`, `patches/README.md`, `tools/run_all.ps1`.
   FENCE: Edit only `tools/`, `patches/README.md`, `deps.lock` and `PROGRESS.md`. Do not change game behavior. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: In a fresh clone, run `powershell -File tools/check.ps1` then `tools/run_all.ps1`. Done means both exit 0 and the release folder holds no ROM-derived file.
   BUDGET: Stop after 3 failed tries, or 60 minutes with no progress.
   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 run_all summary. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenA fresh clone builds with one command, every golden run passes, and the release has no game data.

   Proof this works: WinBack Recompiled, Zelda 64: Recompiled, Ship of Harkinian

Path B: Full decomp for porting

You split the ROM, then write C for each function. The game's own compiler must turn your C into the same bytes. A script rebuilds the whole ROM and checks its hash. When every function matches, you swap the console parts for PC parts with libultraship and Torch.

1. Scope: prior work and the compiler

   Check for an existing decomp before anything else. Then make a first guess at which compiler built the game. IDO and GCC leave different marks in the code. The wrong compiler can never match. You prove the guess later, in the first-light step.

   • Search GitHub and decomp.dev for <GAME> decomp.
   • Look up decomps of the studio's other games and note their compiler.
   • If you already split the ROM for Path A, look at a few functions. IDO and KMC GCC lay out stack frames in different ways.
   • Ask in the N64 decomp Discord which compiler the studio's other games used.
   • Write the compiler guess, its evidence and the ROM SHA-1 in SCOPE.md.
   Prompt for ClaudeCopy

   GOAL: Name the most likely compiler and flags for <GAME>, with evidence, so the first-light step can prove it.
   READ FIRST: `SCOPE.md`, `notes/prior-work.md`, and if they exist, three small functions in `asm/` that I name: <FUNC1>, <FUNC2>, <FUNC3>.
   FENCE: Edit only `SCOPE.md` and `notes/compiler.md`. Everything else is read-only. Do not install anything. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `grep -E "^(Compiler|Flags|Evidence):" notes/compiler.md`. Done means all three lines print, and Evidence lists at least two sources with URLs or file paths.
   BUDGET: Stop after 30 minutes.
   IF BLOCKED: Stop. Say which compilers you ruled out and why. Do not guess without evidence.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the grep output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whengrep -E "^(Compiler|Flags|Evidence):" notes/compiler.md prints three lines, and you approved the guess in SCOPE.md.

   Proof this works: https://blog.chrislewis.au/decompiling-a-nintendo-64-game-in-84-days/, https://github.com/decompals/ido-static-recomp, https://github.com/decompals/mips-gcc-2.7.2

2. Set up the matching build in WSL

   Matching builds are made for Linux. Clone into the WSL file system, not under /mnt/c. Set up the old compiler, splat and a build that prints OK when the ROM matches. That OK is your one check.

   • In Ubuntu: sudo apt install make git python3 python3-venv python3-pip binutils-mips-linux-gnu.
   • Make a venv: python3 -m venv .venv, then .venv/bin/pip install -U "splat64[mips]".
   • Download the Linux build of ido-static-recomp (IDO 5.3 or 7.1) or mips-gcc-2.7.2 into tools/.
   • Vendor asm-processor into tools/ if the game uses IDO.
   • Write tools/build-and-verify.sh that rebuilds and checks the ROM SHA-1.
   • Add Claude Code hooks that block edits to the .sha1 file and to asm/.
   Prompt for ClaudeCopy

   GOAL: Make `./tools/build-and-verify.sh` rebuild <GAME> from the split assembly and print `OK` because the SHA-1 matches.
   READ FIRST: `SCOPE.md`, `Makefile`, the `splat` config, the Snowboard Kids decomp README as a pattern.
   FENCE: Edit only `Makefile`, `tools/`, `.claude/settings.json` and `CLAUDE.md`. Never edit `<game>.sha1` or `asm/`. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `./tools/build-and-verify.sh`. Done means the last line is `build/<game>.z64: OK`. Then break one byte in a copy and show the check fails.
   BUDGET: Stop after 5 failed tries, or 90 minutes with no progress.
   IF BLOCKED: Stop. Do not edit the expected hash. 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 both check outputs. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done when./tools/build-and-verify.sh prints OK on a clean clone, and fails when one byte is changed.

   Proof this works: https://github.com/cdlewis/snowboardkids-decomp, https://github.com/zeldaret/oot, https://github.com/ethteck/splat

3. Map the binary into a function ledger

   List every function with its size and a status column. Mark library code, so nobody matches it by hand. Sort the rest from easy to hard. This file is the to-do list for every worker.

   • Name libultra functions with n64sym, then compare against ultralib sources.
   • Write ledger.csv with columns: name, file, address, size, status, owner.
   • Mark library functions as lib and try the matching ultralib version first.
   • Run m2c on every function once as a cheap first pass. Keep only exact matches.
   • Sort the rest by size and by likeness to already-matched code.
   Prompt for ClaudeCopy

   GOAL: Write `ledger.csv` listing every function in <GAME> with address, size and status, with libultra marked.
   READ FIRST: `SCOPE.md`, the `splat` config, `asm/` file list, `notes/library.md`.
   FENCE: Edit only `ledger.csv`, `tools/make_ledger.py` and `notes/library.md`. `asm/` is read-only. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `python3 tools/make_ledger.py --verify`. Done means it reports zero functions missing from the ledger and the size total equals the code size from `splat`.
   BUDGET: Stop after 4 failed tries, or 60 minutes with no progress.
   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 verify output and counts by status. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whentools/make_ledger.py --verify reports no missing functions and sizes add up.

   Proof this works: https://blog.chrislewis.au/decompiling-a-nintendo-64-game-in-84-days/, https://github.com/decompals/ultralib, https://github.com/matt-kempster/m2c

4. First light: match one function end to end

   Prove the whole loop on one small function. Swap its assembly for C. Rebuild. The full ROM hash must still match. Now you know the pipeline works, and that your compiler guess was right.

   • Pick a short function with no loops from the ledger.
   • If no flag set matches after a few tries, go back to notes/compiler.md and try the next compiler guess.
   • Get a draft with python3 tools/m2c/m2c.py -t mips-ido-c asm/<file>.s (use mips-gcc-c for GCC games).
   • Put the C in src/, replacing its INCLUDE_ASM line.
   • Check the diff with asm-differ or objdiff.
   • Run ./tools/build-and-verify.sh and commit only if it prints OK.
   Prompt for ClaudeCopy

   GOAL: Match function <FUNC> in `src/<FILE>.c` so the full ROM still builds to the original SHA-1.
   READ FIRST: `asm/nonmatchings/<FILE>/<FUNC>.s`, `include/`, the m2c draft.
   FENCE: Edit only `src/<FILE>.c` and its header. Never edit `asm/`, the `.sha1` file or the build scripts. No inline assembly. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `./tools/build-and-verify.sh`. Done means it prints `OK` and the `INCLUDE_ASM` line for <FUNC> is gone.
   BUDGET: Stop after 10 attempts with no gain. Save each attempt as a new file `scratch/<FUNC>_n.c`.
   IF BLOCKED: Stop. Report the best diff score and the first differing instructions.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the check output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenOne INCLUDE_ASM is gone, C is in its place, and build-and-verify.sh prints OK.

   Proof this works: https://blog.chrislewis.au/the-unexpected-effectiveness-of-one-shot-decompilation-with-claude/, https://github.com/simonlindholm/asm-differ

5. Grind: the bulk worker loop

   Now match functions one per session. A script picks the next one, not Claude. Each worker gets its own git worktree. Commit after every match and reset after every failure.

   • Run 3 or 4 worktrees: git worktree add ../wt1 -b wt1.
   • Split the ledger between them so no two workers touch one file.
   • Run one function per headless session: claude -p "<CARD>". It runs once and exits.
   • For runs with nobody watching, pre-approve only the tools the card needs with --allowedTools, and add --permission-mode dontAsk so anything else is refused.
   • After each run: if build-and-verify.sh passes, commit; if not, git reset --hard.
   • Merge worktrees often, and run the full check again after each merge.
   • Update ledger.csv and PROGRESS.md from the commits, not from chat.
   Prompt for ClaudeCopy

   GOAL: Match function <FUNC> (ledger row <ROW>) in worktree <WT>.
   READ FIRST: `CLAUDE.md`, `notes/compiler-quirks.md`, `asm/nonmatchings/<FILE>/<FUNC>.s`, up to 3 similar matched functions: <REFS>.
   FENCE: Work only in the absolute path <WT>. Edit only `src/<FILE>.c` and `scratch/`. Never edit `asm/`, the `.sha1` file, `tools/` or other files. No inline assembly or register pins. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `<WT>/tools/build-and-verify.sh`. Done means it prints `OK` and <FUNC> is C.
   BUDGET: Stop after 10 attempts with no gain, or 25 minutes.
   IF BLOCKED: Stop. Write <FUNC> and the best score in `notes/hard.md`. Do not try the next function.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the check output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe ledger's matched count rises, and build-and-verify.sh prints OK on the merged main branch.

   Proof this works: https://blog.chrislewis.au/decompiling-a-nintendo-64-game-in-84-days/, https://github.com/cdlewis/nigel, BattleShip

6. The hard tail: big functions and compiler quirks

   The last tenth is the hardest part. Huge functions, display lists and matrix math resist matching. Use the permuter only as an idea source. Ask human experts. Record every trick in one shared quirks file.

   • Send functions from notes/hard.md to hard sessions, one at a time.
   • Run decomp-permuter from its folder: ./import.py <REPO>/src/<file>.c <REPO>/asm/nonmatchings/<file>/<func>.s, then ./permuter.py nonmatchings/<func> -j 4.
   • Have Claude explain any permuter win before keeping it.
   • Write general compiler tricks in notes/compiler-quirks.md, never one-off notes.
   • Post the hardest ones on decomp.me and ask in the N64 decomp Discord.
   Prompt for ClaudeCopy

   GOAL: Match hard function <FUNC>, or prove what blocks it.
   READ FIRST: `notes/hard.md` entry for <FUNC>, `notes/compiler-quirks.md`, earlier attempts in `scratch/<FUNC>_*.c`.
   FENCE: Edit only `src/<FILE>.c`, `scratch/` and `notes/compiler-quirks.md`. No inline assembly, `asm("")` barriers, register pins or compiler changes. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `./tools/build-and-verify.sh`. Done means it prints `OK` with <FUNC> in plain C.
   BUDGET: Stop after 15 attempts with no gain, or 60 minutes.
   IF BLOCKED: Stop. Name the exact differing instructions and your best idea of why. "Compiler artifact" alone is not an answer.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the check output or the best diff. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenEvery ledger row is matched or has a written blocker that a person has read.

   Proof this works: https://blog.chrislewis.au/the-long-tail-of-llm-assisted-decompilation/, https://github.com/simonlindholm/decomp-permuter

7. Harden the decomp and hunt for cheats

   A fresh agent checks the claimed work. It rebuilds from scratch and searches for banned tricks. Bad matches go back to the queue. Clean names and types help the port later.

   • Clone fresh and run ./tools/build-and-verify.sh.
   • Search for cheats: grep -rn -E "__asm__|asm\(|register .* asm" src/.
   • Check git log -p for any change to the .sha1 file or asm/.
   • Rename func_XXXX names to real names as you learn them.
   • Turn pointer math into struct access where you can.
   Prompt for ClaudeCopy

   GOAL: Independently check the last <N> matched functions and list any that cheat.
   READ FIRST: `CLAUDE.md` rules on banned constructs, `git log --oneline -<N>`.
   FENCE: Read-only. Edit only `notes/verify-<DATE>.md`. Do not fix anything. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: In a fresh clone, run `./tools/build-and-verify.sh` and the grep for inline assembly. Done means the report lists every function as CLEAN or SUSPECT, with the reason.
   BUDGET: Stop after 45 minutes.
   IF BLOCKED: Stop. Tell me what you could not check and why.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the build output and grep output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenA fresh clone prints OK, and the verify report shows no SUSPECT function left unresolved.

   Proof this works: https://blog.chrislewis.au/the-long-tail-of-llm-assisted-decompilation/, https://github.com/cdlewis/snowboardkids2-decomp

8. Port: put the decomp on libultraship

   Now swap the console parts for PC parts. libultraship replaces libultra and draws display lists. Torch pulls assets from the player's ROM. First make every file compile on PC, then link.

   • Add libultraship and Torch as pinned git submodules. Fork them only if you must.
   • Do a compile sweep: build every file with the PC compiler and group the errors by type.
   • Fix N64 types declared as long; they must stay 32-bit on a 64-bit PC.
   • Wrap each change to decomp files in #ifdef PORT.
   • On Windows, set up the build as Starship does: cmake -S . -B build/x64 -G "Visual Studio 17 2022" -T v143 -A x64.
   • Describe assets in YAML for Torch, and extract them from your ROM with cmake --build build/x64 --target ExtractAssets.
   • Build the game: cmake --build build/x64.
   Prompt for ClaudeCopy

   GOAL: Make every decomp source file of <GAME> compile and link on PC against `libultraship`.
   READ FIRST: `SCOPE.md`, `notes/port-errors.md`, the libultraship porting guide at https://kenix3.github.io/libultraship/PORTING.html.
   FENCE: Edit only `port/`, `CMakeLists.txt`, `yamls/`, and decomp files inside `#ifdef PORT` blocks. Never remove the original N64 code path. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run `cmake --build build/x64`. Done means zero errors, and `./tools/build-and-verify.sh` in WSL still prints `OK` for the N64 build.
   BUDGET: Stop after one error class per session, or 60 minutes.
   IF BLOCKED: Stop. Do not silence warnings like implicit function declaration. Tell me what blocked you.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste error counts before and after. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe PC build has zero errors, and the N64 build still prints OK.

   Proof this works: BattleShip, Project Midas, Starship

9. Port: golden runs and graphics traces

   Make the PC build boot and play. Compare its display lists to an emulator's, not by eye. Fix byte order and struct layout bugs with proof. Ship with no game data.

   • Add a trace switch that dumps the display list each frame, like BattleShip's SSB64_GBI_TRACE=1.
   • Capture the same frames from an emulator and diff them with a small script.
   • Fix big-endian data at load time, with small per-struct fixes.
   • Add _Static_assert checks on struct sizes.
   • Run boot, menu and first-level golden runs after every fix.
   Prompt for ClaudeCopy

   GOAL: Fix graphics bug <BUG_ID> in the PC port using a display-list trace diff.
   READ FIRST: `notes/bugs/`, the port trace and the emulator trace for frame <N>.
   FENCE: Edit only `port/` and decomp lines inside `#ifdef PORT`. Do not add features, refactors, tools or cleanups I did not ask for.
   CHECK: Run the trace diff for frame <N>. Done means no differing commands, and all golden runs pass.
   BUDGET: Stop after 3 failed fixes, or 60 minutes with no progress.
   IF BLOCKED: Stop. Do not change the trace tool or the reference trace. Tell me the first differing command and your evidence.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the diff summary and golden run results. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe trace diff for the chosen frames is empty, and every golden run passes on PC.

   Proof this works: BattleShip, Project Midas

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

For Path A, one card is one crash, one hang, one missing call or one bad frame. Each card names the golden run that shows the bug. For Path B, one card is one function, checked by the full ROM hash. For the port, one card is one class of compile error or one trace diff. A script picks the next unit, not Claude.

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` and `PROGRESS.md` at the start of every session.
- The one check is `./tools/build-and-verify.sh` (Path B) or `tools/check.ps1` plus the golden runs (Path A). Do not report DONE until it passes; paste its output.
- Never edit `generated/` or `asm/`. These are made by tools. Change the config or `symbol_addrs.txt` and regenerate.
- Never edit the `.sha1` file, the build-and-verify script or the golden-run reference images.
- No inline assembly, `asm("")` barriers or register pins to force a match. A matching hash does not make a cheat acceptable.
- Never commit the ROM or anything made from it. `rom/`, `generated/` and `build/` stay ignored.
- Fix drawing bugs in the renderer patches, never by changing game code.
- Unknown system calls must stop with a named error. Never return fake success with an empty stub.
- In a worktree, always use absolute paths in commands. The working folder resets between commands.
- When you fix a real bug, write `notes/bugs/<topic>_<YYYY-MM-DD>.md` with symptom, cause and fix.
- Do not send pull requests to `N64Recomp`, `RT64` or the Zelda and Banjo recomps. They reject AI-written code. Keep fixes as patch files here.
- Cap builds at `-j 4`. Side ideas go to `notes/parking-lot.md`.

Keep the context small

• Give Claude a function name and a file path, not pasted assembly. Snowboard Kids 2 found Claude ignored pasted listings anyway.
• Start each matching worker in its scratch folder, not the repo root, so it does not spend tokens exploring.
• Keep CLAUDE.md short and point to topic files like notes/compiler-quirks.md, as WinBack and BattleShip did.
• Hand over at most three similar matched functions as examples per card.
• For a graphics bug, give the first differing display-list command from a trace diff, not a description of the picture.
• Clear the chat after every unit. State lives in ledger.csv and PROGRESS.md.

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> (<REGION>, SHA-1 <HASH>) can be recompiled or decompiled, by which technique, and what exists already.
READ FIRST: `notes/prior-work.md`, the RecompLauncher entry if any, GitHub search results for `<GAME> decomp` and `<GAME> recomp`.
FENCE: Edit only `SCOPE.md` (draft) and `notes/prior-work.md`. Do not open or copy the ROM. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `grep -E "^## (Technique|Prior work|Compiler|Risks)" SCOPE.md` and `grep -c http notes/prior-work.md`. Done means all four headings print, the URL count is above zero, `SCOPE.md` names one technique and the compiler or "unknown", and it lists the three biggest risks (compression, overlays, missing decomp).
BUDGET: Stop after 40 minutes.
IF BLOCKED: Stop. Say what you could not find. Do not guess facts.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the URLs. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Produce `ledger.csv` for <GAME> with every function's name, address, size, segment and status.
READ FIRST: `notes/segments.md`, `config/symbol_addrs.txt`, `config/n64sym_addrs.txt`.
FENCE: Edit only `ledger.csv`, `tools/make_ledger.py` and `notes/library.md`. Everything else is read-only. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `python3 tools/make_ledger.py --verify`. Done means no missing functions, sizes add up, and libultra rows are marked `lib`.
BUDGET: Stop after 4 failed tries, or 60 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: counts by status and segment. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Fix <BUG_ID>: <SYMPTOM>, seen in golden run `<RUN>`.
READ FIRST: `PROGRESS.md` entry <BUG_ID>, the run log, `notes/bugs/`.
FENCE: Edit only `config/<game>.us.toml`, `patches/` and `src/game/`. Never edit `generated/`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `powershell -File tools/check.ps1` then `powershell -File tools/run_all.ps1`. Done means `<RUN>` passes and no older run fails.
BUDGET: Stop after 3 failed fixes, or 60 minutes.
IF BLOCKED: Stop. Do not stub the call or skip the scene. Tell me the proven cause and your options.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: run_all summary. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Match <FUNC> in `src/<FILE>.c`.
READ FIRST: `asm/nonmatchings/<FILE>/<FUNC>.s`, `notes/compiler-quirks.md`, similar matched functions <REFS>.
FENCE: Edit only `src/<FILE>.c` and `scratch/<FUNC>_*.c`. Never edit `asm/`, the `.sha1` file or `tools/`. No inline assembly. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `./tools/build-and-verify.sh`. Done means it prints `OK`.
BUDGET: Stop after 10 attempts with no gain. One change per attempt.
IF BLOCKED: Stop. Log <FUNC> and the best score in `notes/hard.md`. Do not start another function.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the check output. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Pick the next <N> units from `ledger.csv` and start one worker per unit, each in its own worktree.
READ FIRST: `ledger.csv`, `notes/hard.md`, `git worktree list`.
FENCE: Edit only the `owner` column in `ledger.csv`. Never give two workers the same file. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `git worktree list` and `git diff ledger.csv`. Done means one worktree per worker, each worker got the unit loop card with its absolute worktree path, and the diff shows exactly <N> owner changes.
BUDGET: Stop after dispatching <N> units.
IF BLOCKED: Stop. Tell me which units could not be assigned and why.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the table of unit, worker, worktree. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Find the cause of <SYMPTOM> in <GAME>. Do not fix it yet.
READ FIRST: the log of `<RUN>`, `notes/bugs/`, the display-list dump or memory watch if one exists.
FENCE: Edit only `notes/debug-<BUG_ID>.md` and temporary log lines in `src/game/debug_*`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `powershell -File tools/capture_test.ps1 <RUN>` once with your test switch on and once with it off. Done means the bug appears and vanishes on purpose, and the note shows the log or trace lines that prove it.
BUDGET: Stop after 60 minutes or 3 wrong theories.
IF BLOCKED: Stop. List the theories you ruled out and the evidence you still need.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the log lines. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Check the work since commit <SHA> and list anything that cheats or breaks the rules.
READ FIRST: `CLAUDE.md`, `git log --stat <SHA>..HEAD`.
FENCE: Read-only. Write only `notes/verify-<DATE>.md`. Do not fix anything. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: In a fresh clone, run the one check command and every golden run. Grep for inline assembly, edits to `.sha1`, `asm/` or `generated/`, empty stubs and disabled runs. Done means each commit is CLEAN or SUSPECT with a reason.
BUDGET: Stop after 45 minutes.
IF BLOCKED: Stop. Tell me what you could not check.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: check output and grep output. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Report project status with numbers only.
READ FIRST: `ledger.csv`, `PROGRESS.md`, `notes/hard.md`, `git log --since="7 days ago" --oneline`.
FENCE: Read-only except `PROGRESS.md`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run the one check command once (`./tools/build-and-verify.sh` or `powershell -File tools/run_all.ps1`) and paste it. Done means it ran, and every number traces to a file or command you name.
BUDGET: Stop after 15 minutes.
IF BLOCKED: Stop. Say which number you could not get.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: matched and total, bugs open and closed, golden runs passing. 3) Files changed. 4) Biggest blocker. 5) New parking-lot items.

GOAL: Write down everything the next session needs to carry on.
READ FIRST: this session's work, `PROGRESS.md`, `git status`.
FENCE: Edit only `PROGRESS.md` and `notes/handoff-<DATE>.md`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `git status --short`. Done means only `PROGRESS.md` and the handoff note changed, and the note lists the current unit, the last check output, what was tried, dead ends, and the next card to run.
BUDGET: Stop after 10 minutes.
IF BLOCKED: Stop. Say what state you could not record.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the note path. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Tell me plainly whether <UNIT> can be finished, and if not, why.
READ FIRST: `notes/hard.md` or `notes/bugs/` for <UNIT>, all attempts in `scratch/`.
FENCE: Read-only. Write only `notes/blocked-<UNIT>.md`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run the unit's check once more (`./tools/build-and-verify.sh` or its golden run) and paste the result. Done means the note says CAN, CANNOT YET or CANNOT, with that output, the evidence and the best result so far.
BUDGET: Stop after 20 minutes.
IF BLOCKED: Stop. Say which evidence is missing.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: best score or last run output. 3) Files changed. 4) Two or three options with cost. 5) New parking-lot items.

GOAL: Ask me before you leave the fence for <UNIT>.
READ FIRST: `SCOPE.md`, the current task card.
FENCE: Do not edit anything. Write only `notes/scope-request-<DATE>.md`. Do not add features, refactors, tools or cleanups I did not ask for.
CHECK: Run `git status --short`. Done means the request note is the only change, and it names each file you want to touch, why, the risk, and a way to undo it.
BUDGET: Stop after 10 minutes.
IF BLOCKED: Stop and wait for my answer.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the request path. 3) Files changed: none. 4) What you will do if I say yes. 5) New parking-lot items.

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 decomp already exists. It gives names for a recomp and source for a port.
• Compression and overlays. Each overlay must be found and listed by hand.
• The compiler. IDO games have a hard tail of register quirks that needs experts.
• Game size. Snowboard Kids had 2,145 functions; big games have several times more.
• Whether you build scripted golden runs early. Without them, every check needs you at the controller.
• Your usage limit. The Snowboard Kids author borrowed usage from three other people. He also wrote that one unattended task could use up a Max 20x plan in days.

The facts behind these numbers

Projects reviewed (15)

We took the top project for each of the top 12 games on RecompLauncher. We added the three whose makers say they used AI. None of the 15 is a matching decomp. So Path B also uses the Snowboard Kids and Ocarina of Time decomps.

What each project teaches

What we could not check

• The time ranges are estimates from a few projects. No project reports hours per week.
• How much private work came before the first public commit of WinBack Recompiled and Project Midas is unknown.
• The N64Recomp README still says an ELF file is required and that hooks are not built yet. Its config source reads symbols_file_path and hooks, and Banjo, Donkey Kong 64 and Marchwind64 use them. We did not run it ourselves.
• We did not test whether ido-static-recomp's Windows build works with N64 decomp Makefiles on plain Windows. The projects we read use Linux or WSL.
• The N64Recomp build commands come from WinBack's tools/fetch_deps.sh. We did not run them.
• splat on plain Windows: its Quickstart assumes Ubuntu, WSL2 or Docker. WinBack runs it on Windows. We did not test it.
• Whether Visual Studio puts Ninja on your path was not confirmed. The Visual Studio download page was opened, but only the Microsoft Learn pages were read for part names.
• The decomp-permuter command line was read from its README and import.py, not run.
• None of the commands, scripts or prompts in this guide were run end to end on a real game here. They come from project files and tool docs.
• The skills.sh skills listed here were not run on an N64 project.
• Whether the Pilotwings 64 team used AI is not stated.
• Whether a Claude Code rule against recreating existing games affects decomp or recomp work is not known.

Sources

• N64Recomp README
• N64Recomp CONTRIBUTING.md (AI policy)
• N64ModernRuntime README
• RT64 README
• splat README
• splat wiki Quickstart
• n64sym README
• ares README and releases
• ido-static-recomp README
• mips-gcc-2.7.2
• asm-processor README
• m2c README
• asm-differ README
• objdiff README
• decomp-permuter README
• libultraship README
• Torch README
• ultralib README
• Ocarina of Time decomp README (WSL advice)
• Snowboard Kids decomp README
• Snowboard Kids 2 decomp README
• Chris Lewis: Decompiling a Nintendo 64 Game in 84 Days
• Chris Lewis: The Long Tail of LLM-Assisted Decompilation
• N64brew wiki: ROM Header
• N64brew wiki: Libultra
• N64brew wiki: Main Page (hardware index)
• Marchwind64 debug interface guide
• WinBack Recompiled development notes
• WinBack Recompiled tools/fetch_deps.sh (N64Recomp build commands)
• N64Recomp config parser (src/config.cpp)
• RT64 CONTRIBUTING.md (AI policy)
• Harbour Masters AI policy
• Starship BUILDING.md (Windows port build)
• libultraship porting guide
• z64decompress README
• Microsoft Learn: CMake projects in Visual Studio
• Microsoft Learn: Clang/LLVM support in Visual Studio CMake projects
• Microsoft Learn: Install WSL
• Chris Lewis: Using Coding Agents to Decompile Nintendo 64 Games
• Claude Code docs: run Claude Code programmatically (claude -p)
• Claude Code docs: hooks
• RecompLauncher
• Python downloads