Amiga decomp guide

What this system is like

Amiga games run on a Motorola 68000 chip. Most games skip the operating system and drive the custom chips directly. Many were written by hand in assembly, not in C. So there is no shared tool like the ones other systems have.

For Path A, every reviewed recomp wrote its own small recompiler. A recompiler turns the game's machine code into C. Three AI-assisted ports took an easier first step. They ran the original code on a tiny Amiga model built for that one game. Then they swapped in C code piece by piece.

Path B means a byte-exact rebuild of the game first. You disassemble it with IRA and assemble it again with vasm. The hash must match. Then you turn each routine into C, with a test against an emulator for each one. No reviewed project is a byte-matching C decomp. The closest is ReDMCSB, a C rebuild of Dungeon Master. Its site says each build is the same as the original or very close.

Most steps run on Windows. WSL is handy for scripts, IRA and make. Expect weeks for Path A and many months for Path B.

Two paths

Path A: Get it running on PC

First you run the game's own 68000 code on a tiny Amiga model in C or C++. It uses a free CPU core like Musashi or Moira. That gives you a playable build and a reference. Then a recompiler you write turns the code into C, one routine at a time. An interpreter catches any code the recompiler missed. A test compares every translated instruction with the interpreter.

1. Pick the game and pin its files

   You choose one game and one exact release. Amiga games come in many disk forms. You hash each game file, not only the whole disk. You also look for work that already exists.

   • Keep your own disk images in a folder outside the repo, like D:/amiga-games/<GAME>/.
   • In WSL, try xdftool disk1.adf list. If it lists files, the game is an AmigaDOS program. If it fails, the game uses its own track loader.
   • Unpack a DOS disk outside the repo with xdftool disk1.adf unpack <OUT_DIR>, then run sha256sum on each file.
   • Note the chip set (OCS or ECS for A500, AGA for A1200) and the disk format (.adf, .ipf or WHDLoad).
   • Search RecompLauncher, GitHub and the WHDLoad site for prior work. Check for a source release, like the one Gloom had.
   • Write SCOPE.md: game, release, file hashes, chip set, goal, technique, first milestone and its check.
   Prompt for ClaudeCopy

   GOAL: Draft SCOPE.md for a Path A port of <GAME> (<RELEASE>, <CHIPSET>).
   READ FIRST: `xdftool <ABSOLUTE_PATH_TO_ADF> list` output, https://www.whdload.de/, https://github.com/cnvogelg/amitools
   FENCE: Create only `SCOPE.md`, `notes/hashes.sha256` and `notes/prior-work.md`. Do not copy any game file into the repo. Do not write code.
   CHECK: Run `sha256sum -c <ABSOLUTE_PATH_TO_REPO>/notes/hashes.sha256` inside the unpacked game folder. Done means it prints OK for every file, and SCOPE.md lists every game file with its SHA-256, the disk format, DOS or track loader, the chip set, prior work with links, the first milestone and its check, and an out-of-scope list.
   BUDGET: Stop after 45 minutes of searching for prior work.
   IF BLOCKED: Stop. Do not guess a release or a hash. Tell me what is missing.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: paste the xdftool and sha256sum output. 3) Files changed. 4) Prior work found, with links. 5) New parking-lot items.

   Done whensha256sum -c notes/hashes.sha256 prints OK for every game file, SCOPE.md names the disk type, and you approved it.

   Proof this works: Lightmere, BloodCash, ZGloom-x86, https://amitools.readthedocs.io/en/latest/tools/xdftool.html

2. Set up the repo, tools and one check

   You make a repo that holds only your code. Game files and machine-made C stay out of git. You install the build tools and the CPU core. You write one command that builds and runs a headless test.

   • In WSL: sudo apt install build-essential cmake ninja-build git python3-venv libsdl2-dev lhasa.
   • Make a Python venv, then pip install amitools capstone ziglang.
   • Outside the repo, build IRA (see its tool entry) and clone amiga68ktools. Step 3 uses both.
   • Add the CPU core as a pinned submodule: git submodule add https://github.com/kstenerud/Musashi vendor/musashi.
   • On Windows, the sanviler ports use Visual Studio 2022 with vcpkg: cmake --preset windows-vcpkg then cmake --build --preset release.
   • Put *.adf, *.ipf, *.dms, gamedata/, build/ and gen/ in .gitignore before the first commit.
   • Write tools/check.sh. It regenerates, builds and runs the game headless for a set number of frames.
   • Write CLAUDE.md, PROGRESS.md and an empty notes/parking-lot.md.
   Prompt for ClaudeCopy

   GOAL: Make one command, `tools/check.sh`, that builds the <GAME> port and runs it headless for <N> frames.
   READ FIRST: `SCOPE.md`, `vendor/musashi/readme.txt`, `CMakeLists.txt`.
   FENCE: Edit only `tools/check.sh`, `CMakeLists.txt`, `.gitignore`, `CLAUDE.md`, `PROGRESS.md`. Do not edit anything in `vendor/`. Do not add features or tools I did not ask for.
   CHECK: Run `bash tools/check.sh`. Done means it builds with CMake and Ninja and exits 0. Then break one source file on purpose and show the script exits non-zero.
   BUDGET: Stop after 3 failed tries at the same error.
   IF BLOCKED: Stop. Do not work around a missing package. Tell me the exact error and the command.
   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 whenbash tools/check.sh exits 0, and exits non-zero when you break the build.

   Proof this works: James Pond 2: Codename RoboCod - Recompiled, Lightmere, DuckTales Amiga Recompilation

