| Links | https://stevewetherill.com |
| Serialized Memoir | https://stevewetherill.substack.com |
Continuing the agentic AI reverse engineering topic, I've been curious how the agents could handle actual disassembly from a binary file, vs decorating and formatting an existing disassembly. Since the game Arc of Yesod was basically a reskin of Nodes of Yesod, I thought I'd try there. The screenshot you see is an HTML block renderer generated by Gemini using the Skoolkit tool as the primary disassembler engine. This demonstrates that the agent understands where major data structures live and can render the graphics blocks as a proof of concept (the blocks are composed of 8x8 pixel characters with a per-block map). I'd say it is pretty promising!
Also, Claude Code sucked at this particular exercise.
#ReverseEngineering #RetroGaming #AgenticAI #ZXSpectrum #Skoolkit #Gemini
My project to polish, augment, and publish the disassembly of the 1985 game Nodes of Yesod using generative AI models continues and is going quite well. I am going to quickly skip over the 1 day of lost work when Claude decided to revert a change by overwriting a file (my Wiggum loop has a Git in it now), and instead just briefly mention a side quest I sent Gemini on, and that is to make me a web page to render the graphics blocks from the game. Well, that worked the first time, and you can see the results in the first image. It's just a static web page, but the fascinating thing (for me, at least) is that Gemini created it by analyzing the Z80 code flow and embedded data bytes in the game disassembly. I didn't extract the graphics in any external way. Anyway, that worked so well that I then asked Gemini to make a room renderer, in JavaScript, again based on its understanding of how the Z80 code renders the rooms. That can be seen in the second image - it's a web page with embedded JavaScript. Cursor keys navigate the map. Gemini struggled a bit more with this, but eventually, after some interactive prompting, it got it right, and I had Gemini create an .md file capturing its current state of understanding of that area of the code.
I've also had Gemini sketch out a plan for an NES port of the game. It'd be interesting to see how it handles the Z80-to-6502 conversion.
I tell you, we're on a wild frontier with this stuff.
This work continues. I have found that Codex seems to perform quite well; it is not as polished as Claude Code, but it is probably a bit better than Gemini CLI. I am toggling among the 3 as I explore this wild frontier.
I did find Codex a bit argumentative. I was trying to document a data structure, and it became very insistent in its point of view, to the point where I had Claude prepare a rebuttal, and so back and forth we went. Fascinating.
I'm tracking changes in Git now, not least because Claude copied over the work-in-progress file in a mistaken attempt to revert a change it made. That cost me a day or so of work. :(
I now have a verification loop in place where, after each change, the agents run the assembler to build the code, compare the binary with the "pristine" (less polished) source code version, ensure there are no errors, and then perform a binary comparison to confirm the output is the same. I also placed some "anchor" symbols in the code, and the verification step compares the values of the symbols against the map file from the original.
Attached is a screenshot of the Markdown file that the agents collectively maintain regarding the format and usage of one of the data structures.
I'll continue to post on progress.
I have been working on regenerating the (long-lost) source code for Nodes of Yesod, a game I wrote for the Sinclair ZX Spectrum in 1985. I have been picking away at this Z80 disassembly for nearly 20 years, starting with IDA and later moving to Ghidra.
While the project has been technically complete for some time (it reassembles to a binary identical to the shipped game), my goal is to release a fully documented codebase that is actually readable for future developers and historians.
To that end, this weekend, I compared the Claude Code CLI and the Gemini CLI for the specific task of identifying and defining symbols for methods, labels, and constants. In the past, I've run into context memory issues with the web interfaces, but the CLI tools seem to handle this single 30K+ line file very well.
Here is the breakdown:
Claude Code CLI: It is faster and understands the Z80 context with very few mistakes. However, it is significantly more expensive for this volume of work, running into Pro plan rate limits relatively quickly.
Gemini CLI: This allows me to work much longer before hitting rate limits on the Pro plan. It requires more iteration to get the output right, but it is a great workhorse.
The screenshots below show an example of the results, including some ASCII art Claude generated directly from the raw sprite bitmap data, and a section of code constants where both the name and comments were determined or augmented by Claude.
#SinclairSpectrum #OdinComputerGraphics #OldDogNewTricks #RetroDev #RetroGames #ReverseEngineering #SoftwarePreservation #ClaudeCodeCLI #GeminiCLI
