Key Summary
- Babylonian Twins is a game developed in Baghdad in 1993, with the original built on 72,758 lines of 68000 assembly
- The developer used a Claude variant (labeled Fable 5 in the summary) along with Claude Code to analyze the original’s behavior and data
- Based on the analysis, the original’s behavior and data were reconstructed within the Godot 4 environment
Analysis
Table of Contents
- Key Summary
- An LLM Legacy Porting Case Study: Porting 72,758 Lines of 30-Year-Old 68000 Assembly to Godot 4
- The Scale of the Original and Its Three Transformations
- The LLM Legacy Porting Procedure: How Claude Was Used to Analyze Assembly
- The Significance of the 50Hz Dual-Run Structural Approach
- Numbers and Limits: What Has Not Been Verified
- Implications: LLM Legacy Porting Requires Tooling and Procedural Transparency Together
- Key Issues
- What to Try Right Now
- Frequently Asked Questions
- Reference Source
An LLM Legacy Porting Case Study: Porting 72,758 Lines of 30-Year-Old 68000 Assembly to Godot 4
In 1993 Baghdad, an Amiga development team built a game out of 72,758 lines of 68000 assembly: Babylonian Twins. Three decades later, in the 2020s, a case of LLM legacy porting that brought this code to Godot 4 was posted on Geeknews (original post). The developer mobilized Claude and Claude Code to analyze the original and reconstruct it within the modern Godot 4 environment. I see this case as showing not a simple “retro game restoration” but the realistic limits and possibilities of LLM legacy porting at the same time.
The Scale of the Original and Its Three Transformations
The original is 72,758 lines of 68000 assembly, born in Baghdad in 1993. A C++ rewrite (roughly 34,000 lines) was made around 2010, and that C++ version had already been ported to Godot at an earlier point. Recently, the developer also brought the original 68000 assembly directly into the scope of LLM legacy porting. This is the interesting part: behavior and data were extracted directly from the original source and reconstructed in Godot 4, without a detour through an intermediate version.
| Stage | Year | Language/Engine | Code Scale | Notes |
|---|---|---|---|---|
| Original | 1993 | 68000 Assembly (Amiga) | 72,758 lines | Developed in Baghdad |
| C++ Rewrite | 2010 | C++ | ~34,000 lines | Intermediate porting step |
| Godot 4 Port | 2024~ | Godot 4 (GDScript/C#) | Undisclosed | Analyzed with Claude |
The LLM Legacy Porting Procedure: How Claude Was Used to Analyze Assembly
The developer used a Claude variant together with Claude Code. At the level of the publicly available summary, all we get is the statement that “the original’s behavior and data were analyzed and reconstructed in Godot 4.” The specifics, such as how the disassembly output was fed into the LLM and how function-level mapping was carried out, are not confirmed in the body. This is the most disappointing part of the LLM legacy porting discussion: the tools were opened up, but the procedure was never verified.
The Significance of the 50Hz Dual-Run Structural Approach
The most eye-catching attempt is the dual-run. The original’s behavior was reimplemented separately at 50Hz, and a modern Godot 4 version was layered on top, running both games simultaneously. It reads as an attempt to capture both source fidelity and modern convenience at once. From a practitioner’s standpoint, what matters in LLM legacy porting is that this kind of approach is closer to “reconstruction and concurrent execution” than a plain “port.” Even without a verified procedure, the resulting structure is quite aggressive.
Numbers and Limits: What Has Not Been Verified
All numbers depend on a single source (an RSS summary). For reference, the collected Anthropic commerce-agent blueprint (related context) does not cross-verify with this case directly. As a result, figures such as 72,758 lines, 34,000 lines, and the 50Hz dual-run need to be reconfirmed against primary sources (the developer’s GitHub or blog). In my view, this case shows the possibility of LLM legacy porting, but there is not enough verifiable information.
Implications: LLM Legacy Porting Requires Tooling and Procedural Transparency Together
The reason LLM legacy porting is interesting is simple. It plays a bridging role: the model interprets old code that is hard for humans to read and moves it into a modern language. However, with only the kind of one-line RSS summary seen in this case, it is hard to tell whether “the LLM actually understood the assembly, or whether it just ported the C++ version again.” For an LLM legacy porting discussion to hold up, procedural transparency has to come along with the tooling.
Key Issues
- It is unclear whether the original 68000 assembly was analyzed directly, or whether the existing C++ rewrite was ported again
- The 72,758-line, 34,000-line, and 50Hz dual-run figures rely on a single RSS summary
- The dual-run structure is a new attempt in LLM legacy porting, but there is no verified benchmark
- The Claude Code procedure (disassembly → prompt → mapping) was not disclosed
- There is a large verification gap between a single RSS line and the developer’s primary materials
What to Try Right Now
- Read the original Geeknews post directly and trace the developer’s primary sources, such as their GitHub or blog
- Slice your own legacy code into 100~200 line chunks and feed them to Claude to test function-level dependency analysis
- Build a small prototype in Godot 4 that runs a 50Hz loop and a 60Hz loop simultaneously to self-verify dual-run feasibility
- Create a prompt template that cross-verifies disassembly output (e.g., Ghidra output) against the original behavior using an LLM
- Do not rely on a single RSS feed; cross-check the developer’s GitHub commit log and issue tracker together
Frequently Asked Questions
What kind of game is Babylonian Twins?
An action game developed for the Amiga in 1993 in Baghdad, built on 72,758 lines of 68000 assembly. In the 2020s, its port to Godot 4 was reported as an LLM legacy porting case.
Can an LLM really read assembly?
In theory, yes, but in the publicly available information, the procedure by which Claude decomposed and mapped the original has not been confirmed. The actual procedure has to be verified through the developer’s primary materials.
What is the 50Hz dual-run?
A structure in which the 50Hz (European PAL) timing under which the original ran is reimplemented separately in Godot 4, and a modern version is executed alongside it to run both versions simultaneously. It appears to be an attempt to preserve source fidelity.
Can I try LLM legacy porting right now?
You can start by feeding small-scale code (hundreds to a few thousand lines) into an LLM in function-level chunks and extracting dependencies and behavior. However, you should not take results at face value; you need the habit of cross-verifying with disassemblers and static analysis tools.
Reference Source
This article was written after checking the following original source: Geeknews — Reading 68000 assembly of a 1993 Amiga game with an LLM and porting it to Godot
Expert Commentary (AI)
Software Reverse-Engineering Specialist
LLM-based assembly porting is a promising direction for lowering reverse-engineering costs, but without a verification pipeline, the substance of the engineering achievement is not guaranteed
Porting 70,000 lines of 68000 assembly to a modern engine is not a simple translation problem. It is a reverse-engineering task that must restore the cycle-level behavior of Amiga custom chips (Blitter, Copper, DMA) and irregular data layouts. It is a clear advance that LLMs can assist with function-level semantic reconstruction and data-table extraction, dramatically cutting the exploration cost that traditionally took months. However, at the assembly level, plausible-but-wrong interpretations are fatal, and without a deterministic pipeline that cross-verifies disassembler output (such as Ghidra’s) against the original binary’s runtime behavior, the reliability of the result cannot be secured. The structure of running a 50Hz original reproduction alongside a modern version is a practical variant of differential testing and is the most engineering-valuable idea in this approach. The core question is whether the LLM actually took assembly as input, or just re-ported the far easier 2010 C++ rewrite, which fundamentally changes the difficulty and meaning of the case. Ultimately, the future of this approach depends less on the model’s own capability and more on how much of a verifiable procedure is made public.
Game Engine Development Specialist
A 50Hz reference implementation and a modern version running in parallel is textbook design for preservation-style porting, but it needs frame-level verification tooling to go beyond a demo
Godot 4 has enough features for a 2D platformer port, but if the original’s logic was designed for PAL 50Hz timing and you stack it on top of the default 60Hz physics tick, integer-based physics and collision detection can drift slightly. The strategy of extracting level data and sprite tables directly from the original source for reuse is the right approach from a preservation standpoint rather than a recreation. Running a 50Hz reference implementation alongside the modern version is not mere technical showmanship; it can be the basis for frame-by-frame comparative verification. However, a design that runs both loops at the same time multiplies input handling, state synchronization, and debugging complexity, and without an automated frame-difference comparison tool it stays at the level of a symbolic demo. Community-led retro ports do make a real contribution to game preservation, but the value is only complete when licensing is sorted out and long-term maintenance is in place. The dual goal of preserving source fidelity while keeping modern convenience is itself a reasonable direction in this genre.
Critical Analyst
The “miraculous assembly porting” narrative is more likely a marketing symbol demanded by the AI coding-tool competition era than a piece of technical record
The biggest beneficiary in this matter is the AI coding-tool ecosystem led by Anthropic. The sentence “an LLM read 70,000 lines of 30-year-old assembly” is a viral narrative that both vendors and traffic-chasing aggregators need at a time when tooling competition is fierce. But look beneath the surface: derivative content being mass-produced from a single RSS summary without any primary output (repository, commit log, reproduction procedure) being confirmed is a signal that a narrative is being distributed, not a record. Details being muddled, like the unknown model name “Fable 5” in the summary, also suggest that this case went through a content-recombination process rather than being a technical document. What we should really pay attention to is not the success or failure of the port, but why unverifiable achievement stories happen to circulate in lockstep with AI-tool promotional cycles. The question readers should ask themselves is “what would I need to check to falsify this case,” and as long as that answer is not public, this narrative may be advertising rather than evidence.
Behind-the-Scenes Scenarios
- It is possible that the actual work was done primarily on the 2010 C++ rewrite, with the 68000 assembly only partially referenced — the C++ version is already known to exist, and there is no procedural record of direct assembly analysis anywhere, which is the basis for this hypothesis.
- It is possible that a personal hobby project was amplified into a “miracle case” by the traffic needs of community aggregators and the AI-tool ecosystem — a distribution structure in which many derivative articles were generated from a single RSS summary without primary-source verification is circumstantial evidence of that.
Leave a Reply