3. Map the game code

   You find out how the game loads and where its code is. You list every routine, the OS calls, the chip register writes and the disk loader. You also mark code that changes itself. This map becomes your ledger.

   • For a DOS game, run hunktool info -d <GAME_EXE>. It dumps the hunk structure: hunks, sizes and overlays. Add -R to see each relocation.
   • Load the program in Ghidra 12.2 with the ghidra_amiga_ldr add-on. The add-on picks Ghidra's built-in 68000 family language, so you need no CPU add-on.
   • Make a text listing too: ira -A -KEEPZH -NEWSTYLE -COMPAT=bi -PREPROC <GAME_EXE>. It writes <GAME_EXE>.asm and a .cnf config.
   • For a track-loader game, boot it in WinUAE with 1 MB chip RAM and no fast RAM. Open the debugger with Shift+F12. Save RAM with S dump.bin 0 $100000.
   • Mark OS calls (JSR -n(A6)), writes to $DFF000 and up, the disk loader, interrupt handlers and copper lists.
   • Flag self-modifying code with amiga68ktools: python3 <AMIGA68KTOOLS>/68kchecker/m68kchecker.py -i <GAME_EXE>.asm > notes/smc.txt. Its hits are guesses, so check each one.
   • Write ledger/functions.csv: address, size, name, kind, status.
   Prompt for ClaudeCopy

   GOAL: Write `ledger/functions.csv` and `notes/map.md` for <GAME>: routines, OS calls, chip writes, disk loader, interrupts and self-modifying code.
   READ FIRST: `SCOPE.md`, `hunktool info -d <ABSOLUTE_PATH_TO_EXE>` output, the IRA listing `<ABSOLUTE_PATH_TO_ASM>` (search it, do not read it whole), http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0000.html
   FENCE: Edit only `ledger/functions.csv`, `notes/map.md` and `tools/make_ledger.py`. Do not edit game files or the IRA listing.
   CHECK: Run `python3 tools/make_ledger.py`. Done means one row per routine, the hunk count matches hunktool, and every entry in map.md cites listing lines (address and instruction).
   BUDGET: Stop after 2 hours, or after 20 minutes with no new entry.
   IF BLOCKED: Stop. If the code is packed or loaded from raw tracks, say so and stop. Do not decode bytes by hand.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: row counts per kind. 3) Files changed. 4) Addresses you could not explain. 5) New parking-lot items.

   Done whenpython3 tools/make_ledger.py exits 0, every row in ledger/functions.csv has a status, and its hunk count matches hunktool info -d.

   Proof this works: DuckTales Amiga Recompilation, James Pond 2: Codename RoboCod - Recompiled, https://tetracorp.github.io/guide/reverse-engineering-amiga.html, https://github.com/jotd666/amiga68ktools

4. Run the original code on a small machine

   This is first light. You run the game's own code on a CPU core with a tiny Amiga model around it. You add only the chip parts the game uses. You replace the disk loader with a file read. No Kickstart ROM is needed.

   • Link Musashi (C) or Moira (C++) as the CPU. Give it chip RAM and the custom chip registers.
   • Load the hunks yourself and apply the relocations. For a track loader, load the RAM dump or the boot code.
   • Hook the loader's address and read straight from the user's files, as BloodCash and Lightmere do.
   • Answer only the OS calls the game makes. DuckTales handled about 70 library calls this way.
   • Add a headless mode: no window, scripted keys by frame number, and a screenshot at frame N. James Pond 2 has --headless N, --input and --shot F:file.png.
   Prompt for ClaudeCopy

   GOAL: Boot <GAME> to its title screen on the interpreter machine, headless.
   READ FIRST: `SCOPE.md`, `notes/map.md` (loader and OS call sections), `vendor/musashi/m68k.h`.
   FENCE: Edit only `runtime/` and `tools/check.sh`. Do not edit game files. No Kickstart ROM. No game bytes in source files.
   CHECK: Run `bash tools/check.sh`, then `build/<GAME> --headless <N> --shot <N>:logs/title.png`. Done means it exits 0 and logs/title.png shows the title screen.
   BUDGET: Stop after 3 failed tries at the same crash, or 2 hours.
   IF BLOCKED: Stop. Tell me the last PC address, the last OS call or chip write, 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: run output and the screenshot path. 3) Files changed. 4) OS calls and chip parts still faked. 5) New parking-lot items.

   Done whenbuild/<GAME> --headless <N> --shot <N>:logs/title.png exits 0 and writes the image. You look at it once, then save its SHA-256 in tests/expected/title.sha256, so later runs check it by script.

   Proof this works: BloodCash, Lightmere, Radiant Fighter: A Shadow Fighter Recomp, https://github.com/kstenerud/Musashi, https://dirkwhoffmann.github.io/Moira

5. Write the recompiler

   Now you turn the code into C. You write a small tool that reads the game file and the ledger. It writes C into gen/ on every build. Code it missed still runs on the interpreter, so the game never stops.

   • Write the tool in Python or C++. DuckTales used tools/analyze.py then tools/recomp.py. James Pond 2 used jp2-recomp.
   • Emit one C function per run of code, with a label per instruction and a dispatcher for jumps through tables.
   • Insert a POLL() call at each backward branch. The runtime then runs frames, interrupts, sound and input.
   • Keep override lists for special routines: replace, gate or add a prologue, like DuckTales does.
   • Mark code that rewrites itself as interpreter-only. James Pond 2 did this for its music player.
   • Regenerate gen/ on every build. Never edit it by hand.
   Prompt for ClaudeCopy

   GOAL: Make the recompiler turn <HUNK_OR_RANGE> of <GAME> into C in `gen/`, with interpreter fallback for anything it skips.
   READ FIRST: `ledger/functions.csv`, `notes/map.md` (self-modifying code section), `tools/recomp.py`.
   FENCE: Edit only `tools/recomp.py`, `runtime/` and `tools/check.sh`. Never edit files in `gen/`. Do not translate code marked self-modifying.
   CHECK: Run `bash tools/check.sh`, then `build/<GAME> --headless <N> --shot <N>:logs/title_recomp.png`. Done means it exits 0, the shot matches logs/title.png from the interpreter build, and the log prints the count of interpreted addresses.
   BUDGET: Stop after 3 failed builds with the same error.
   IF BLOCKED: Stop. Do not patch generated C. Tell me the first error, the instruction and its address.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: build output, both screenshot paths, the interpreted count. 3) Files changed. 4) Instructions not yet handled. 5) New parking-lot items.

   Done whenThe recompiled build's headless shot at frame N has the hash in tests/expected/title.sha256. The log prints how many addresses still run on the interpreter.

   Proof this works: DuckTales Amiga Recompilation, James Pond 2: Codename RoboCod - Recompiled, Dogs of War Atari ST Recomp

