C64 Programming with AI

Long Read. The reward - a knowledge pack for AI coding agents to create and debug C64 cartridges with file systems and a couple of games in cartridge format.

In late June 2026 I took on several projects for the Commodore 64 with Claude and Gemini. The first reason was: I had credits to burn. Due to a promotion there was $1000 worth of Anthropic usage in my account and I intended to spend it on some C64 stuff before it was gone.

(If you want to skip my "scene" rant, please go to the next heading.)

The second reason: There is stuff I want but nobody builds. The C64 "scene" is a strange place. There is a handful of people that do proper versions of good old C64 games for modern environments. There is OneLoad64 (mainly Statmat), Multiload64 (mainly Solo1870), some good conversions by Stephan Scheuer over at Forum64 and that's about it. Of course, every free game on itch.io gets "cracked" and vandalised with stupid intros and useless trainers and there seem to be many more people doing these inifintely stupid things then the handful of folks that want to build just the best versions of classic games.

Over the past two years I created projects that would make it easier to do proper re-cracks into cartridges, the major one being T64 to CRT. The resonance: One person did use the tool. But I got requests to please do more games myself. Over at Lemon64, two other fantastic tools saw the light of day, the Magic Desk CRT Linker from Pugsy and VICE Snapshot to PRG Converter from tommyo. I loved both tools, played around with them, made suggestions (that both developers kindly implemented) and then saw that basically nobody used them to do actually "fix" some of the games out there. And with the advent of the C64U, even more people just "want" stuff rather than build it - at least it feels that way when checking out forums. Well if nobody builds the games I want for my collection, I have to do it myself. I just don't have the time...

Turn IDE64 releases into cartridges

There are some games that have seen fantastic IDE64 conversions by "grue", that for years are in my "need to convert to a different format" stack. Because, unless you have a physical IDE64 unit or lots of time, these are just extremely unfriendly to run. IDE64 emulation in VICE is a pain, the C64U and the MEGA65 do not do IDE64 emulation either. Having these games either as carts or as SD2IEC games would be much nicer.

So I gave Antropic Claude the task to crack into the grue-versions of Portal and Alter Ego. To make this perfectly clear: 95% of the hard work was done years ago by grue, turning multi-disk track-sector based stuff into one giant binary blob that can be read by the IDE64 commands. Unfortunately, nothing else in the world uses that command structure.

Pulling stuff from a binary blob can be optimized best with a cartridge. So the task was: Turn the IDE64-version into an EasyFlash-Version. Without access the source code, so please find the calls and rewrite them.

Claude learns the C64

My expectation was: Install Regenerator2000 as an MCP server, install the MCP structure to remote control VICE and let Claude use those tools. After burning through about 600$ worth of credits Claude had written it's own disassembler and learned how to remote control VICE by himself because the existing documentation was incomplete and not correct. I had Claude do a lot on Autopilot. Imagine my surprise when I saw him find out about Warp mode himself to make debugging run faster.

Everything Claude learned about the process has been compiled into a knowledge pack that you can download here. More details about this later on. Just wanted to let you know that you, yes YOU, can save a lot of AI credits by reusing this stuff.

But it worked! I have fully playable, read-only EasyFlash versions of Alter Ego (Male and Female) and Portal. They are good only for emulator use with snapshots, because you can not save the game (yet). But they are pretty fast and a great proof-of-concept.

Alter Ego Male - https://webdrive.commodoregames.net/SHARE_MEHHHCB7PM

Alter Ego Female - https://webdrive.commodoregames.net/SHARE_0GQHYERZ7U

Portal - https://webdrive.commodoregames.net/SHARE_P6817XDNJN

Easyflash, Wasteland and running against walls

I spend quite a lot of time to get Portal to save the game progress. The whole thing made me very humble with folks that actually build games that save to EasyFlash. It's just not that easy. The way EasyFlash works is that you can only write Zeros. Once a bit contains a Zero, it can not be set back to a One individually. You can reset a full 64KB block to all Ones. So games that store stuff use two 64KB blocks and a "Ping Pong" structure - write into one block, until it is full, erase a second block, copy over what is valid and have the first block ready for erasure. That takes so much time (and wears out the flash) that you can not build anything that just writes a couple of bytes now and then. I have not given up on adding save to these games yet, but I was running out of time and credits and I had some more ideas in parallel.

