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.
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.
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!
> 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.
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
porting a 93 game with an llm reading 68k assembly while i'm over here struggling to refactor last month's javascript. we are not the same. seriously cool project though
Since Claude did the port and apparently understands it better than you do at this point, can we ask Claude? Is there a git repo we can point Claude at to interrogate it on the way things were done? Maybe you can share the transcripts you used to port it?
This is actually what I did to understand what happened during the port. I did analysis weeks after the game was ready.
While doing the analysis, I came to know about this 108 byte delta. I didn't quite understand the explanation Claude gave me. I added more details about this in the post above. It could be the difference in the assembler used, the environment used (Amiga 500 vs M5 Macbook), or how the binary was saved from memory 33 years ago
I really tried to start reading this because I am interested in the idea, but the obvious AI writing prose is just so off-putting that I can't force myself to continue reading it without my eyes rolling into the back of my head. I'm not against using AI to code, but if you're actually passionate about the project and want to share it with others, you should use your own words.
What's the point though? If you got the stuff it's better run in UAE. If you have none I don't trust you and therefore think the Amiga name is misleading. To gain trust here show some code running in UAE.
There is no point in "porting to Godot" because either you port Amiga stuff to UAE-likes or FPGAs or you in fact advertise "AN AI REWROTE MY CRAP GWBASIC GAME FROM 93 LOL". Lol. Which is riduculous.
and people will just laugh.
also 68k asm is actually human-readable compared to x86.
> 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
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.
Wow, that's gorgeous for something written in assembly, running in 512k, nice work!
Very cool! Wish you had released it back then
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.
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!
> 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.
Yeah, someone reverse engineered Red Alert 2 recently. Took Fable cranking for almost a month, but it's pretty amazing to see.
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
porting a 93 game with an llm reading 68k assembly while i'm over here struggling to refactor last month's javascript. we are not the same. seriously cool project though
> Please post any questions.
Since Claude did the port and apparently understands it better than you do at this point, can we ask Claude? Is there a git repo we can point Claude at to interrogate it on the way things were done? Maybe you can share the transcripts you used to port it?
This is actually what I did to understand what happened during the port. I did analysis weeks after the game was ready.
While doing the analysis, I came to know about this 108 byte delta. I didn't quite understand the explanation Claude gave me. I added more details about this in the post above. It could be the difference in the assembler used, the environment used (Amiga 500 vs M5 Macbook), or how the binary was saved from memory 33 years ago
I really tried to start reading this because I am interested in the idea, but the obvious AI writing prose is just so off-putting that I can't force myself to continue reading it without my eyes rolling into the back of my head. I'm not against using AI to code, but if you're actually passionate about the project and want to share it with others, you should use your own words.
I mentioned the same thing to OP by email, but this story is too good to block on that.
To me, someone with interest in amiga games and low level assembly ports, having that write up being done by hand wasn't load bearing.
Though I'd admit that using claude for a few hours every day this year desensitivized me to its prose :-)
There were a couple of AI tropes but not overly so. This is a great story, especially if you’ve programmed the Amiga before.
Think of it as: this is a story that quite possibly would not be told without AI to help with the writeup.
What's the point though? If you got the stuff it's better run in UAE. If you have none I don't trust you and therefore think the Amiga name is misleading. To gain trust here show some code running in UAE.
There is no point in "porting to Godot" because either you port Amiga stuff to UAE-likes or FPGAs or you in fact advertise "AN AI REWROTE MY CRAP GWBASIC GAME FROM 93 LOL". Lol. Which is riduculous.
and people will just laugh.
also 68k asm is actually human-readable compared to x86.