6. Test every translated instruction

   A build that runs is not proof. You test each translated instruction against the interpreter. Both start from the same random state. Registers, flags and every written byte must match.

   • Have the recompiler write one test per instruction into gen/tests.cpp, like James Pond 2 does.
   • Run each test from a random register, flag and memory state in both the C and Musashi. Compare registers, the status register, the PC and every byte written.
   • Check your own instruction decoder against capstone on every instruction. DuckTales checked 44,545.
   • Add a lockstep run: play the same input in both builds and compare all RAM each frame. Dogs of War did this over all 12 missions.
   • Break one translation on purpose and show the test fails.
   Prompt for ClaudeCopy

   GOAL: Make `build/<GAME>-difftest` compare every translated instruction with Musashi and report zero mismatches.
   READ FIRST: `tools/recomp.py`, `runtime/cpu.h`, `notes/findings.md`.
   FENCE: Edit only `tools/difftest.cpp`, `tools/recomp.py` (test output only) and `CMakeLists.txt`. Do not change the seed list or skip any instruction.
   CHECK: Run `build/<GAME>-difftest --adf <ABSOLUTE_PATH_TO_GAME>`. Done means it prints zero mismatches. Then break one opcode handler and show it fails with that address.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. List the instructions you cannot set up a fair test for.
   OTHER PROBLEMS: Write mismatches you find in `notes/parking-lot.md`. Do not fix them in this task.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both outputs. 3) Files changed. 4) Instruction count tested. 5) New parking-lot items.

   Done whenThe difftest passes on every translated instruction, and fails when you break one handler.

   Proof this works: James Pond 2: Codename RoboCod - Recompiled, DuckTales Amiga Recompilation, Dogs of War Atari ST Recomp

7. Close code gaps and fix chip bugs

   Now you grind. Some code only runs through jump tables, so the recompiler misses it. Some chip behavior is wrong, so pictures or sound break. You fix one gap or one bug per session, with proof first.

   • Record which addresses ran on the interpreter during play. Sweep every level headless with the game's cheat, like James Pond 2's tools/sweep.py.
   • Feed the coverage file back to the recompiler and rebuild. Watch the interpreted count fall.
   • For a chip bug, record the input, then trace it. DuckTales used HLE_TRACE, write watchpoints and memory dumps.
   • Check the same moment in the WinUAE debugger. Use w 1 <ADDR> 4 W to watch writes.
   • Fix the runtime or the recompiler. Rerun the difftest and the check.
   Prompt for ClaudeCopy

   GOAL: Find and fix the cause of <BUG> seen at frame <N> of `tests/inputs/<ROUTE>.txt`.
   READ FIRST: `notes/map.md`, `notes/findings.md`, the Hardware Reference Manual chapter on <CHIP_PART>, the screenshot `logs/<FILE>.png`.
   FENCE: Edit only `<RUNTIME_OR_RECOMPILER_FILE>` and `notes/findings.md`. Never edit `gen/`. No game-specific hacks in the shared machine code unless I approve them.
   CHECK: Replay the route with a screenshot at frame <N>, then run `build/<GAME>-difftest` and `bash tools/check.sh`. Done means the frame is right and both pass.
   BUDGET: Stop after 2 failed fixes. Write the cause first. No fix before the cause is proven with a trace.
   IF BLOCKED: Stop. Tell me the evidence you have, the ideas you ruled out, 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: before and after screenshots and the trace lines. 3) Files changed. 4) Cause in one sentence, with addresses and registers. 5) New parking-lot items.

   Done whenEach route in tests/inputs/ gives its expected screenshot hash, and build/<GAME>-difftest passes. The interpreted count is zero, or notes/map.md gives a reason for each address left.

   Proof this works: James Pond 2: Codename RoboCod - Recompiled, DuckTales Amiga Recompilation, https://tetracorp.github.io/guide/uae-debugger-intro.html

8. Harden it and ship without the game

   You turn your routes into a regression set. Then you package the program. The package holds no game code or data. It checks the player's own files by hash and says plainly why it rejects one.

   • Save a RAM hash or screenshot at set frames for each route. Write tools/regress.sh to replay them all.
   • Check each user file by SHA-256 at start, like Lightmere. Store only the hashes in the repo.
   • Write a package script that refuses to finish if it finds game bytes. DuckTales' make_dist.sh does this.
   • Test at 125% and 150% Windows display scaling. All three sanviler ports had to fix blur there.
   • Unzip the package on a clean PC and run it with your own disks.
   Prompt for ClaudeCopy

   GOAL: Make `tools/regress.sh` and `tools/package.sh` for <GAME>, so a release is tested and holds no game data.
   READ FIRST: `SCOPE.md`, `PROGRESS.md`, `tests/inputs/`.
   FENCE: Edit only `tools/regress.sh`, `tools/package.sh`, `tests/expected/` for routes I name, and `PROGRESS.md`. Do not put game files, RAM dumps or `gen/` in the package.
   CHECK: Run `bash tools/regress.sh`, then `bash tools/package.sh`. Done means every route passes, the package scan finds zero game bytes, and the unzipped program starts with my files and refuses a wrong one with a clear message.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. Tell me which route is not repeatable, or which file the package needs.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: all three outputs. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenbash tools/regress.sh exits 0 on a fresh clone, bash tools/package.sh reports zero game bytes, and the unzipped program refuses a wrong file with a clear message.

   Proof this works: DuckTales Amiga Recompilation, Lightmere, Dogs of War Atari ST Recomp, BloodCash

