llm A field note by Vikrant Sharma
Someone fed 68000 assembly to Claude and got a working Godot port
A developer used an LLM to translate 1993 Amiga assembly into modern game engine code. The surprising bit is how much of it actually worked.
A developer just ported a 33-year-old Amiga game to Godot by feeding 68000 assembly to Claude. Not the high-level design docs. The raw assembly. The game is Babylonian Twins, a platformer from 1993. The original codebase is 68000 assembly for the Amiga 500. No one writes assembly for fun anymore, and reading someone else’s assembly from three decades ago is worse. So the developer tried something odd: paste chunks of assembly into Claude, ask it to explain what the code does, then rewrite the logic in GDScript. It worked. Not perfectly, but well enough that the game runs. The LLM hallucinated some details and misread pointer arithmetic in a few places, but it caught the control flow and the game logic. The developer had to fix the mistakes, but the starting point was readable pseudocode instead of raw opcodes. This is not how anyone teaches porting. The textbook approach is to rewrite from scratch using the original as reference, maybe with a design doc if you are lucky. But assembly is hostile to human readers. Variable names are gone. Comments are rare. Control flow is goto spaghetti. An LLM does not care. It has seen enough assembly in training data to guess what MOVE.W D0, (A0) probably means in context. The interesting bit is not that LLMs can read assembly. It is that they are now good enough to bootstrap legacy code into something a human can work with. You still need to know the domain. You still need to catch the errors. But the first pass is no longer the hardest part. I would not trust this for production firmware or anything safety-critical. But for a hobby port of a 1993 platformer? The LLM is faster than learning 68000 by hand.
Source: Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly
