Top
Best
New

Posted by rabahs 14 hours ago

Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly(babyloniantwins.com)
These are my notes from porting my Amiga game, which I originally built in Baghdad in 1993 in MC68000 assembly, to Godot, using Claude Fable 5 during last July holiday. It took an evening! Getting the feel right and shipping it took a few more weekends and evenings.

I spent the last few weeks analyzing what Claude did, feeding it my 33 years of memory of how I built the game, my notes and the git repos. It wrote the first draft of the article, and I edited line by line over a week. The screenshots of my 1993 map editor is the first I have run it since then. The one thing I never verified myself is the 108-byte explanation.

"Before starting everything, the model assembled the code using vasm on my Mac, and kept going till the binary is byte-identical to the binaries I had in my original game. Even after that, the there was mismatch of about 108 bytes. I originally used AsmOne which assembles into memory, and the game saved into the disk by saving that memory after running the game. So the original shipped files are a snapshot of the game that had already been running, not clean asm-one output."

Please post any questions. I am also releasing the original game for free.

232 points | 68 comments
mattjoyce 7 hours ago|
A few weeks ago I downloaded a memory dump of a zx81 game, and ask Claude to build it in Go. It nailed it. Converted the binary back to basic and then to go. My idea was that the game would be unknown to llm training and perhaps a nice bench.

What a crazy thing it is to be first at the advent of personal computing, and then in the inflection point where AI treats that first experience as archeology.

rabahs 2 hours ago|
Curious if you had to do any follow up prompts. How large was the binary and which model did you use?
btbuildem 10 hours ago||
> one copy of the Amiga Hardware Reference Manual

aka The Book... my, this brings back dusty memories

Babylonian Twins has such strong "Gods: Into the Wonderful" vibes, I wonder if that game was an inspiration for you

https://www.lemonamiga.com/game/gods-into-the-wonderful

https://www.youtube.com/watch?v=1kAXGjUwHyA

rabahs 9 hours ago|
The main inspiration for Babylonian Twins that nobody mentioned or even thought about was https://en.wikipedia.org/wiki/The_Maze_of_Galious it predates them all.
anonzzzies 7 hours ago||
Ah! How many times I played that game. I missed it on the Amiga after and never unfortunately saw your game. Those old MSX games just had good ideas.
dannyobrien 7 hours ago||
I just wanted to add how much in awe I am at you creating this game in '93 in assembly. Around the same time I was trying to write a game on the Atari ST, and the dedication to the project -- especially when documentation was so thin on the ground, pre-Internet -- is extraordinary. Do you have any stories from debugging the game? I always found that the most dispiriting part, after the endless hope of handcrafting the code that I was sure would work first time...
rabahs 7 hours ago|
Thank you for sharing your experience. It can be hard to remember all the details of debugging in assembly, but the main aspect I recall was managing game performance to ensure all rendering and processing stayed within 1/50 of a second. My technique was drawing a white line using the Amiga Copper, starting at the beginning of the top vertical blanking period. As I added more game objects, logic, and rendering, I had to make sure the line does not drop below the beginning of the active display area. If it went below that point, a frame would be dropped, resulting the game to flicker. I had to use many techniques to split the processing of the game objects in batches across multiple frames. Fun time.
Gamemaster1379 3 hours ago||
Neat project.I've been experimenting with making reusable console porting frameworks since last October. Opus 4.6 was my first success with the NES 6502.

Since then I've done static/native ecosystems for the Super NES, GBA. Nintendo DS, Playstation (most popular) and even Sega Genesis, such also uses the 68k.

https://github.com/mstan/segagenesisrecomp

I even extracted the 68k decoder to its own repo because I wanted to reuse it for the Phillips CDI.

Sega does Sonic 1 2 and 3&K. Also Rocket Knight adventures. Still early yet though. CD-I does the BIOS. Didn't get a game running end to end yet though.

rabahs 2 hours ago|
Cool. I wonder how much additional harnesses would improve the porting process. In my case, I gave more freedom to Fable 5. The model was able to figure things out. I am hearing that the latest models works better with less restrictions. Curious to know the progress on the above.
Gamemaster1379 2 hours ago||
If you want to see a bit more in depth, some shameless plugs but here's a few articles I've written as I've made progress:

https://1379.tech/building-enhancing-recomps-ecosystem-updat... https://1379.tech/recomp-ai-5-months-later/

Ultimately, Sega Genesis has been low priority. I've been focusing mostly on community feedback for my existing ones. Playstation is by far the most popular and the one I get the most PRs on. SNES is second. And right now Nintendo DS is newer, but has a very popular Metroid Prime Hunters I've been working a ton on.