Path B: Full decomp for porting

Most Amiga games were hand-written assembly, so there is no C to match. You first rebuild the game file byte for byte from a labeled disassembly. Then you name every routine. Then you turn each routine into C and test it against the 68000 core. Last, you run the whole game in lockstep with the original and port it.

1. Find out how the game was built

   You check for prior work and for signs of the original tools. A source release or an old reconstruction can save years. Signs of a C compiler change the plan. You write the scope.

   • Search for a source release, a remake, a WHDLoad install and EAB forum threads about the game.
   • Look for a full reconstruction like ReDMCSB, Christophe Fontanel's C rebuild of Dungeon Master. Its 2021 release builds the Amiga versions too.
   • Look for compiler signs. DuckTales showed Aztec C: an A5 frame pointer and globals read off A4. Hand assembly has no such pattern.
   • Write SCOPE.md: file hashes, assembler or compiler guess with proof, port target, and the checks.
   Prompt for ClaudeCopy

   GOAL: Find prior work for <GAME> and say how it was built, then draft SCOPE.md for Path B.
   READ FIRST: `notes/map.md` from Path A, the IRA listing `<ABSOLUTE_PATH_TO_ASM>` (search only), https://www.dungeon-master.com/forum/viewtopic.php?t=29805 as an example of a reconstruction.
   FENCE: Create only `SCOPE.md` and `notes/prior-work.md`. Do not download game files or other people's disassemblies of this game into the repo.
   CHECK: Run `sha256sum -c notes/hashes.sha256` in the game folder; it must print OK. Done means SCOPE.md names the build tool guess (assembler or a named C compiler) with at least three listing lines as proof, lists prior work with links and dates, and names the port target.
   BUDGET: Stop after 60 minutes.
   IF BLOCKED: Stop. Say 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: the listing lines. 3) Files changed. 4) Your recommended start. 5) New parking-lot items.

   Done whenSCOPE.md names the build tool guess with proof, names the port target, and you approved it.

   Proof this works: DuckTales Amiga Recompilation, ZGloom-x86, https://www.dungeon-master.com/forum/viewtopic.php?t=29805, http://dmweb.free.fr/community/redmcsb/

2. Rebuild the game file byte for byte

   You turn the game file into assembly that rebuilds it exactly. IRA writes the source. vasm assembles it back into a hunk file. The hash must match. This is the check for the rest of Path B.

   • In WSL, get ira.lha from Aminet and unpack it with lhasa -x ira.lha (sudo apt install lhasa). Then run make in the ira/ folder.
   • In WSL, clone the vasm source mirror and run make CPU=m68k SYNTAX=mot. That builds vasmm68k_mot.
   • Run ira -A -KEEPZH -NEWSTYLE -COMPAT=bi -PREPROC <GAME_EXE>, fix code and data ranges in the .cnf, then run it again with -CONFIG.
   • Assemble: vasmm68k_mot -no-opt -Fhunkexe -nosym -o build/<GAME_EXE> <GAME_EXE>.asm.
   • Write make compare: it builds, then checks sha256sum against the hash in SCOPE.md.
   • For a track-loader game, rebuild the loaded code block as a raw binary instead, and compare that.
   Prompt for ClaudeCopy

   GOAL: Make `make compare` rebuild <GAME_EXE> from IRA source with vasm and match the SHA-256 in SCOPE.md.
   READ FIRST: `SCOPE.md`, the IRA readme and `ira_config.doc`, https://github.com/StarWolf3000/vasm-mirror
   FENCE: Edit only `Makefile`, `<GAME_EXE>.cnf` and `tools/`. Do not edit the expected hash file. The game file stays at `<ABSOLUTE_PATH_TO_EXE>`.
   CHECK: Run `make compare`. Done means it prints OK with the SCOPE.md hash. Then change one byte in the .asm and show `make compare` fails.
   BUDGET: Stop after 3 failed tries at the same mismatch.
   IF BLOCKED: Stop. Paste the first differing offset from `cmp -l` and the listing lines around 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 whenmake compare prints OK, and fails when one byte is changed.

   Proof this works: https://aminet.net/package/dev/asm/ira, https://tetracorp.github.io/guide/reverse-engineering-amiga.html, https://github.com/StarWolf3000/vasm-mirror

3. Split code from data and list every routine

   A raw disassembly guesses where code starts. Wrong guesses turn tables into fake code. You feed it real proof of what ran. Then you build the routine ledger.

   • Use the coverage files from Path A. They list every address that ran.
   • Mark code and data ranges in the .cnf with that proof. Rerun IRA with -CONFIG.
   • Run make compare after each change.
   • Write ledger/routines.csv: hunk, offset, size, name, status (raw, named, in C).
   Prompt for ClaudeCopy

   GOAL: Build `ledger/routines.csv` for <GAME> and a `.cnf` that marks every code and data range.
   READ FIRST: `SCOPE.md`, `coverage/<FILE>` from Path A, `<GAME_EXE>.cnf`.
   FENCE: Edit only `<GAME_EXE>.cnf`, `ledger/routines.csv` and `tools/make_ledger.py`. Do not hand-edit the generated .asm in this task.
   CHECK: Run `make compare`. Done means OK, and every address in the coverage file sits inside a routine in the ledger.
   BUDGET: Stop after 2 hours or 3 failed compares.
   IF BLOCKED: Stop. List the ranges you cannot class as code or data.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: compare output and row counts. 3) Files changed. 4) Unknown ranges. 5) New parking-lot items.

   Done whenmake compare prints OK, and every covered address belongs to a routine in the ledger.

   Proof this works: James Pond 2: Codename RoboCod - Recompiled, https://aminet.net/package/dev/asm/ira

