Glonce

Claude Fable 5 ports 1993 Amiga 68000 assembly into Godot

agentsThe Glonce editorsHacker News🔥69Glonce rating69Impact45Novelty65Relevance88Surprise60Players40Credibility85

In 1993, in Baghdad, an engineering student in their twenties built a platform game called Babylonian Twins on an Amiga 500 with 512KB of RAM and no hard drive, writing every sprite and scanline by hand in pure 68000 assembly and programming the hardware directly from the Amiga's own reference manual, with no internet or other resources available under the sanctions of the time. Murtadha Salman drew the art and Mahir AlSalman composed the music; heat and constant floppy-disk swapping killed the developer's disk drive three times during that work. It became the first commercial game made in Iraq, but Commodore's collapse and the sanctions scared off publishers, so it sat unreleased until an Amiga enthusiast forum tracked the developer down in 2008 after finding footage the developer's brother had posted to YouTube. In 2010 the same team hand-built a from-scratch iPhone engine for it, about 34,000 lines of C++; Apple and Google featured that port, and it passed over two million downloads.

The developer has now had an AI model they call Claude Fable 5, running inside Claude Code with a terminal and access to their filesystem, rebuild the game a second and third time. The premise was a deliberate test: 68000 assembly for a discontinued 1980s home computer is unlikely to be well represented in any model's training data, so succeeding at it would suggest the model was working the logic out rather than recalling a memorized answer, unlike an earlier, unnamed model the developer had tried about a year before, which needed several rounds and heavy hinting to make sense of the game's binary level maps. Over the July 4th weekend the developer set three sequential goals, in their own words the safe ask, the unfair ask and the greedy ask: port the 2010 C++ engine into Godot 4 as a control; separately rebuild the original, undocumented 72,758-line, 26-file 1993 assembly source into Godot at the Amiga's original 50 Hz, with no hints this time; and finally fold that assembly-derived build into the C++-derived one, so the modern release also contains the original as a bonus, launchable extra. All three succeeded, the developer reports. The level-format problem that had taken the earlier model several corrected rounds a year before came out right in a single pass this time.

Porting the 34,000-line C++ engine took one evening: the developer's timestamped log shows a bare Godot 4 project at 22:23, both playable characters with working collision and camera by 22:44, all 38 entity types ported by 23:19, and builds exporting to macOS, iOS and Android by 02:15. About three more days went into making movement feel right (jump arcs, trampoline timing, hit detection), tested every night alongside the developer's thirteen-year-old son. The port kept the original's own hand-written, 150-line player-collision code rather than switching to Godot's built-in CharacterBody2D system, carrying over old tuning constants unchanged, including one the developer calls an unexplained stray 0.49 offset that nobody tidied up. It also deliberately kept two different fixed tick rates, 50 Hz for the assembly-derived build and 60 Hz for the C++-derived one, matching each original's own rate, since a frame-multiplied constant like the ported code's 0.85 ground-drag factor behaves differently depending on tick rate.

The harder test began the following Sunday. Before porting anything, the process first got the 1993 assembly reassembling on a modern vasm toolchain until its output matched the originally shipped binaries byte for byte, reconciling differences between the 1993 ASM-One assembler's conventions and vasm's; one early attempt miscounted a rewound memory block and shifted 944 bytes of output, including the video-coprocessor display list, before the developer says it was tracked down and fixed. A remaining discrepancy of about 108 bytes was explained, according to the developer, by the AI itself: the shipped disk files are a snapshot of the game's memory taken after it had already run once, so leftover uninitialized-variable bytes differ from a clean assembly's zeros but are harmless because the code overwrites them before reading them. The developer says this is the one part of the account they never independently verified themselves.

