Claude Code ports 72,758 lines of Amiga 68000 assembly to Godot, but fidelity remains manually judged
- The author says Claude Fable 5 moved a 34,000-line 2010 C++ engine into Godot 4, rebuilt the separate 72,758-line 68000 Amiga version at 50 Hz, and embedded the 1993 original as a second launchable game.
- Running in Claude Code, the model could edit files, invoke the assembler, build and launch the game; it used vasm plus binary diffs to rebuild Amiga binaries and FS-UAE to boot the results.
- The model added scripted test controls including --drive, --probe, and --screenshot, plus headless checks that compile every script and build every level; the author still inspected screenshots manually and no automated test measured game feel.
- The author did not compare the Godot port and the original in UAE with identical inputs, and says a 108-byte reassembly difference remains unexplained; gameplay judgment came from nightly playtesting, with one trampoline-jump adjustment.
Hacker News opinions
I would like Claude Code to export an engineering guide for ports like this, including the tooling it built. I have reversed binaries before, but never with results this good.
After this, I tried giving Claude binary game files and it could reverse engineer them into Godot. A reusable game-porting skill could make the process much smoother.
I am building something similar for DOS SDL ports. My repo is not public yet, but I want a knowledge base, skills, and patches that agents can reuse instead of bootstrapping each port from scratch.
I could not get past the obvious AI-written prose. I am fine with AI coding, but someone passionate about a project should write the story in their own words.
The write-up may have a few AI tropes, but the story is too good to discard over that. It might not have been written at all without AI helping with the prose.
For me, hand-written prose is not load-bearing when the subject is Amiga games and low-level ports. Using Claude for hours every day has probably desensitized me to its style.
I am glad it stumbled in a few places. I expected obscure, improvised hardware techniques from old games to be much harder for agents, and I want to know what agent analysis can teach us about how that code was built.
If Claude did the port and apparently understands it better than the author, I would rather ask Claude questions. Is there a Git repo or session transcript that people can inspect?
I used Claude to understand the port weeks after it was done. That is when I learned about the 108-byte delta, and I still do not fully understand Claude's explanation: it may be the assembler, the environment, or how the binary was saved 33 years ago.
I do not see the point of a Godot port when the original can run in UAE. I would want to see code running there, otherwise calling it Amiga feels misleading.
I agree that criticism is too harsh. The original Amiga version is available free at the bottom of the article, so people can play it in UAE if that is what they want.
I released the full Amiga game as an ADF for the first time in 33 years, and AI helped fix bugs and package it. The post is about using AI to work with 1990s assembly code.
Did you run the Godot port and the UAE original side by side with identical inputs? A 108-byte binary delta is puzzling, and "it feels right" is not the same test.
I did not run them side by side. I played the Mac port, and it felt right after thousands of hours with the original; I only adjusted the trampoline jump. Claude kept the original behavior rather than using Godot physics.
A small binary difference can come from equivalent instructions receiving different encodings or an assembler choosing a shorter form. I would inspect the differing bytes before treating 108 bytes as evidence of a behavioral difference.
I want performance and memory figures. How much less efficient is the 2010 port than the original, and where does the new Godot version land?