Nice to see an MCP integration here as well. In my experience, coding agents are great at analyzing MOS6502 code. Because the code is limited to only 64 kB, it does not overwhelm the agent. And in parallel it can write specs and even extract assets via normal coding tools.
Using my similar tool [0], I feel I get roughly a 100x speedup. I will definitely try regenerator2000.
Most such emulators have Internet access on the IP level. Therefore, this is a very cheap way to test anything on the Internet.
apk add nmap
nmap your.domain.com
However, the speed is heavily throttled. You can even use ssh and login to your own server.
It can also be used as a very cheap way to provide a complete build environment on a single website, for example to teach C/C++. Or to learn the shell. You don't have to install anything.
To reverse engineer old C64 games using Coding Agents, I built a CLI and MCP flow disassembly tool. The agent can search the disassembly, provide annotations, manage symbols, and reinterpret code and data.
AI is very effective for reverse engineering. Unless you’re doing it purely for fun, it makes sense to use AI where it helps.
I’ve tried to visualize the “navigate and modify” process you mentioned in [0]. It’s mesmerizing.
Because reverse engineering outcomes are comparatively easy to verify, it’s a good fit for training for AI. I expect major progress in the next few years, potentially to the point where reverse engineering many binaries becomes highly automated.
My first agent test was pointing it out to my toy compiler repo (L98) and ask to translate the AT&T Assembly files that gave me so much trouble to come up with (my head has Intel syntax burned into it), and translate it back to Intel syntax.
In a couple of seconds I had it back.
Didn't bother commiting the changes, because it works and was a toy compiler anyway.
About halfway through my reverse-engineering process, I came across those documents and realized that roughly 50% were missing. I searched pretty much the entire web to see if anyone had stored these files elsewhere, but so far I haven’t had any luck.
Author here. I’m happy to see one of my projects on Hacker News. This has been a fun one. One evening you just try to disassemble it and wonder where the code is. The following months were a truly satisfying experience, reverse-engineering this diamond.
There is still a functioning Forth interpreter implemented in the game. If they hadn’t removed all the word names, it would have been possible to debug at any time and analyze the program state and call functions live with real Forth code. Some crazy feature at that time.
Some early source code snippets of the game have even survived and can still be found on archive.org [0]. By today’s standards, they’re almost unreadable.
A fantastic read, and really interesting to see the use of Forth. I remember Forth having a bit of popularity in the 80s. This was such an amazing game, especially in that you felt like the world was huge with the encouragement to just explore.
The other game this reminds me of is a game for the TI99/4a called Tunnels of Doom. It was a cartridge game that also had a floppy or cassette data load. It had a dynamic dungeon creation so every time you played the game you got a new unique experience. That would be an equally challenging one to reverse engineer due to the oddity of the GROM/GPL architecture in the TI99/4a.
I’ve performed many experiments using AI to reverse-engineer old games like this one, and it looks like the newest generation of models has no trouble with it. They’re actually awesome.
Even with the current models, we might be able to automatically reverse-engineer all those old games, decode all assets, and even rewrite them in a more sensible language than assembler.
For the Atari 2600, Assembly is almost a necessity because of the very tight "racing the beam" timing required to draw things correctly on the screen. Your argument applies to some other platforms and games, though (not that many among the oldest ones, to be honest).
"Racing the Beam" is a great book by MIT press that covers the specifics of the Atari 2600 platform. The 2600 sparked a number of innovations _largely because of_ the limitations of the platform forces you to think outside the box.
There’s a small misunderstanding here. Reverse engineering by annotating a disassembly file is fine. However, the next obvious steps would be to write a sensible, high-level documentation of the internals of the game and then port it to a high-level language.
Indeed, whether this would run on the original hardware might be questionable for such an Atari Game. But have you seen modern C compilers like Oscar64 [0] for such old hardware? Never say never …
I’ve also been playing around with reverse engineering, and I’m very impressed. It turns out that Codex with GPT-5.2 is better at reverse engineering than Claude.
For example, Codex can completely reverse-engineer this 1,300-line example [0] of a so-called C64-SID file within 30 minutes, without any human interaction.
I am working on a multi-agent system that can completely reverse-engineer C64 games. Old MS-DOS games are still too massive to analyze for my budget limit.
Oh, interesting. I started using the ReVa/Ghidra MCP server together with Claude since day 1 (Well, since Claude Sonnet 4.0 was released) and I saw Claude get better at it with every update. I've gotten pretty far in reverse engineering a game from the early 2000s (though I still have to do a lot of things manually, but this then also taught me A TON about Ghidra)
Blast from the past. In my mind, the Adventure Game Studio is forever tied to the ancient (German) Maniac Mansion Mania website [0]. Yes, that Maniac Mansion from Lucasfilm Games.
To this day, they’re are releasing fun new adventure episodes in the Maniac Mansion universe.
Using my similar tool [0], I feel I get roughly a 100x speedup. I will definitely try regenerator2000.
[0] https://github.com/s-macke/OpcodeOracle
reply