From there, the process worked out the game's undocumented file formats by reading the assembly routines that used them. A 1,652-line uncommented level loader yielded correct tile maps for all five levels on the first attempt, later confirmed pixel for pixel against the developer's own 2020 reference screenshots once two missing effects, a scrolling sky-color gradient and a water color cycle, both driven by the Amiga's video coprocessor, were restored: five images, zero differing pixels. A 16-bit map-cell format was decoded by cross-referencing two different assembly routines that each read half of it: values 1 to 3 mark walkable or climbable ground, 10 to 13 mean damage from a given direction, 14 is instant death, and 63 marks a door. The process also recovered and ran a 1993 level-editor tool under emulation to produce a screenshot: MEDITOR.S, 1,254 lines built, per its own source comment, in four days in February 1993 by the developer, its design worked out with their then-studio partner Udai, who was separately building a game of his own that was never finished. It also discovered that in-game doors are drawn by runtime code rather than stored in the level map data, resolving what had looked like a contradiction, and correctly resolved an ambiguous sprite-sheet size convention by asking the developer directly, who confirmed their own 1993 design choice.

Embedding the 1993 build inside the modern one, Step three, took a single evening, from 21:58 to 23:43. Testing then surfaced concrete bugs introduced by the ports. A spear-carrying enemy soldier, whose only job was to shove whoever stood at its own feet, could instead hit the player from thirteen tiles away through solid rock, because the ported collision check kept the original's lower distance bound but dropped its upper one. A feature letting the two playable twins swap places at any distance had to be cut after the process traced resulting map corruption to the game's own original design: an idle twin is drawn directly into the level's tile data as a stationary statue, and two overlapping statues overwrite each other's tiles, rather than to any missing distance limit. And a complaint that the trampoline felt too high, at first blamed on the ported physics constants (which a short simulation confirmed were correct, predicting 19.1 tiles against a measured 19.5), turned out to be a difference in how Godot polls the jump button compared with the 2010 iPhone build's event-driven input, itself a legacy workaround for an old tvOS quirk.

The process then handled the commercial release: generating store screenshots at five pixel sizes in eleven languages, always using the game's real fonts and real translated strings rather than any AI-rendered text (one generation run failed, and empty caption boxes in Russian and Korean were caught before upload), plus a preview video and icons in six shapes, across iOS, Android and Steam. It drove the iOS and Android submissions through their official APIs, and, since Steam has no equivalent API, operated the Steam web dashboard directly through a browser; the developer reserved only logging in and pressing final submit, publish, price and release buttons for themselves.

It also pulled and triaged the game's fifteen years of Google Play reviews, working around the official API's seven-day history limit with a public scraper, and flagged a poorly spelled one-star review reporting that a door on level one would not let the player finish the level. That review described a genuine defect: a level-complete prompt existed in only two of the game's eighteen levels, and one level missing it was the last free one, meaning a prospective buyer hit an apparently broken game exactly when deciding whether to pay. The fix shipped as version 2.0.3 on both stores.

The result, Babylonian Twins: Definitive Edition, is live now on iOS and Android with a free demo on Steam; the full Steam release for Windows, Mac and Linux, bundling the 1993 original as a launchable extra, is due this fall. Separately, the original 1993 game is now free to download on itch.io, playable in an Amiga emulator or on real hardware, thirty-three years after it was built. The developer also had the same AI draft this account of the project from their notes and the two codebases, then spent a week editing that draft by hand; they say the code, timestamps and screenshots in the post are real, though the AI's explanation for the 108-byte mismatch is the one part they never personally checked.

Key facts

  • Claude Fable 5, running inside Claude Code with a terminal and filesystem access, first made the 1993 game's 72,758-line, 26-file 68000 assembly source reassemble byte-identical to the originally shipped binaries, then ported it into Godot at the Amiga's original 50 Hz.
  • It separately ported the 2010 iPhone remake (about 34,000 lines of C++) into Godot in one evening, reaching a playable character in 21 minutes and all 38 entity types by the end of that first night; movement then took about three more days of tuning.
  • It reverse-engineered undocumented file formats, including a 16-bit tile-property encoding and a sprite-sheet layout, by reading the assembly routines that used them, and verified the rebuilt levels pixel for pixel against the developer's 2020 reference screenshots: five levels, zero differing pixels.
  • It found and fixed real bugs introduced by the port, including an enemy that could hit the player from thirteen tiles away and a level-completion prompt missing from sixteen of eighteen levels, the second caught only via a one-star Google Play review.
  • The result, Babylonian Twins: Definitive Edition, is live on iOS and Android with a free Steam demo; the full Steam release lands this fall bundling the 1993 original, which is now also free on itch.io.

