RIFT64 - Remote Interface For The 64

Bridging the entry barrier

To me, the Commodore 64 remains one of the most loved, unique, and iconic systems of our era, packed with distinct visual and audio qualities that stay unique to this day. However, writing native software requires a steep learning curve in 6502 machine language that many of us simply don't have the time to master.

There are millions of talented software developers globally writing in modern languages. I wanted to build a bridge to narrow that gap. By establishing a high-speed remote command-and-control stream, developers from any discipline can build rich, high-performance C64 software. You can offload database queries, complex game loops, and remote networking to a modern server—while your real Commodore 64 handles what it does best: rendering native graphics, shifting sprites, and playing synthesized SID audio.

My Inspiration: Re-evaluating Serial Potential

Many years had passed since I was lost in the Commodore world, but returning to it in 2022 sparked a wave of new ideas. After acquiring a SwiftLink clone cartridge in June 2023 and exploring BBSes, a realization struck me:

As I experimented with transfer rates up to 38.4kbps, it became clear that raw data transmission over a serial link was significantly faster than standard disk operations on the C64 IEC serial bus—even with fastloaders! This realization unlocked the potential for streaming remote memory and screen changes live. What started as basic experimentations (previously under the development name CRG) quickly evolved into a comprehensive, feature-complete remote terminal command system: RIFT64.

Hardware Compatibility

My philosophy is simple: RIFT64 should work wherever Commodore enthusiasts play.

Vintage Legacy Hardware: Run the RIFT64 client directly on an original Commodore 64 or Commodore 128 using a SwiftLink clone cartridge connected to a modem or serial adapter.
Modern Replicas: Built to run perfectly on modern hardware setups like the beautiful Commodore64U. The C64U features native built-in SwiftLink serial emulation. While I haven't been able to test on a physical C64U yet, technically it should work out of the box!
Emulation Safety: Fully supported inside emulators like VICE using virtual SwiftLink loops for clean, zero-hardware local development.

My Near-Term Roadmap

While RIFT64's V1 Protocol is feature-complete and currently in active Beta, my journey with this interface has just begun. I have several near-term goals planned to bring even more control, stability, and integration to the platform:

1. Direct SID Audio Support: I plan to expand the audio layer to allow developers to program and control the C64's legendary SID synthesizer chip directly, bypassing the need for pre-compiled song structures.
2. Connection & Crash Recovery (Safe Fallback): I am developing an automatic timeout handler. If the serial communication link stalls or fails, the C64 client will execute a safe, silent fallback sequence to seamlessly reinitialize RIFT64.
3. Native Mouse & Cursor Support: By expanding the upstream telemetry stream, I will integrate direct C64 mouse (like the 1351) coordinate tracking and cursor feedback, enabling point-and-click hosted GUIs.
4. Remote Custom Function Calls: I will build a secure, dynamic subroutine executor. This will allow developers to upload custom 6502 Machine Language code blocks and have them safely executed via system interrupt queues (much like the current high-speed MiniPlayer2 integration!).

🧠 A Note on Client Memory Footprints & Safety:

As I add these advanced features, the memory footprint of our C64 client naturally expands, pushing the "safe upload RAM" boundary slowly upwards from its base at $0800. Currently, the client's RS-232 ring buffer sits dynamically at the nearest 256-byte page boundary immediately following the RIFT64 assembler code. To manage this safely and dynamically, I plan to introduce a new protocol query command that provides the server with the exact start and end memory pointers for "reserved memory." This will guarantee that hosted application servers will never overwrite the client's own code and buffers during bulk memory writes!

About the Author

James Cann

DSI Alum // Creeping Death

I spent my youth writing 6502 assembly in the 1980s as a member of a Toronto-based Commodore software group called Damage Soft Inc. (DSI). Some of my fondest memories belong to those days. DSI was a small fish in an ocean of great groups, but it was inspiring. The team we had helped shape me as a developer for many years to come. I don't know what ever happened to them all, but I hope you all prospered in life!

After college, my professional path led to a career in Enterprise Software development. Along the way, I spent some time in music during the 90s—long live Metal! Having owned a VIC-20, C64, and eventually falling in love with the dual-screen power of the C128, I have brought decades of modern software design back to my childhood hobby, creating the RIFT64 terminal system to connect our retro machines with the modern world.

Watch it in Action

Check out my YouTube setup tutorial and live emulator configurations:

▶

VICE & SwiftLink Setup Guide Watch on YouTube

Credits & Open Source Acknowledgements

RIFT64 stands on the shoulders of giants in the Commodore 64 scene. I want to give credit to the incredible developers whose open-source libraries have helped make this project possible:

SID Music Player: The client's background audio routine is driven by Miniplayer2, a brilliant, lightweight SID sound module player created by cadaver.
ACIA/SwiftLink Driver: The high-speed serial communications code was taken from the robust rs232lib within the legendary ccgmsterm terminal emulator repository by mist64, with some custom, lightweight modifications to the ring buffer address placement.