NES and Sega Genesis get little attention. CDI and VirtualBoy [understandably] get no real attention.

I have an early original Xbox LLE prototype. Hoping to do more with it soon, but I'm all tapped out of usage at the moment. I got a lot done during all the crazy resets with OpenAI there for a while.

hedgehog 14 hours ago||
This is fantastic. It would be interesting to have Claude Code export an engineering guide for doing similar ports, including descriptions of the tooling it built to do it. I've done some reversing from binary but never with results this good.
ecliptik 4 hours ago||
I'm doing something similar for DOS SDL ports. Repo isn't public yet, but idea is to have a repo with a knowledge base, skills and patches agents can use when porting to avoid having to bootstrap everything from scratch.
rabahs 13 hours ago|||
This is a great idea. It could be a generic game porting skill to make the porting experience smoother. After my experience above. I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot!
sedawkgrep 10 hours ago|||
> I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot!

Oh wow...I hadn't even thought of trying something like this. There are soooo many games from that era that I'd love to play again without the hackery of emulation.

rabahs 9 hours ago|||
Just grab any game, especially old rom files form the 80s (I tried TimePilot and Road Fighter from MSX era). The model extracted the graphics, the sounds and then built the whole game. It takes less than 1 hour to port a 16kb rom file, in one shot. You will get a playable game, but you need a few follow up prompts to get it back to its original form. Usually some sprites or sounds issues, but very easy to fix, if you have played the original game.
ericd 10 hours ago|||
Yeah, someone reverse engineered Red Alert 2 recently. Took Fable cranking for almost a month, but it's pretty amazing to see.
hnlmorg 9 hours ago|||
Dumb question this, but how do you load it into Claude? I’ve only seen APIs for text and image uploads. Not random files. Or maybe that’s a limitation of the SDK I’m using?
rabahs 8 hours ago||
With Claude Code command line, you can point to any directory you have in your file system. In this case, Claude Code was working across three directories: the original game in assembly, the 2010 port in C++, and the new Godot port.
asimovDev 10 hours ago||
session stored on the drive would also contain all of the tool calls , right? unless op changed the default settings it would've expired though by now, since the run was in July
rabahs 9 hours ago||
That's a good point. I looked at the git history for my analysis. What is the best way to analyze claude sessions history? I definitely check if I still have them stored. Thanks
asimovDev 9 hours ago||
sessions are stored in the home folder somewhere but are deleted after 30 days by default. it won't be stored in the bash history, at least it does not for me on macOS with zsh + omz
b112 6 hours ago||
Of course is one does nightly, off site backups, all is well! A friendly note to all, always have backups!
ropable 3 hours ago||
Thank you to the effort of building this game in the first place (I'm sorry that I never got to try it then), and thank you for re-introducing it to us today. I'll give it a proper play in my leisure time.
rabahs 2 hours ago|
Thanks! would love to hear your feedback.
snvzz 31 minutes ago||
From the article:

move.l #$dff000,a0 ;Base for hardware registers

lea save(pc),a1 ;Get the system

move.w #$4000,intena(A0) ;from the AMIGA

Crude, although perfectly fine in practice. The system-friendly way is to call the function exec.library has for the purpose, Disable()[0].

0. http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodo...

rabahs 24 minutes ago|
[dead]
robviren 10 hours ago||
I'm actually glad to see it stumbled in a few areas. Always surprised to see how much it gets right though. I had always hoped the rather obscure parts of computer history and games would be this incredibly difficult area for Agents to mine.

The amount of non standard hackish and obtuse things that had to be done to implement things in the past feel impossibly complicated to touch today. Lots of people made it up as they went along and used the hardware in ways no one expected. Reminds me of Tim Follin doing the audio for Plock on SNES and Miamoto being shocked the audio was real. It would be so interesting to see what we could learn about development of the past from agentic insights into how code was constructed. I love stuff like this an appreciate the in depth post.

abrookewood 3 hours ago||
Must be incredibly rewarding seeing your game rebuilt. Fantastic bit of history too - I had no idea games were being made for the Amiga in Baghdad!
ericd 10 hours ago|
Wow, that's gorgeous for something written in assembly, running in 512k, nice work!
efficax 9 hours ago|
amigas were way ahead of their time. We had an Amiga 500 and then got a 386 and it was such a downgrade, but the Amiga was clearly a dying system.
ericd 6 hours ago||
Yeah, my cousin had one, was like a computer from a parallel evolution chain, kind of weird, but kind of awesome.
More comments...