Why it matters

The developer designed this deliberately as a test, not just a port. Step two, rebuilding the original 1993 assembly rather than the already-ported C++ code, targets 68000 assembly for an Amiga computer discontinued decades ago, exactly the kind of material unlikely to be well represented in any model's training data; succeeding would suggest the model was working the logic out rather than recalling a memorized answer. The developer reports a concrete before-and-after: the same class of problem, recovering a level's binary format, took an earlier, unnamed model several corrected rounds and heavy hinting a year prior, and came out right in a single pass this time. From there the process reconstructed the original binaries byte for byte, recovered undocumented file formats well enough to pass a pixel-for-pixel check, and carried the result through an actual multi-store commercial release rather than stopping at a demo.

Who it affects

Most directly: indie developers and hobbyists sitting on old, undocumented personal codebases, who previously had no route back into them beyond a hex editor and years of guessing. It also speaks to game-preservation efforts (the process here recovered a lost two-disk retail release from a clue in one file) and to anyone evaluating what agentic coding tools can do with legacy, low-level code specifically, rather than the modern, well-documented codebases most coding-assistant demonstrations use. More narrowly, it affects Babylonian Twins' own audience across three eras: original Amiga owners, the 2010 iPhone port's audience of over two million downloads, and new Steam and mobile buyers.

How to use it

The workflow depended on giving the model real leverage, not just a chat window: running inside Claude Code gave it a terminal and access to the developer's filesystem, so it could edit files, invoke the actual toolchain itself (the vasm assembler, the FS-UAE Amiga emulator), and run two headless checks, compiling every script and building every level, before showing the developer anything. It used its own diffs against the originally shipped binaries and pixel comparisons against old reference screenshots as objective correctness checks, rather than relying only on the developer's judgment. Command-line flags (to load a level directly, position characters exactly, script input frame by frame, or dump a screenshot) turned subjective questions, like whether a jump felt right, into something machine-checkable. For the release itself, it drove the iOS and Android submissions through their official APIs and, since Steam has no equivalent API, operated the Steam web dashboard through a browser instead, with the developer keeping only login and final publish, price and submit actions for themselves.

How solid is it

This is a single first-person developer account, not an independent benchmark or third-party audit: the byte-identical reassembly and the zero-differing-pixels claims are the developer's own report of running their own diff and comparison tools, not externally reproduced. It is unusually well corroborated for an anecdote though, coming with real timestamps, code excerpts, and a shipped, downloadable, checkable result: an actual live store listing and a free original disk image. Tellingly, the developer flags the one point in the account they are least confident about themselves, the explanation for the leftover 108-byte reassembly mismatch described above, and says outright that the AI's explanation was taken on faith and never independently verified.

Risks and caveats

This is one elaborate case, verified largely by a developer unusually equipped to check it: they wrote the original code themselves, tested every build personally, and could recognize a wrong decision (a distance ambiguity, a corrupted map) because they remembered the 1993 design. By the developer's own account, nothing automatically checked whether the newly built, C++-derived Godot port looked or felt right beyond their own eyes and play-testing; only the separately recovered 1993 level data got a pixel-for-pixel check. A less specialized user, or a less benign codebase, would have fewer ways to catch an error, and no failure rate, cost, or token figures accompany the successes described here. Several of the process's own findings, that doors are drawn by code rather than stored in the map, or that a sprite-sheet's size value meant two facing rows, were confirmed only because the developer happened to know the answer; the one claim they could not personally check, the 108-byte explanation, is the reminder that a fluent, plausible-sounding account from the tool is not automatically a correct one.

“The part I'm least sure of is the 108 bytes: the model told me the shipped files were a memory snapshot saved after a run, and that the code writes those variables before it reads them. I read that, moved on, and have never checked it myself.”

— the developer