In 1993, a developer in Baghdad built a platform game on an Amiga 500 in pure MC68000 assembly. The machine had 512KB of RAM and no hard drive. Thirty-three years later, he fed the entire 72,758-line assembly codebase to Claude and had a working port of the game inside Godot in a single evening.
The writeup on the Babylonian Twins blog is one of the better-documented accounts of LLM-assisted legacy migration yet published, and the details matter more than the headline. This was not vibe coding. It was a careful, verified process that treated the LLM as a very fast junior engineer with perfect recall of documentation and no memory of the codebase itself.
Step one: rebuild the toolchain, verify byte-identical output
Before touching Godot, the author had Claude assemble the original source with vasm on an Apple Silicon Mac. The goal was not a port yet, just proof that the 1993 code could still compile. Claude produced byte-identical binaries in about 15 minutes, with one wrinkle: a 108-byte discrepancy turned out to be an artifact of the original ASM-One workflow, where the game was assembled into memory and the shipped files were a snapshot saved after the game had already run. That kind of forensic detail is exactly where naive LLM use fails and a careful workflow succeeds.
The actual port: one evening, 21:58 to 23:43
With the toolchain verified, the “greedy ask” was to embed the original Amiga game inside the modern Godot build as a second launch option. The elapsed time from start to working build was under two hours.
The result preserved the details that matter to anyone who knew the original: the Amiga version keeps its authentic 50Hz tick rate, while the 2010 C++ port runs at 60Hz. Switching between them required a guest scene that changes the engine clock on entry and restores it on exit. Claude also caught and fixed several subtle porting bugs along the way, including incorrect org handling, missing copper sky gradients, and guard collision bounds.
Verification carried the project, not the model
The author’s quality gates are the transferable part of the story:
- Script compilation checks on every build
- Automated level builds
- Pixel-level diffs of rendered level screenshots against 2020 reference captures
The screenshots diff is the clever one. A porting bug in a 1993 game rarely announces itself in a stack trace, but it shows up immediately when a rendered frame differs from a known-good capture. Anyone migrating legacy software with LLM assistance should steal this pattern: capture golden outputs from the old system, then diff mechanically.
It is also worth noting what the human contributed. The author fed Claude 33 years of memory of how the game was built, personal notes, and git history. The model did the assembly archaeology and the boilerplate; the human supplied the context that never made it into the source code. The resulting blog post itself was drafted by Claude and then edited line by line over a week, which the author describes openly.
Why this matters beyond retro gaming
Legacy migration is one of the highest-cost, lowest-glamour jobs in software. Banks still run COBOL, factories still run DOS-era controllers, and the engineers who understand those systems are retiring. The pattern demonstrated here, rebuild the toolchain first, verify byte-identical output, port with the model, then diff golden outputs, generalizes well past Amiga games.
The economics tell the story too. The 2010 iPhone port of this same game took a custom C++ engine of roughly 34,000 lines and a professional effort measured in months. That port earned the game a second life, with more than two million downloads on iOS. The Godot port was an evening of supervised generation, followed by weekends of polish. The model did not replace the author’s judgment; it replaced the tedium.
It is worth being honest about where the LLM approach still falls short. The author did not simply accept Claude’s output. The polishing phase, getting the game feel right, took several more weekends of weekends-and-evenings work, and the article itself went through a week of line-by-line human editing after Claude produced the first draft. Assembly written for a machine with 512KB of RAM carries assumptions, timing dependencies and hardware tricks that a modern engine does not reproduce automatically. What the model accelerated was the mechanical translation layer; the judgment layer stayed human throughout. That division of labor is the realistic template, not the one-evening headline.
For teams sitting on legacy codebases with a shrinking pool of maintainers, the demonstrated workflow suggests a concrete first project: pick one module, rebuild its toolchain, verify output parity, and let the model draft the port while humans review diffs. The Amiga exercise shows the pattern works even when the source language is 40-year-old assembly and the only living expert is the original author.
Try it on your own legacy code
The workflow translates directly:
- Rebuild the original first. Get the legacy code compiling with a modern toolchain before changing anything. Byte-identical or behavior-identical output is your baseline.
- Give the model your context. Design notes, commit history, tribal knowledge. The LLM cannot know why that magic constant is 7 unless you tell it.
- Automate golden-output diffs. Screenshots, output files, API responses. Anything the old system produced, capture and compare.
- Expect an evening, budget a month. The first working build was fast. Getting the feel right and shipping took the author several more weekends, which is still a spectacular ratio.
The full post, including the assembly listings and Claude’s actual session logs, is on the Babylonian Twins blog and worth reading in full.