4. Name one routine end to end

   You take one small routine all the way. You name it, its labels and the RAM it uses. You swap raw numbers for chip register names. The file must still match.

   • Pick a short routine, like the joystick reader.
   • Run python3 <AMIGA68KTOOLS>/tools/cheapres.py -i <GAME_EXE>.asm -o notes/named.asm. It names OS calls and custom chip registers. Copy the names you trust into the .cnf.
   • Add names with SYMBOL, LABEL and COMMENT lines in the .cnf, so names survive a rerun of IRA.
   • Watch the routine's RAM in the WinUAE debugger to confirm what each variable means.
   • Run make compare. Set the ledger status to named.
   Prompt for ClaudeCopy

   GOAL: Fully name and comment routine <HUNK:OFFSET> in the <GAME> disassembly.
   READ FIRST: the ledger row for <HUNK:OFFSET>, the routine's lines in `<GAME_EXE>.asm`, `notes/ram-map.md`.
   FENCE: Edit only the `.cnf` entries for this routine, `notes/ram-map.md` and its ledger row. Do not change any byte the build emits.
   CHECK: Run `make compare`. Done means OK, no raw chip address is left in the routine, and the ledger row says `named`.
   BUDGET: Stop after 3 failed compares or 30 minutes.
   IF BLOCKED: Stop. Say which value you cannot explain and what you checked.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: compare output and the diff. 3) Files changed. 4) Names you are unsure of. 5) New parking-lot items.

   Done whenmake compare prints OK and the routine has names in place of raw addresses.

   Proof this works: https://github.com/jotd666/amiga68ktools, https://tetracorp.github.io/guide/uae-debugger-intro.html

5. Name every routine in parallel

   Now you repeat the unit loop many times. Each worker takes routines from one slice of the ledger. Easy leaf routines go first. Every change must keep make compare at OK.

   • Sort the ledger: leaf routines first, then routines whose callees are all named.
   • Give each worker one hunk or address range and its own git worktree.
   • All names live in the .cnf, so assign .cnf sections to one worker each.
   • Run make compare after every routine and again after each merge.
   • Record dead ends in notes/findings.md.
   Prompt for ClaudeCopy

   GOAL: Name the next <N> `raw` routines in range <START>-<END>, one at a time.
   READ FIRST: `ledger/routines.csv` (rows in that range only), `notes/ram-map.md`, `notes/findings.md`.
   FENCE: Edit only the `.cnf` section for <START>-<END>, `notes/ram-map.md` and ledger rows in that range. Work in worktree `<ABSOLUTE_WORKTREE_PATH>`. Do not touch other ranges.
   CHECK: Run `make compare` after each routine. Done means OK each time and each finished row says `named`.
   BUDGET: Skip a routine after 3 failed tries and mark it `hard`.
   IF BLOCKED: Stop. Tell me which routine and why.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the last compare output. 3) Files changed. 4) Routines named, routines marked hard. 5) New parking-lot items.

   Done whenEvery ledger row says named or hard, and make compare prints OK on the merged branch.

   Proof this works: https://github.com/jotd666/amiga68ktools, https://aminet.net/package/dev/asm/ira

6. Pull out the graphics and tables

   A port needs the art and data as real files. You turn bitplane graphics into PNG images. The build turns them back into the same bytes. The hash must not change.

   • Find each graphics block in the ledger and the .cnf.
   • Write it out as PNG with bitplanelib.py from amiga68ktools. It reads and writes bitplanes with the palette order.
   • Add a make rule that turns the PNG back into bitplanes and includes it with incbin.
   • Do the same for level and text tables as labeled data.
   • Run make clean && make compare after each block. Keep extracted files out of git.
   Prompt for ClaudeCopy

   GOAL: Move graphics block <LABEL> out of the .asm into `assets/<NAME>.png`, rebuilt to the same bytes.
   READ FIRST: `<GAME_EXE>.cnf`, `Makefile`, `amiga68ktools/lib/bitplanelib.py`.
   FENCE: Edit only `Makefile`, `tools/` and the lines for <LABEL>. Do not commit the PNG or any other file made from game data.
   CHECK: Run `make clean && make compare`. Done means OK.
   BUDGET: Stop after 3 failed compares.
   IF BLOCKED: Stop. Tell me the plane count, size or palette layout you could not match.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: compare output. 3) Files changed. 4) Blocks left. 5) New parking-lot items.

   Done whenmake clean && make compare prints OK with graphics built from PNG files.

   Proof this works: https://github.com/jotd666/amiga68ktools, Lightmere

7. Turn each routine into C with a test

   Now you write C, one routine per ticket. Each C function keeps the original instruction as a comment. A test runs the C and the 68000 core from the same state. Both must leave the same registers and memory.

   • Follow Dogs of War: one C function per routine, the address and original instruction in a comment, named registers and RAM.
   • Keep return addresses on the emulated stack, so RAM stays the same as on a real Amiga.
   • Take start states from saved game snapshots, plus random states, like the James Pond 2 difftest.
   • Run the C and Musashi from each state. Compare registers, flags and every byte written.
   • Set the ledger status to in C only when the test passes and fails when you revert a line.
   Prompt for ClaudeCopy

   GOAL: Turn routine <HUNK:OFFSET> (<NAME>) into C with a differential test.
   READ FIRST: the routine's named lines in `<GAME_EXE>.asm`, its ledger row, `notes/ram-map.md`, at most 3 already-done C routines it calls.
   FENCE: Edit only `src/<FILE>.c`, `tests/diff/<NAME>.cpp` and the ledger row. Do not edit the .asm, the snapshots or the test harness.
   CHECK: Run `build/difftest --routine <NAME> --states tests/states/`. Done means zero mismatches on every state, and a mismatch when you revert one line of the C.
   BUDGET: After 3 failed tries, stop and mark the row `hard`.
   IF BLOCKED: Stop. Tell me which instruction or flag you could not settle.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: test output, and output with the line reverted. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenEvery routine is in C or hard, and each C routine passes its test and fails when a line is reverted.

   Proof this works: Dogs of War Atari ST Recomp, James Pond 2: Codename RoboCod - Recompiled, https://github.com/kstenerud/Musashi