There is this IDE64 version of Wasteland, also by grue. That one has a unique problem: It writes persistent game world changes into the large binary blob. Claude burned through some more credits to find a way integrating that into an EasyFlash cart, but it's next to impossible. So my idea was to use an SD2IEC device instead. Another $100 later Claude decided that this is not possible with a standard SD2IEC, because it misses a Write function. That has been included with the alternate "Thierer"-version of SD2IEC. So we tried building it for that. There is a version on my development machine, it does not really boot. I intend to "fix" it during 2026, but in the meantime I was building a third project. So, no Wasteland SD2IEC yet.

VICE Snapshot to PRG enhancements

Tommy Olsens VICE Snapshot Converter is a very clever piece of software. It takes a memory snapshot from VICE, finds nooks and crannies to hide its decompression code and creates a PRG file that can be run on a C64 to restore the state of the machine. It's a bit like an external freezer cartridge, using the capabilities of a modern PC to write code that can humans would need hours to hunt for short byte blocks and rewrite all the JMPs and other stuff.

In later versions (and because I asked), a CRT builder was added that could do the decompression either from EasyFlash or MagicDesk cartridges. And then another version came up, that could do floppy LOAD emulation, but only from an EasyFlash cartridge. Tommys reasoning: Once you turn off a MagicDesk you can't get it back. Now that is wrong - my T64 to CRT code exactly does turn it on and off. So I was ready to dig in and rewrite the EasyFlash code to also work with MagicDesk. And then I realized, this again is just perfect for an AI coder.

So I started another Claude instance, gave it access to Tommys Github, gave it my own code for MagicDesk switching, asked it to enhance Tommys tools and, with only a few credits worth of work, got a working version. Then I started getting more and more insane ideas. Change the way empty memory detection works, so that the typical C64 reset pattern (00 00 FF FF...) can be blanked out AFTER the fact. Move the loader to the last found free area. Add this to the UI. Make a PR.

With everything Claude had learned about cartridges and debugging right now, it was getting faster and better with the cartridge stuff. But it was still chewing on Wasteland in the other process... and my credits ran out.

Switch to Gemini / Antigravity

So I changed AI agents in midflight. I still had some Gemini left from my AI Pro subscription. The question was: when I give Gemini everything that Claude learned and documented in Markdown, would it be able to continue and add features?

Short answer: Yes. Very much so. In way shorter time I now had a version that on EasyFlash would also capture SAVE. Basically every adventure that uses Kernel LOAD and SAVE could now be turned into a cartridge semi-automatically.

Well, there was some cheating involved. In building EasyFlash versions of some Ultima games, Drunella created EAFS, a library for EasyFlash carts to offer a complete file system. I told Gemini and Claude about it, they pulled the repo and started integrating (with Gemini then finishing the work). There is a version that captures Load and Save on my Github. The Load and Save path is fully tested but pretty useless because not a lot of games use Kernel Save when they write highscores. They open a file and CHROUT to it. As I am writing this blog post, a version that does all that is up on the Github and untested - and it is Sunday evening, on the hottest weekend we had in Germany for quite some years, and I'd rather give all this into the community now instead of waiting until late September when I see my next time window for crunch coding. Also, at this point, I'd really like some feedback, especially from Tommy.

The current state of this project (end of June 2026):

Load and Save vectors captured and tested
Automatic Memory allocation changed to put stuff in top of memory ($C) so that in theory you can load stuff.
With the added memory requirements most automatic conversions WILL FAIL but if you can find a memory block that will survive the game code, it should work
Have a list of games that will be converted soon for real world testing.

That sounds fun! Can I help?

Sure, here is a couple of things you can do:

Play the three carts I uploaded and tell me about bugs
Go through the code on my Github and tell me about bugs
Take the knowledge pack, train your AI and build stuff for the community!

Really, yes, take that pack. It is a lot of human readable files, python tools and about $1000 worth of AI teaching itself C64 filesystems and cartridges. It will give you a headstart. You'll be amazed what Claude can do on Autopilot with this knowledge!

Contact me anytime via Github, Lemon64 (docbobo) or simply mail boris at dreisechzig.net. I'd really like to see somebody USE this because I am seriously considering building stuff only for myself in the future.

I hate you because you used AI!

Unless your mom knitted your clothing, please run around naked because you know some hundred years ago we invented machines to do knit clothing.

AI will not go away. Without AI I would never have found the time do to these builds. And let's make this 100% clear: There is about a dozen people in the world that do USEFUL stuff for the C64 preservation against thousands of users that just want to play the games. Unless you can code this yourself and have many hours of free time, I am not interested at all in your oppinion. If AI can help us all to get some C64 classics modernized, I'm happy to do so.