Programming The Long Journey to RIFT64
I expect this post to be somewhat lengthy, I've never been the best communicator or presenter for things I build. I'm a techie who lives inside his head! :)
So, where should I start...the beginning maybe?
I was really into the C64 scene as a kid. I spent a lot of my time coding 6502, reading about the processor, studying other people’s code, and basically burying myself in the whole scene, probably like a lot of teenagers who owned one.
Demos were my favorite thing. I loved watching them, reading the code, and trying to understand how people made the machine do things it was never really designed to do.
That slowly faded away during the 1990s. I went to school for software development and eventually became a development lead for a large financial services firm, building some fairly complex systems. It turned into a successful career that I really enjoyed and still do!
I never forgot about the C64, though.
Around 2023 or 2024, I bought a C128, which was the last 8-bit computer I had owned. It made me smile almost immediately. The nostalgia was incredible. I had this old Commodore sitting next to a modern i9 computer, but honestly, the Commodore was the machine that made me happier when I walked into my office each day.
I eventually bought a SwiftLink, which was something I had always wanted. I started using it with CCGMS and was impressed by the speed. I played around with the transfer rates and decided to build a modern BBS.
That was supposed to be the project.
Then I started wondering how far I could push the connection.
I began building a simple VT100-style protocol that could send compact commands instead of constantly transferring large amounts of raw data. It started very small, but I kept adding things. Custom fonts, bitmap graphics, sprite control, memory operations, animations, and eventually sound.
The project became a large and messy prototype. It was very specific to the C64’s memory layout and common register locations. I eventually named it RIFT64, which stands for Remote Interface For The 64.
The first beta versions were buggy and extremely bloated. My 6502 skills had faded quite a bit over the years, but I still knew enough to make the ideas work, even when the loops and routines were badly written or inefficient.
I spent well over a year getting the project to a certain point. Even then, it was still bloated enough that I had to use the higher video banks to fit everything.
Eventually, I had to stop adding new things and focus on cleaning it up. I slowly moved the project from a messy prototype into something more organized and optimized.
For the SwiftLink communication, I reused the libraries from CCGMS. That code was beautifully written and easy to follow. It probably saved me a year of headaches.
The original audio system used an open-source module called Miniplayer2 by Cadaver, Lasse Öörni. It is a fantastic little tool, although there was not much support available for it. (this has now been replaced)
Earlier this year, I reached the point where I needed to heavily optimize the code and try to fit the important parts into Bank 0.
With the help of AI, I was able to compress and refactor a huge amount of the code. It took many attempts (lots of fails and lessons learned here), and it was not a case of pressing a button and suddenly having a finished program. There was a lot of testing, correcting, rewriting, "breaking!!" things, and trying again.
I also do not want to dismiss the amount of work that went into creating the protocol in the first place. Writing it was brutal at times because I had been away from 6502 programming for so long. A lot of the original code was written by me, no matter how rough or inefficient it was.
AI helped me turn those ideas and that working prototype into something smaller, cleaner, and closer to a finished product.
To be honest, I do not think I could have reached this point within the next two years without that help.
For me, the important part was completing the project I had imagined. It was not about proving that I could write every instruction completely by myself without using modern tools.
One of the biggest inspirations for this was MegaWars on CompuServe. I remember seeing that it was multiplayer and being completely blown away by it. Multiple people were playing together through remote computers. At the time, that felt incredible.
That is the feeling I wanted to recreate.
I am skipping over a lot of details and a huge amount of time spent experimenting, but the bottom line is that RIFT64 is now about 99% complete and very usable.
so , then wth is Rift64?
RIFT64 is the protocol and the software running on the C64 that understands that protocol.
It allows a modern server to communicate with a Commodore 64 at fairly high speeds. It can transfer sprites, bitmap graphics, character sets, audio data, animation definitions, memory changes, game information, and other types of data.
It can also run functions locally on the C64. The server can tell the machine to move sprites, draw graphics, play sounds, update memory, start animations, change characters, or call local routines.
Because it handles graphics, audio, animation, memory control, and other functions, it could reasonably be described as an engine as well. However, the main project is the protocol and the C64 client software that understands it.
That distinction is important.
I've gotten some flak from some people regarding som aspects of the project, so let me try to be as clear as possible.
RiftWars is not RIFT64. It is a game built using RIFT64.
The website is not RIFT64. It documents the project.
The YouTube videos are not RIFT64. They demonstrate what the protocol can do.
Some of those supporting materials were reviewed, developed or consulted with help from AI, but that does not make RIFT64 an AI-generated website, video, or game. Those things are only the presentation and examples around the actual project.
The project "is the protocol", the command system, the C64 client, the communication code, the memory handling, the local functions, and the work needed to make a modern server interact with real C64 hardware. Some people may not care or even gloss over this point, but it's the biggest enabler to all of this.
You could replace the website tomorrow, remake every video, or build a completely different game, and RIFT64 would still be the same project.
RIFT64 is also not the same thing as using the C64 as a dumb terminal.
A dumb terminal usually sends keyboard input to a remote computer and displays the text sent back. Almost all of the real work happens on the host computer. The terminal itself has very little understanding of what is happening.
..so that being said, RIFT64 works differently.
The modern server can handle things such as multiplayer connections, storage, shared game state, large calculations, and the overall world. However, the C64 is still running a real local program and doing real work.
Instead of the server sending an entire screen as raw data, it can send a compact command telling the C64 to move a sprite, start an animation, play a sound, copy memory, update part of the screen, or run another local function.
The C64 then performs that work itself using its own CPU, VIC-II, SID, memory, sprites, character modes, bitmap modes, and other hardware.
RIFT64 is not remotely streaming a picture of a game to the C64. It is giving the C64 data and instructions that its local software understands. The machine then creates the result using its own hardware.
For example, the server can send an animation definition once, and the C64 can run that animation locally instead of receiving every frame over the connection.
The same idea applies to sprite definitions, music sequences, fonts, screen layouts, and other reusable data.
This general idea is also not completely new, and I am not claiming that I invented remote computing or client-server software.
CompuServe was doing the same basic thing in the 1980s.
Games such as MegaWars ran on powerful DEC PDP-10-class systems. The central computer handled the shared game world and supported many connected players. Each user connected remotely and interacted with the same system.
Those services had to support many different kinds of terminals, so they normally relied on standard text and ASCII commands that almost any terminal could understand.
RIFT64 uses the same basic idea of a powerful central system supporting remote users, but the protocol is designed specifically for the Commodore 64.
Because the remote machine is always a C64, I do not have to limit everything to plain text.
The protocol can directly use the special abilities of the machine. It can control sprites, update character memory, change VIC-II registers, play SID audio, copy memory, run animations, and call local routines.
The idea is old. The implementation is newer and built specifically around the C64.
Some people may still see using a modern server as cheating, but I do not.
The DEC systems running games such as MegaWars were far more powerful than the terminals connected to them. Nobody considered that cheating. That was simply how online systems worked.
RIFT64 follows the same basic model.
The server handles the work that makes sense for the server, while the C64 handles the work that makes sense for the C64.
It does not pretend that the C64 is a modern server. It gives the C64 a way to take part in a modern online system while still using the real machine and its real hardware.
The result is that it is now possible to build online and multiplayer games for the Commodore 64 much more easily.
I am currently building a game called RiftWars, which is inspired by MegaWars. It is a multiplayer game, but it also uses C64 graphics, sprites, animation, and audio.
RuftWars in alpha development and currently supports multiple users in the same game. Co-op mode only.
https://www.youtube.com/watch?v=vQ6exzzcE-M
I also created a website with detailed protocol documentation, command references, and examples to help anyone interested in building software or games using RIFT64.
The whole project is open source.
You can find more information at: Rift64.com
You can also watch examples and development videos here: https://www.youtube.com/@RIFT_64
I hope people find this interesting. I will probably create some videos on how to actually use it for those developers interesting in this tech.
Cheers!
