Claude Ported a 1993 Amiga Game
Babylonian Twins is a 1993 Baghdad-built MC68000 assembly game whose developer wrote a project note about moving it into Godot, with an LLM reading the assembly. Can an LLM read old assembly well enough to recover game behavior, not just translate syntax? The author tested this with Claude Fable 5, a model release, rather than the Claude Code CLI agent specifically, and says the first port took an evening, while getting the feel right and shipping took more weekends and evenings. For Claude Code the practical takeaway is simple: a legacy-port evidence trail is the notes, commands, diffs, screenshots, and tests that let someone check why a port behaves the way it does.
Let the model read before it rewrites
The interesting part of the Babylonian Twins port is not that an LLM produced Godot code quickly. It is that the model had to infer intent from MC68000 assembly, old project memory, notes, and repositories.
That is a different job from normal code completion. In a Claude Code workflow, the first useful move is often to ask for an inventory: routines, data tables, sprite assumptions, collision state, input handling, and anything that looks like a game loop.
Watch for starting with convert this file to GDScript. Old game code often hides meaning in layout, timing, and hardware constraints. If the agent translates too early, it can preserve the shape of the code while losing the behavior that made the game feel right.
A better first prompt is boring and powerful: read these files, name the behaviors, and show the evidence for each guess. That gives the human something to review before the rewrite begins.
Treat feel as separate from translation
The source note has a lovely split: the first port was fast, but the real work was getting the feel right and shipping it. Anyone who has touched old games will recognize that sentence immediately.
A platformer is not just draw calls and collision checks. It is jump gravity, input buffering, animation timing, camera follow, enemy wake-up distance, and tiny mistakes that became part of the original game.
So the practical move is to split the work into two lanes. Let Claude propose a mechanical port, then review feel as its own artifact: short clips, screenshots, input traces, or side-by-side notes from the original.
Don't treat a running Godot scene as proof. Running is good. Familiar is harder. A port can compile, load assets, and still be wrong in the first three seconds of movement.
Use memory as data, not vibes
The author did something many successful agent sessions quietly depend on: he fed the model decades of human memory. Not just code. Not just a repo. Memory of how the game was built, what mattered, and what the old tools were doing.
That matters because legacy systems are full of missing context. A variable name may be absent. A routine may exist only because the Amiga had a particular constraint. A map editor screenshot may explain more than a thousand lines of disassembly.
Don't let memory stay conversational. If the human says, the camera always led the player slightly, ask Claude to turn that into a checkable note: where it should happen, how to observe it, and which target file implements it.
This is also where concise repository memory helps. A small CLAUDE.md note can say which emulator output is canonical, which Godot version is used, and which behaviors must not be modernized without review. Keep it short. The agent should not need a novel before every run.
Try one reversible port slice
The safest experiment is one behavior, one target file, and one receipt. Pick something visible but bounded: player jump, ladder entry, enemy patrol, map tile collision, or camera follow.
Ask Claude Code to read the legacy code first, write a mapping table, make the smallest target change, and stop. That is not glamorous, but it keeps the agent from turning a reverse-engineering task into a weekend-long rewrite with no trail.
This fits the broader habit behind Team conventions: make the convention small enough that people actually use it. It also pairs well with the autonomy boundary discussed in Breaking Claude Code Opus 5 Auto Mode, where the hard part is deciding what evidence must exist before the agent keeps going.
The limitation is real. Claude can misread old CPU flags, infer the wrong coordinate system, or smooth away hacks that were intentional. The point of the workflow is not to make the model perfect. It is to make its guesses reviewable.
Copy this slash-command receipt
Use this as a small Claude Code slash command for one legacy-port slice. It is deliberately narrow. The command asks for a receipt before more code, which is the habit this story makes worth stealing.
# /port-slice
You are porting one legacy behavior, not the whole game.
Inputs:
- Legacy files:
- Target files:
- Observable behavior:
- Run command or scene:
Steps:
1. Read the legacy files and list the routines or data tables involved.
2. Write a mapping table from legacy symbols/instructions to target concepts.
3. Name every assumption, especially timing, coordinates, flags, and units.
4. Propose the smallest target change that ports this one behavior.
5. Make the change only after the mapping is clear.
6. Identify one verification step a human can run.
7. Stop and output the receipt below.
Receipt:
- Behavior ported:
- Legacy evidence used:
- Assumptions made:
- Files changed:
- Verification command or manual check:
- What still might be wrong:
- Question for the human:
If you repeat this more than a few times, turn the mapping style into a Claude skill. A good skill can carry the reusable knowledge: 68000 addressing notes, Godot scene conventions, emulator capture steps, and the receipt format. Keep the command for the task. Keep the skill for the reusable method.