8. Run the whole game in lockstep

   Routine tests do not prove the whole game. You run the C game and the reference machine side by side. Same input, same start. All RAM, the palette and the sound registers must match every frame.

   • Use the Path A interpreter machine as the reference. It runs the original, unchanged code.
   • Feed both the same scripted input and compare after every frame. Dogs of War compared 4 MB of RAM, sound registers and palette.
   • Cover every level with recorded routes or an auto-pilot.
   • On a mismatch, print the frame, the address and the last routine run.
   Prompt for ClaudeCopy

   GOAL: Make `tools/lockstep.sh` run route <ROUTE> in the C build and the reference machine and compare RAM, palette and sound registers every frame.
   READ FIRST: `PROGRESS.md`, `tests/inputs/<ROUTE>.txt`, `runtime/machine.h`.
   FENCE: Edit only `tools/lockstep.sh`, `tools/compare_state.py` and `tests/lockstep/`. Do not change game code in this task.
   CHECK: Run `bash tools/lockstep.sh <ROUTE>`. Done means it exits 0 only when every frame matches, and prints the first differing frame and address when not.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. Tell me which frame cannot be lined up and why.
   OTHER PROBLEMS: Write differences you find in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the run output. 3) Files changed. 4) Differences found. 5) New parking-lot items.

   Done whenbash tools/lockstep.sh <ROUTE> exits 0 for every route in tests/inputs/.

   Proof this works: Dogs of War Atari ST Recomp, Lightmere

