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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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
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
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.
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.
Thanks! Yes, this was not possible last year, and probably even a few months ago. Amazing times to revive forgotten games and software. Let me know if you have questions on my process.
I've been wanting to do some ports of old games i liked on the atari 400 i had as a kid. some of them I want to see if they would translate to a mobile web game. couple i'm looking to translate are Archon, lode runner, balderdash and maybe some of the ultima games, I really liked ultima 4.
Hmm did you ever run the game port against the original one in UAE? With the same inputs? Or is it just "it plays right when I play it"? That 108 byte delta is puzzling...
There are a few instructions that are functionally equivalent. It is possible that one of the assemblers has the ability to auto convert equivalent behaviour instructions into smaller instructions that do the exactly the same thing. That is fairly common in assemblers. If one of the assemblers had a normalisation phase where they treat multiple forms of the same instruction as the same thing prior to checking if a more compact encoding is possible then that normalisation phase could be generating a same size instruction with same behaviour but with a different encoding. A small number of bytes different with same behaviour is what I would expect from a reassembly like this.
The proof of the pudding would be to have a look at what the differing bytes were encoding.
You mean run them side by side ? No, I did not do that. I played the ported game on my Mac only. The movement feels right based on my thousands of hours playing the original. There was only small tweak I had to make the trampoline jump, but everything else ported so smooth. I think the decision that Claude made not to use Godot physics and just port everything as as, made the gameplay feels right without much tweaks.
Have you been following the videos on Youtube of the Amiga port of Sonic?
Their approach to replicating the behaviour is to run the original game logic. The display has to be totally rewritten but they had the advantage of 68k for both machines.
I don't know of any games that used the blitter for calculation like some programs did for MFM decoding, that might have presented quite the porting challenge.
No, I have not. I will definitely check before releasing the Amiga port inside the Steam. I think that would be the right approach, especially if you are porting a game you have not played enough. I did use blitter for all graphics. Now you mentioned MFM, I remember I wrote some disk copy protection code back in the day that leverages MFM encoding. I will check if that code is still around.
What I'm interested in is performance and memory use. How many times less efficient is the 2010 port compared to the original? What about this new one?
Are you interested in comparing the 2010 remake (C++) to the original (Assembly)? They are quite different games, so hard to compare, but both run at peak frame rate for their respective platforms (60fps vs 50fps).
I have not compared the 2010 port to the current Godot port. However, I felt the Godot port was smoother. I think that was because Godot uses the latest graphics frameworks (e.g Metal) vs old Opengl ES 1. It would also be interesting to compare the godot port of the original game vs the original in assembly. Curious how I can achieve that. A good question to ask Claude.
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
Thanks. I know the Amiga version took a long time. It was very hard to even look at the assembly code I wrote after so many years. AI was the hero that explained everything and helped me to package it for releasee. Enjoy!
How was Baghdad like in 1993? All I remember from that time was the Gulf war, Saddam and much conflict. I can only imagine how it would be finding hardware, books and resources such a time. That was hard enough even in parts of Europe.
Yes, it was a tough time after the war, but the main difficulty was the economic sanctions, which hit us hard. There are a few interviews and news articles published after I launched the mobile version back in 2010 that discuss our experience in the 90s. You can read more about it here: https://babyloniantwins.com/story/ I am happy to go into more detail on any aspect. I will be watching this thread regularly.
> 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.
Sooooo cool! I did something similar a few months ago: had the old source code (and executable files) of a game I wrote in 1991 (PC DOS) and a few notes in source code and, well, my old memories of how things worked. I didn't know how to compile it anymore but with the help of LLMs I managed to get it compiling again.
Since then I found about 8 pages of handwritten notes I took back in the days and I did immediately scan them and I added them to the repo.
Now my PC DOS from 1991/1992 does compile again and, well, I really should blog post about it one of these days (if only I had a blog...).
Thanks for sharing. It is truly an amazing feeling when AI helps us excavate the past. I never thought I would be able to do so. I'm so glad I kept all my files over the past 33 years.
Since Claude did the port, wrote the article, 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?
It's marvelous that software can be written with minimal human input, but I guess I'm confused about why I would talk to the human that prompted the AI, rather than the AI that did the work.
> ... confused about why I would talk to the human that prompted the AI, rather than the AI that did the work.
One reason is because you can't talk to the AI that did the work, not unless the human who prompted it is able to hand you a file with the complete session and/or context data. (And I'm not at all certain whether Anthropic would allow users to obtain that kind of thing, since it would probably be extremely useful to people trying to distill their models. It's possible they might allow user A to say "Hey, allow user B" (or anyone with the link) "to access my session with GUID ba5eba11-1234-5678-abcd-0decafc0ffee", but I doubt they'd ever allow context data to be downloaded and passed around).
Without the context, you're talking to a different instance of the AI that doesn't have the memory of the instance that ported the code, so the answers you get won't be nearly as useful.
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.
Yes, and that is unfortunately the worst of the fuzzy areas. We get a lot of emails from non-native English speakers asking why their posts are getting killed. This is what I usually say these days:
We understand that our non-native English speaking users are in a special position with all of this, and we sympathize - but we don't have an easy way to treat posts differently on that basis. What we're telling such users is to please write in your own voice and don't worry about any mistakes, because those are rapidly becoming signs of authenticity at this point (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).
To judge by how the AI classifiers react, translation tools are leaving a ton of LLM imprints on text which are not strictly about translation. As many of us have been learning, it's hard to restrict what these systems do. They are overeager on every level.
I hear you. However I wrote that assembly code 33+ ago :) Again, I mentioned elsewhere on this post and in the article, I had to review and/or edit every line in this post. AI biggest help in writing was referencing the right source / graphics..etc. Thanks
Your last point is exactly right. I wouldn't have had the time to do this port and write-up without the help of AI. Having said that, the AI wrote this based on my own notes and I edited and reviewed every line over a week. AI also helped with extracting screenshots and code snippets which would have taking me more time. I don't like to read AI writing either, but I thought that the fact that this is based on my own notes and experience and using original code and screenshots from the 90s would be of interest to the community. Thanks
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.
Suppose there are two options: remaster the game with AI assistance, or don’t remaster the game at all (because that would entail porting 72,758 lines of assembly by hand, and the time-to-reward ratio would be deemed to low for most people).
Why complain about the outcome? The old game remains available, and you can play it for free. This isn’t some zero sum situation where the existence of the remastered game sets the world back in some way. I could see being more interested (or only interested) in playing the original, but I don’t see what motivates the negativity.
This is inordinately harsh, though I agree with wanting to just play the original Amiga game. It's available at the following link from all the way at the bottom of the article: https://bithunch.itch.io/babylonian-twins
Thanks for the feedback. If you have read the article, I also mentioned that I have released the Amiga version for free to the Amiga community. AI actually helped addressing a few bugs and get it ready. You can download the ADF and play the full Amiga game for the first time since 33 years ago. This post was more about my experience using AI and interacting with assembly code from the 90s.
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.
Curious if you had to do any follow up prompts. How large was the binary and which model did you use?
> 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
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
Yeah, someone reverse engineered Red Alert 2 recently. Took Fable cranking for almost a month, but it's pretty amazing to see.
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?
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.
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
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
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
Of course is one does nightly, off site backups, all is well! A friendly note to all, always have backups!
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.
Thanks! would love to hear your feedback.
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!
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.
Yeah, my cousin had one, was like a computer from a parallel evolution chain, kind of weird, but kind of awesome.
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!
Great work! I'm planning to do that to another forgotten game (not mine) and it's great to see that this is now quite possible.
Thanks! Yes, this was not possible last year, and probably even a few months ago. Amazing times to revive forgotten games and software. Let me know if you have questions on my process.
Which game are you planning to do? We all should coordinate so we're not doing the same games repeatedly.
I've been wanting to do some ports of old games i liked on the atari 400 i had as a kid. some of them I want to see if they would translate to a mobile web game. couple i'm looking to translate are Archon, lode runner, balderdash and maybe some of the ultima games, I really liked ultima 4.
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...
Hmm did you ever run the game port against the original one in UAE? With the same inputs? Or is it just "it plays right when I play it"? That 108 byte delta is puzzling...
There are a few instructions that are functionally equivalent. It is possible that one of the assemblers has the ability to auto convert equivalent behaviour instructions into smaller instructions that do the exactly the same thing. That is fairly common in assemblers. If one of the assemblers had a normalisation phase where they treat multiple forms of the same instruction as the same thing prior to checking if a more compact encoding is possible then that normalisation phase could be generating a same size instruction with same behaviour but with a different encoding. A small number of bytes different with same behaviour is what I would expect from a reassembly like this.
The proof of the pudding would be to have a look at what the differing bytes were encoding.
You mean run them side by side ? No, I did not do that. I played the ported game on my Mac only. The movement feels right based on my thousands of hours playing the original. There was only small tweak I had to make the trampoline jump, but everything else ported so smooth. I think the decision that Claude made not to use Godot physics and just port everything as as, made the gameplay feels right without much tweaks.
Have you been following the videos on Youtube of the Amiga port of Sonic?
Their approach to replicating the behaviour is to run the original game logic. The display has to be totally rewritten but they had the advantage of 68k for both machines.
I don't know of any games that used the blitter for calculation like some programs did for MFM decoding, that might have presented quite the porting challenge.
No, I have not. I will definitely check before releasing the Amiga port inside the Steam. I think that would be the right approach, especially if you are porting a game you have not played enough. I did use blitter for all graphics. Now you mentioned MFM, I remember I wrote some disk copy protection code back in the day that leverages MFM encoding. I will check if that code is still around.
What I'm interested in is performance and memory use. How many times less efficient is the 2010 port compared to the original? What about this new one?
Are you interested in comparing the 2010 remake (C++) to the original (Assembly)? They are quite different games, so hard to compare, but both run at peak frame rate for their respective platforms (60fps vs 50fps).
I have not compared the 2010 port to the current Godot port. However, I felt the Godot port was smoother. I think that was because Godot uses the latest graphics frameworks (e.g Metal) vs old Opengl ES 1. It would also be interesting to compare the godot port of the original game vs the original in assembly. Curious how I can achieve that. A good question to ask Claude.
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
Very cool! Wish you had released it back then
Thanks. I know the Amiga version took a long time. It was very hard to even look at the assembly code I wrote after so many years. AI was the hero that explained everything and helped me to package it for releasee. Enjoy!
How was Baghdad like in 1993? All I remember from that time was the Gulf war, Saddam and much conflict. I can only imagine how it would be finding hardware, books and resources such a time. That was hard enough even in parts of Europe.
Yes, it was a tough time after the war, but the main difficulty was the economic sanctions, which hit us hard. There are a few interviews and news articles published after I launched the mobile version back in 2010 that discuss our experience in the 90s. You can read more about it here: https://babyloniantwins.com/story/ I am happy to go into more detail on any aspect. I will be watching this thread regularly.
It's interesting to know this.
> 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.
Sooooo cool! I did something similar a few months ago: had the old source code (and executable files) of a game I wrote in 1991 (PC DOS) and a few notes in source code and, well, my old memories of how things worked. I didn't know how to compile it anymore but with the help of LLMs I managed to get it compiling again.
Since then I found about 8 pages of handwritten notes I took back in the days and I did immediately scan them and I added them to the repo.
Now my PC DOS from 1991/1992 does compile again and, well, I really should blog post about it one of these days (if only I had a blog...).
Thanks for sharing. It is truly an amazing feeling when AI helps us excavate the past. I never thought I would be able to do so. I'm so glad I kept all my files over the past 33 years.
> Please post any questions.
Since Claude did the port, wrote the article, 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?
It's marvelous that software can be written with minimal human input, but I guess I'm confused about why I would talk to the human that prompted the AI, rather than the AI that did the work.
> ... confused about why I would talk to the human that prompted the AI, rather than the AI that did the work.
One reason is because you can't talk to the AI that did the work, not unless the human who prompted it is able to hand you a file with the complete session and/or context data. (And I'm not at all certain whether Anthropic would allow users to obtain that kind of thing, since it would probably be extremely useful to people trying to distill their models. It's possible they might allow user A to say "Hey, allow user B" (or anyone with the link) "to access my session with GUID ba5eba11-1234-5678-abcd-0decafc0ffee", but I doubt they'd ever allow context data to be downloaded and passed around).
Without the context, you're talking to a different instance of the AI that doesn't have the memory of the instance that ported the code, so the answers you get won't be nearly as useful.
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.
You made the right call. Very interesting article and great to hear about the history of game development that isn't focussed on the US market.
I couldn't detect it from my casual read. English is almost certainly OP's second language so it seems much more forgivable.
Yes, and that is unfortunately the worst of the fuzzy areas. We get a lot of emails from non-native English speakers asking why their posts are getting killed. This is what I usually say these days:
We understand that our non-native English speaking users are in a special position with all of this, and we sympathize - but we don't have an easy way to treat posts differently on that basis. What we're telling such users is to please write in your own voice and don't worry about any mistakes, because those are rapidly becoming signs of authenticity at this point (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).
To judge by how the AI classifiers react, translation tools are leaving a ton of LLM imprints on text which are not strictly about translation. As many of us have been learning, it's hard to restrict what these systems do. They are overeager on every level.
Yeah I think it's not 100% AI but my vomit senses started tingling at
> The test was deliberate.
> Step one, the safe ask
> Step two, the unfair ask
My guess "AI write a blog post about this" and then he edited it, but didn't quite eliminate the stench. Pretty close though to be fair.
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 :-)
I hear you. However I wrote that assembly code 33+ ago :) Again, I mentioned elsewhere on this post and in the article, I had to review and/or edit every line in this post. AI biggest help in writing was referencing the right source / graphics..etc. Thanks
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.
Your last point is exactly right. I wouldn't have had the time to do this port and write-up without the help of AI. Having said that, the AI wrote this based on my own notes and I edited and reviewed every line over a week. AI also helped with extracting screenshots and code snippets which would have taking me more time. I don't like to read AI writing either, but I thought that the fact that this is based on my own notes and experience and using original code and screenshots from the 90s would be of interest to the community. Thanks
Tics, tropes are worn out predictable plot devices
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.
Suppose there are two options: remaster the game with AI assistance, or don’t remaster the game at all (because that would entail porting 72,758 lines of assembly by hand, and the time-to-reward ratio would be deemed to low for most people).
Why complain about the outcome? The old game remains available, and you can play it for free. This isn’t some zero sum situation where the existence of the remastered game sets the world back in some way. I could see being more interested (or only interested) in playing the original, but I don’t see what motivates the negativity.
This is inordinately harsh, though I agree with wanting to just play the original Amiga game. It's available at the following link from all the way at the bottom of the article: https://bithunch.itch.io/babylonian-twins
Thanks for the feedback. If you have read the article, I also mentioned that I have released the Amiga version for free to the Amiga community. AI actually helped addressing a few bugs and get it ready. You can download the ADF and play the full Amiga game for the first time since 33 years ago. This post was more about my experience using AI and interacting with assembly code from the 90s.
You handled GP's post much better than I would have.