How to Load Programs onto a C64 — An Engineering Approach

Background

Not too long ago, my retro collection was spontaneously enriched with two Commodore 64C units. I found them in the attic, restored them, and got them working again. I wrote about that story in detail in two earlier posts. Once they came back to life, the question immediately arose: where to go from here? On its own, a C64 is just a blinking cursor on the screen and a keyboard through which you can issue boring commands, or maybe write and run programs in BASIC. But by itself, this doesn't really amount too much, it shows off very little of what the hardware is actually capable of, and on top of that, everything is lost when you switch it off. To do something meaningful with it, you need at minimum some kind of storage device: a cassette deck, a floppy drive, or perhaps an expansion cartridge. Unfortunately, I had none of these.

I could have solved the problem by simply buying a storage device, but honestly, there would have been no challenge in that. I prefer creative pursuits, and I saw this instead as another DIY project - one that would give my dopamine levels a nice boost.

Concept

The idea was to download Commodore 64 programs from the internet onto a computer with an internet connection, and then somehow transfer them into the memory of the Commodore 64. The Commodore 64 has several ports through which it can connect to the outside world. Of these, the IEC serial port seemed the simplest, since the floppy drive also connects to the computer through it. The port can be accessed via a 6-pin DIN connector. Luckily, I had one of these plugs at home.

I set the following requirements:

• The Commodore 64 should be connectable to a PC via the IEC serial port.
• It should be buildable from parts available at home.
• A prototype-level implementation is sufficient.

Planning

Implementing the idea above can be split into two parts: hardware interfacing and software implementation. I needed hardware that would allow the Commodore 64's IEC serial bus to be physically connected to a PC's USB port. On top of that, I needed software capable of interpreting the IEC serial data protocol implemented by the Commodore 64 at the low level, and the CBM DOS file protocol at the upper level. Naturally, this also requires a PC-side companion application, essentially a file server that can emulate the contents of a floppy disk. Put it all together, and what you get is effectively a virtual 1541 floppy drive.

The Hardware

The basis of the interface ended up being an Arduino Uno, which by default provides a connection to a PC via its USB port. The only remaining question was how to implement the IEC-side interfacing. A bit of overengineering slipped in here, because I ended up designing a transient overvoltage protection and signal-shape stabilization circuit, which on one hand protects the Arduino's ports, and on the other hand allows for more stable signal transmission.

IEC interface

The overvoltage protection is implemented by Schottky diodes, and the signal-shape stabilization by Schmitt trigger gates. Since the IEC serial bus is an open-collector bus, I solved the bus control for the reverse-direction communication with two separate NPN transistors. In principle, this could have been spared - the Arduino's ports could have been used directly - but the separate transistor-based solution also serves to protect the Arduino against overload, since its ports can sink a maximum of 50 mA. Theoretically, if more than 10 devices were connected to the IEC serial port with the standard 1 kΩ pull-up resistor, the load would already exceed this limit.

Parts for the IEC interface

I soldered the adapter together on a prototype PCB, and also made a cable that plugs into the serial port, which I connected to the Arduino through the interface circuit.

IEC-USB adapter

The Software

We developers like to say that the hardware is the body and the software is the soul. Without software, the hardware is a lifeless body. Without hardware, the software is an intangible nothing, a theory. In this case, quite a lot of responsibility falls on the software.

The IEC serial protocol is, on one hand, not publicly documented, and on the other hand, based on very strict timings. Fortunately, diligent people have reverse-engineered it, documented it, and - not least - implemented it as well. Details about the port's design and operation can be found at the following locations:

• https://www.c64-wiki.com/wiki/Serial_Port
• https://retro-bobbel.de/zimmers/cbm/programming/serial-bus.pdf

Luckily for me, David Hansel implemented the IEC serial protocol in a cross-platform fashion for several popular microcontrollers, including the Arduino Uno, which made my work much easier. Based on his library, I wrote a firmware that handles the IEC serial communication coming from the Commodore 64 and forwards the file transfer operations built on top of it to the PC via UART.

With the hardware and software solutions built so far, communication was successfully carried through to the PC side. What was missing was the PC-side implementation. I needed to make sure the CBM DOS file operations arriving from the Commodore were served from the PC's file system.

For this, I wrote a PowerShell script that implements a file server. The server's configuration includes the path of the PC-side folder where the Commodore 64 programs are placed, the identifier of the serial port through which the IEC-USB adapter can be accessed, and optionally the IEC Device ID under which the Commodore 64 sees the file storage device. In the case of a floppy drive, this defaults to 8, but it can be overridden if needed.

File server in action

The file server handles loading the directory file (LOAD"$"), the very first program (LOAD"*"), and specific programs (LOAD"NAME.PRG"). It also supports saving a program from the Commodore 64's memory (SAVE"NAME.PRG"). With these operations, I essentially created a virtual floppy drive that can be used to load and run PRG files. However, it isn't suitable for handling every file operation (e.g., multi-load, fast-load), nor for working with Commodore 64 disk images. Despite this, I believe the goal set for the project has been achieved.

File catalogue

In the end, I rewrote the PowerShell script in Python so that the file server could also run on Linux, allowing my NAS server to serve Commodore 64 programs as well.

Summary

There was a problem with several possible solutions. I chose the engineering approach because that's what brought me joy. Imagine you have a working Commodore 64 right in front of you, but you have no device and no media to bring back to life the old, familiar games and programs you haven't seen in ages on this machine. You don't give up, instead, your mind gets to work, you figure out how to solve it creatively, and after overcoming numerous obstacles, you bring your vision to life. The reward is nothing less than this: a week later, you manage to load the very first program onto the C64 using a solution you built yourself, start it up, and watch the whole thing come alive in front of you.

And finally, I was able to show my daughter what games we used to play back in our day.

A few of the many programs that after 40 years simply had to be launched again: Ghostbusters, Invaders, Boulder Dash, Trail Blazer, Pac-Man, Arkanoid, ...

My daughter is playing Arkanoid

The project is available on GitHub here: https://github.com/fox20io/c64-fdemu

And here comes the next problem that must once again be tackled: the best games can only be played with a joystick :) Of course, I don't have a joystick either. I could buy one or two, but again, there'd be no challenge in that. So one must be built. I'll write about that in the next post.