9. Port it to a new system

   Now you move the chip parts behind a clean layer. The game code then calls your layer, not raw registers. You fix byte order and pointer size. You build for the new system and replay the same routes.

   • Turn copper, blitter and bitplane output into a frame buffer. Turn Paula writes into SDL audio.
   • The 68000 is big-endian and a PC is little-endian. Swap bytes when reading game data.
   • Replace 32-bit Amiga addresses stored in tables with indexes or real pointers for 64-bit systems.
   • Fix original out-of-bounds reads. They were harmless on the Amiga and crash on a modern OS.
   • Build for the new target and replay every route. James Pond 2 reached Android and PlayStation 5 from one code base.
   Prompt for ClaudeCopy

   GOAL: Move <CHIP_PART> access in <SOURCE_FILES> behind `platform/<PART>.h`, with no change in behavior.
   READ FIRST: `PROGRESS.md`, `platform/`, the files named above.
   FENCE: Edit only the files named above and `platform/`. Do not change game logic or data layout.
   CHECK: Run `bash tools/lockstep.sh <ROUTE>` and `bash tools/regress.sh`. Done means both pass on the PC build, and the <TARGET> build boots to the title screen.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. Tell me which register access cannot move without a logic change.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both outputs and a target screenshot. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenbash tools/lockstep.sh <ROUTE> and bash tools/regress.sh pass on the PC build, and the new system's title shot matches its expected hash.

   Proof this works: James Pond 2: Codename RoboCod - Recompiled, Open Fodder, https://codeberg.org/CyCl0ne/DungeonMasterZIG

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 Amiga work by address range and by chip part. On Path A, one unit is one interpreted address, one crash, or one chip bug, with a recorded input that shows it. On Path B, one unit is one routine from the ledger. Every unit has one check: a difftest with zero mismatches, a headless screenshot, a lockstep run or make compare. Keep game files outside the repo and give Claude their 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` and `PROGRESS.md` at the start of every session.
- Never edit files in `gen/`. They are rebuilt from the game file. Fix `tools/recomp.py` or `runtime/`, then regenerate.
- Game files live at `<ABSOLUTE_PATH_TO_GAME_FILES>`. Never copy them, RAM dumps, exported texts or graphics into the repo.
- The one check is `bash tools/check.sh` (Path A) or `make compare` (Path B). No pasted output means not done.
- Never launch the game window to judge a picture. Use the headless runner and its screenshots. I do the visual checks.
- Give the address and the listing lines from IRA or Ghidra for every claim about code.
- Do not edit expected hashes, difftest seeds, files in `tests/expected/` or the check scripts. Ask me first.
- Keep file-format readers free of SDL so their tests run with no window.
- Game-specific hooks go in `src/<game>/`. Keep the shared machine code free of them.
- Cheats and skip switches stay behind flags, and they turn off high-score saving.
- Do not install or fetch libraries. Dependencies are vendored.
- In a worktree, use absolute paths for game files and tools. Gitignored files are not copied in.
- Write side issues in `notes/parking-lot.md` and dead ends in `notes/findings.md`. Do not act on them.
- Start every report with DONE, PARTIAL or BLOCKED.

Keep the context small

• Never let Claude read gen/ or a full IRA listing. DuckTales' machine-made C was about 196,000 lines. Have it grep for an address and read a few lines.
• Give Claude one route's trace lines, not the whole log. Turn on one trace channel at a time.
• Pass a Ghidra address, not pasted assembly. Let the MCP server or a subagent fetch it.
• On Path B, give each worker its address range and those ledger rows only.
• Add Read deny rules for gen/**, logs/** and the game file folder.
• Clear the chat after each unit. The ledger and the findings file 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> (<RELEASE>) suits Path A, Path B, or both, and draft SCOPE.md.
READ FIRST: `xdftool <ABSOLUTE_PATH_TO_ADF> list` output, `hunktool info -d <ABSOLUTE_PATH_TO_EXE>` output if it is a DOS program, https://github.com/cnvogelg/amitools
FENCE: Create only `SCOPE.md`, `notes/hashes.sha256` and `notes/prior-work.md`. No code. Do not copy game files.
CHECK: Run `sha256sum -c <ABSOLUTE_PATH_TO_REPO>/notes/hashes.sha256` in the unpacked game folder; it must print OK for every file. Done means SCOPE.md lists per-file SHA-256, DOS program or track loader, chip set, hunk and overlay count, C or assembly guess with proof, prior work with links, the chosen path, the first milestone with its check, and an out-of-scope list.
BUDGET: 60 minutes.
IF BLOCKED: Stop. Say what you could not check.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: tool outputs. 3) Files changed. 4) Risks you see. 5) New parking-lot items.

GOAL: Build `ledger/functions.csv` from the IRA config and the hunk info for <GAME_EXE>.
READ FIRST: `<GAME_EXE>.cnf`, `hunktool info -d <ABSOLUTE_PATH_TO_EXE>` output, `notes/map.md`.
FENCE: Edit only `ledger/functions.csv` and `tools/make_ledger.py`. Do not read the .asm whole; use a script.
CHECK: Run `python3 tools/make_ledger.py`. Done means one row per routine with hunk, offset, size, kind and status, and per-hunk byte totals match hunktool.
BUDGET: 3 failed tries.
IF BLOCKED: Stop. Tell me which fields are missing.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both totals. 3) Files changed. 4) Odd entries. 5) New parking-lot items.

GOAL: Make the recompiler translate the code at <ADDRESS> so it no longer runs on the interpreter.
READ FIRST: `notes/map.md`, the coverage lines for <ADDRESS>, the IRA or Ghidra listing at <ADDRESS>.
FENCE: Edit only the entry list in `tools/recomp.py` config and `notes/map.md`. Never edit `gen/`. Do not add an address you have not proven is code.
CHECK: Regenerate, rebuild, replay `tests/inputs/<ROUTE>.txt`, then run `build/<GAME>-difftest`. Done means <ADDRESS> is gone from the interpreted list and the difftest shows zero mismatches.
BUDGET: 3 tries or 30 minutes.
IF BLOCKED: Stop. If it is self-modifying code or data, say so with the listing.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: before and after counts and difftest output. 3) Files changed. 4) Addresses left. 5) New parking-lot items.

GOAL: Turn routine <HUNK:OFFSET> into C with a differential test.
READ FIRST: the ledger row, the routine's lines in `<GAME_EXE>.asm`, `notes/ram-map.md`.
FENCE: Edit only `src/<FILE>.c`, `tests/diff/<NAME>.cpp` and the ledger row.
CHECK: Run `build/difftest --routine <NAME> --states tests/states/`. Done means zero mismatches, a mismatch when one C line is reverted, and the row says `in C`.
BUDGET: 3 failed tries, then mark it `hard`.
IF BLOCKED: Stop. Say which instruction you could not settle.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: both test outputs. 3) Files changed. 4) Unsure names or flags. 5) New parking-lot items.

GOAL: Start <N> workers, one per unit, from the top of the ledger.
READ FIRST: `ledger/functions.csv` (status column only), `PROGRESS.md`.
FENCE: Do not edit code yourself. Give each worker its own worktree, one address range, and the unit-loop card with its unit filled in.
CHECK: Done means every worker returned DONE, PARTIAL or BLOCKED, and `bash tools/check.sh` (or `make compare`) passes on the merged branch.
BUDGET: Stop the batch if two workers fail on the same cause.
IF BLOCKED: Stop. Tell me the shared cause.
OTHER PROBLEMS: Collect workers' parking-lot items in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the merged check output. 3) Units done, partial, blocked. 4) What is next. 5) New parking-lot items.

GOAL: Find the cause of <SYMPTOM> at frame <N> of `tests/inputs/<ROUTE>.txt`. Do not fix it yet.
READ FIRST: `notes/findings.md`, the Hardware Reference Manual chapter on <CHIP_PART>, `runtime/<FILE>`.
FENCE: Edit only `notes/findings.md`. You may turn on trace switches and run the WinUAE debugger. No code changes.
CHECK: Replay `tests/inputs/<ROUTE>.txt` headless with one trace switch on, up to frame <N>. Done means findings.md names the cause with proof: trace lines, register values or a watchpoint hit, plus the same moment in WinUAE.
BUDGET: 90 minutes.
IF BLOCKED: Stop. List the ideas you ruled out and what evidence you still need.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the trace lines. 3) Files changed. 4) The cause in one sentence. 5) New parking-lot items.

GOAL: Check that the last <N> units claimed DONE are real.
READ FIRST: `git log` for the batch, `PROGRESS.md`, the ledger rows for those units.
FENCE: Read only. Do not fix anything.
CHECK: Rerun `bash tools/check.sh`, `build/<GAME>-difftest` and `bash tools/regress.sh`. Then search the diff for edits in `gen/`, `tests/expected/`, seed lists or check scripts, new skip lists, stubbed routines, and cheat flags left on.
BUDGET: 60 minutes.
IF BLOCKED: Stop. Tell me which check you could not run.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: all check outputs. 3) Units that pass. 4) Units that fail, with the line that shows it. 5) New parking-lot items.

GOAL: Give me a status report for <GAME> from the files, not from memory.
READ FIRST: `PROGRESS.md`, `ledger/functions.csv`, `notes/findings.md`, `notes/parking-lot.md`.
FENCE: Read only.
CHECK: Done means every number comes from a file or a command you ran: routines by status, interpreted address count, difftest result, routes passing.
BUDGET: 15 minutes.
IF BLOCKED: Stop. Say which number you could not get.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the commands and their output. 3) Numbers table. 4) Top 3 risks. 5) Parking-lot items that need my decision.

GOAL: Write what the next session needs into the ledger files.
READ FIRST: `PROGRESS.md`, `git status`, `git log -5`.
FENCE: Edit only `PROGRESS.md` and `notes/findings.md`. Do not commit half-done code without saying so.
CHECK: Run `bash tools/check.sh` (or `make compare`) and `git status --short`, and paste both into PROGRESS.md. Done means PROGRESS.md has: what works with proof, the unit in progress and its state, the exact next command to run, dead ends, and open questions.
BUDGET: 15 minutes.
IF BLOCKED: Stop. Tell me what you could not record.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the new PROGRESS.md section. 3) Files changed. 4) What is left. 5) New parking-lot items.

GOAL: Tell me plainly whether <TASK> can be done, and what it would take.
READ FIRST: `notes/findings.md` entries for <TASK>, the last three reports on it.
FENCE: Read only.
CHECK: Rerun the failing check for <TASK> once, like `bash tools/check.sh` or `make compare`, and paste its output. Done means you answer YES, NO or NOT YET, with that output as evidence and at least two options with their cost.
BUDGET: 30 minutes.
IF BLOCKED: Stop. Say what you would need to know to answer.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the evidence. 3) The answer. 4) Options with cost. 5) What you recommend.

GOAL: Ask me before you leave the fence for <TASK>.
READ FIRST: `SCOPE.md`, the current task card.
FENCE: Make no change outside the current fence until I say yes.
CHECK: Run `git status --short` and show that no file outside the current fence changed. Done means that, plus one request with: what you want to change, why the current fence blocks the task, the files it touches, the risk, and how we would check it.
BUDGET: 10 minutes.
IF BLOCKED: Stop and wait for my answer.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: the request text. 3) Files you want to touch. 4) The risk. 5) The check you propose.

GOAL: Add <CHIP_FEATURE> to `runtime/<FILE>` so <GAME> draws <SCENE> right.
READ FIRST: the Hardware Reference Manual section on <CHIP_FEATURE>, `notes/findings.md`, `runtime/<FILE>`.
FENCE: Edit only `runtime/<FILE>`, `tests/chip/` and `notes/findings.md`. No game-specific code in the shared machine.
CHECK: Write a small chip test in `tests/chip/` with known pixels, like Radiant Fighter's `agatest`. Done means it passes, the scene screenshot matches `tests/expected/<SCENE>.png`, and `bash tools/regress.sh` passes.
BUDGET: Stop after 3 failed tries.
IF BLOCKED: Stop. Quote the manual text you cannot square with the game's behavior.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof: test and regress output. 3) Files changed. 4) What is left. 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 you reuse a machine core. The sanviler ports shared one core and went public within four days. Their earlier private work is not dated.
• DOS program or track loader. A hunk program loads in one step. A track loader with copy protection needs RAM dumps and hooks.
• OCS or AGA. AGA games need more chip work, like the wide fetch bug in Radiant Fighter.
• Self-modifying code and jump tables. Each one adds coverage rounds and interpreter fallback.
• Assembly or C. On Path B, assembly means naming every routine by hand before any C exists.
• Your review time. Each unit needs a look at its proof, and that is your 10 to 15 hours a week.

The facts behind these numbers

Projects reviewed (10)

The top-starred project for each Amiga game on RecompLauncher. The catalog lists 11 projects for 10 games. All were reviewed except ZGloom-macOS, a sibling fork of ZGloom-x86 by the same author. None of the ten came from outside RecompLauncher. Three outside projects are used only as time and Path B evidence.

What each project teaches

What we could not check

• No reviewed project is a byte-matching C decomp of an Amiga game. ReDMCSB's site says its builds are identical to the originals or very close, but which Amiga builds match exactly was not checked. Its archive was not downloaded.
• Whether vamos from amitools can run SAS/C or Aztec C well enough for a matching C project was not tested.
• Whether asm-differ, which supports m68k, works on Amiga hunk objects was not tested.
• GhidraMCP 2.0 is built for Ghidra 12.1.4. The Amiga loader has builds for 12.0.x and 12.2 only. Building either one from source for the other's Ghidra was not tried.
• The exact Greaseweazle --format name for Amiga DOS disks was not on the pages read. Run gw read --help for it.
• The vasm home site was under maintenance on 2026-11-13. Its build line comes from the source mirror's README. The old prebuilt Windows zips are gone: the prebuilt-amiga-dev-tools repo has no releases. Building vasm or IRA natively on Windows with their Visual Studio makefiles was not tried.
• The tools that analyzed Blood Money, Darkmere and Shadow Fighter are not named in those repos.
• How Claude was directed in the Amiga ports is unknown. None of them publish agent files except RodLegacy's AGENTS.md.
• The James Pond 2 and Dogs of War AI flags partly come from the store catalog, not from the repos.
• A research note reports a Claude Code rule against recreating a specific existing game (Game Developer, 2026-10-30). Whether it affects remakes like four of these projects was not tested.
• The scripts tools/check.sh, tools/regress.sh, tools/lockstep.sh, make compare and the difftest commands in the steps are ones you write. Their names are suggestions.
• Whether WinUAE needs your own Kickstart ROM for a given game was not checked. The download page does not say. Do not download one from an unofficial site.
• No command, build or prompt in this guide was run. Every tool fact comes from its docs or a reviewed project.

Sources

• Ghidra 12.2 release
• ghidra_amiga_ldr (nicodex fork) releases
• ghidra_amiga_ldr (original)
• ghidra-amiga (loads WinUAE state files)
• GhidraMCP README
• IRA on Aminet
• vasm source mirror
• IRA readme on Aminet
• lhasa (free LHA unpacker) on Ubuntu
• Ghidra Getting Started (12.2)
• amitools README and docs
• ADFlib README
• Musashi README
• Moira project page
• Capstone on PyPI
• ziglang on PyPI
• WinUAE download page
• FS-UAE console debugger option
• Greaseweazle README
• Greaseweazle supported image types
• WHDLoad home page
• amiga68ktools README
• Tetracorp: reverse engineering Amiga games
• Tetracorp: introduction to the UAE debugger
• Amiga Hardware Reference Manual (ADCD 2.1)
• Amiga Hunk format
• Amiga programming languages
• Codetapper: system control in an Amiga game
• ReDMCSB announcement thread
• ReDMCSB page (releases and build notes)
• Amiga 500 (clock speed)
• Amiga 1200 (CPU and clock speed)
• DungeonMasterZIG
• wikinger2 README
• Dogs of War CHANGELOG
• DuckTales recomp NOTES.md
• James Pond 2 BUILDING.md