An Afterlife User's Guide to the C64

Introduction: Part II

Remember all those ports we looked at, at the beginning of Part I? Well, they're all designed to hook up extra stuff to your C64. Mice and game controllers, sound and video expanders, storage devices and more memory. Freezer cartridges, breakout boards, eprom burners and realtime clocks. Ethernet adapters, high speed RS-232, and TCP/IP WiFi modems. There is a huge selection of cool stuff you can add to your C64 to extend its capabilities.

Check out the Commodore 8-bit Buyer's Guide for a visual catalog of many of the Commodore 64 hardware expansions available today.

In this part of the guide, I focus on just four areas of expansion:

Storage Devices
JiffyDOS
RAM Expansion, and
WiFi Modems

Part II: Beyond the C64

Storage Devices

A Commodore 64 has no built-in storage. While there is a lot that you can do with a C64 without having any other devices hooked up, the most obvious benefit of a storage device is to load in software that other people have written.

In addition to software (games and programs that can be run,) storage devices also let you save data files. For many users the C64 is primarily a gaming platform, and games tend to manage their own files. But we will explore how to work with data files, including how to create them, rename, delete and copy them.

The list of storage devices available for the C64 throughout its history is long and varied. Here is but a sample of a few different kinds.

Floppy Disk Drives

Commodore made 5.25" floppy disk drives, which pioneered their file system format and the disk operating system conventions that have influenced all subsequent storage devices for Commodore 8-bit computers.

Commodore made several floppy drive models, but the 1541 was far and away the most popular. Many games and other programs were written for the 1541's hardware-specific features and it remains the standard for the distribution of most games and demos today. The .D64 file format is an image file of the track and sector data on a single 1541 disk side.

Some games and demos are so closely tied to the 1541 that they do not run correctly on other drive types. These games require an original 1541 drive or one of several modern reimplementations that are very faithful to the behavior of the original. For this reason, for games and demos in particular, any serious C64 user needs to have access to a 1541 in some form. If you don't have access to a real 1541, Pi1541 is an inexpensive cycle-exact reimplementation of a 1541 drive that comes in a number of versions. And for a more deluxe experience, the 1541 Ultimate (among many other things it can do) provides 2 cycle-exact 1541 drives. Both Pi1541 and 1541 Ultimate use .D64 files. They do not, of course, read real 5.25" floppy disks.

After several models of the 1541, Commodore also made the double-sided 5.25" 1571 disk drive, and—late in the life of the C64—they made the 800KB 3.5" 1581 disk drive. These drives support a single root directory but none of them supports subdirectories. These drives are still usable today, but mostly for nostalgia and for accessing libraries of older software you already have on disk. And of course, new commercial game releases are still made to 1541 disks and sometimes to 1581 disks too.

Creative Micro Designs made two 3.5" floppy drives, the 2MB FD-2000 and the 4MB FD-4000. The original hardware is no longer commercially available, but clones of the originals by other manufacturers are still available. Although these are floppy drives, the CMD drives behave more like mass storage devices on low-capacity removable media.

Hard Drives, SD2IEC and Mass Storage Devices

Commodore never made a hard drive for their 8-bit line of computers, but the CMD HD by Creative Micro Designs was so much like a Commodore 64 disk drive that it feels like their spiritual descendent. The CMD FD drives are a lot like the CMD HD. The main difference is that the FD's capacity per disk is much smaller, but with the advantage that the disks can easily be swapped.

The file system and the disk operating system conventions on CMD storage devices are strongly influenced by those on Commodore's floppy disk drives. But they are not—and were not intended to be—perfectly backwards compatible with Commodore's floppy drives. The advantage of a mass storage device is the ability to access single volumes of data that are much larger than a floppy disk. They also provide support for subdirectories so that files can be organized to more effectively use the larger capacity.

CMD HD

A CMD HD supports up to 255 partitions. Each partition has its own file system and blocks free count. There are 3 emulation partition types, 1541, 1571 and 1581 which emulate only the track and sector layout of those floppy disks. These partitions offer some degree of compatibility, but are not a substitute for the cycle-exact 1541 reimplementations mentioned earlier.

The true power of a CMD HD or FD comes from its native partitions. Native partitions can be up to 16MB, providing over 65000 blocks of storage in a single place. A single file can hold almost 16MB of data. By contrast, a freshly formatted 1541 disk has 664 blocks free, or around 170KB. A single CMD Native partition can store almost 100 times the quantity of data as a single 1541 disk side.

Subdirectories are only available in native partitions. 1541, 1571 or 1581 emulation partitions do not support subdirectories, as the file systems on those original drives don't either. 255 partitions at 16MB each, gives the CMD HD a maximum total capacity of approximately 4GB.

SD2IEC

Because the CMD HD and FD were created in the late 1980s early 1990s, they use many discrete components including the same 6502 CPU found in Commodore's disk drives. They also use large storage mechanisms, a 5.25" SCSI Hard Drive, and a 1.44MB 3.5" Floppy Disk Drive, respectively. These drives are comparably large and bulky as Commodore's own drives, and they are built in a very similar way.

SD2IEC is a firmware that can be installed on a family of commonplace modern microcontrollers. A microcontroller is quite inexpensive and integrates nearly all of the discrete components of a CMD HD into a single chip. This allows SD2IEC devices to be much smaller and cheaper. So small, in fact, that there are many solutions for mounting them inside the case of a C64.

SD2IEC reads the PC file system on an SD Card and transparently bridges the gaps to the file system conventions of Commodore and CMD drives. The SD2IEC firmware is open source, which has resulted in a plethora of SD2IEC-based SD Card drives of all shapes and sizes to become available for the C64.

SD Card drives are the modern replacement for both a CMD HD and a CMD FD. They offer capacities that are very large, with the convenience of swappable media, and even the ability to transfer content back and forth between a PC or Mac and a Commodore 64. Like the CMD drives, an SD Card can hold more than one partition (2 to 16 partitions can be accessed depending on the type of SD2IEC device you have.) And each partition can have a capacity of many gigabytes. Subdirectories and partitions are accessed the same way as on CMD devices.

SD2IEC does not support emulation partitions, but has the ability to mount a .D64, .D71 or .D81 disk image to the current partition. While the image is mounted, that partition takes on the behavior of a CMD emulation partition. It is very similar and more convenient in some ways. SD2IEC can also mount .DNP image files, which are image files of a CMD HD native partition.

Software compatibility on SD2IEC is slightly lower than on a CMD HD or FD, because SD2IEC does not use a genuine 6502 CPU inside.

Highspeed Mass Storage Devices

All of the storage devices discussed up to this point connect to the Commodore 64 via its standard IEC serial port. IDE64 and the CMD RAMLink on the other hand connect to the C64 via the expansion port.

The RAMLink is no longer commercially available. It uses four 4MB 30-pin RAM simms for a maximum capacity of 16MB. The contents of RAM are retained when the computer is turned off by being plugged into the wall, and has an optional battery backup too. A RAMLink supports the same partitioning system as the CMD HD and FD, but the read and write speed of a RAMLink is significantly faster.

The RAMLink also has a parallel port on the back of it, to which a CMD HD can be connected. This speeds up a CMD HD's transfer rates, as long as the software uses standard disk access routines.

IDE64 stores its data on either Compact Flash card or one or more IDE hard drives. The IDE64 also has a very fast transfer rate, due to being connected via the expansion port. IDE64 uses a custom file system, but its disk operating system conventions are highly compatible with those on CMD devices and SD2IEC.

RAMLink and IDE64 are a step below SD2IEC in terms of software compatibility, because they are not connected to the C64's serial port. However, because IDE64 has been around for almost 20 years, and is still commercially available today, many games have been fixed specifically for IDE64 compatibility.

An IDE64 is a powerful, capable drive, offering numerous other benefits to the Commodore 64. It is a bit more expensive than an SD2IEC, and a bit less compatible with existing software, but its shortcomings are made up for by its speed and other built-in tools. It is a worthy expansion for any serious Commodore 64 user.

Reading and Writing data files

Like all devices on the Commodore 64, each storage device must be assigned a unique number. The original 1541 disk drive shipped as device 8, and requires an internal hardware modification to permanently change that number. We will proceed on the assumption that your storage device is on device #8, but wherever the device number is used in the examples, know that it could be any device number from 8 to 30 depending on the number assigned to the storage device you are accessing.

To read data from a file you must first open a connection to the storage device. The connection specifies three numbers:

The logical file number. Any number from 1 to 127 used to identify this open connection.
The device number. The device number from 8 to 30 used to specify the storage device.
The secondary address. Used to specify the channel on the storage device.

Remember, the C64 has a single input channel and a single output channel, to which different open connections can be assigned, via their logical file numbers. But a storage device has its own set of channels. Each channel on a storage device can refer to a different file, and some channel numbers are reserved for special purposes. Here are the channel numbers used by all Commodore 64 storage devices.

Channel Number	Read/Write	Purpose
0	Read	Load binary data.
1	Write	Save binary data.
2 through 14	Read/Write	Transfer any data.
15	Read/Write	Send commands. Read drive status.

Let's begin with a simple case, writing some plain text to a data file. An ordinary text file on a Commodore 64 is essentially the same as an ordinary text file on a PC or a Mac. The encoding of the text is a bit different, but this only really matters when you transfer text files between a C64 and a Mac or PC.

PETSCII not ASCII

The Commodore 64 uses PETSCII, rather than ASCII. If you want to see how PETSCII is encoded see the table: PETSCII Codes

To write some text to a file we will open a connection to the device, and use the secondary address to specify the channel on the device to use. We will use a channel from 2 to 14 because those are set aside for read/write transfers for any type of data. Unlike with a printer or a modem which take a single stream of data, data on a storage device goes into or comes out of named files. Therefore it is necessary to specify the filename to which we will write the data. Try this command:

open1,8,2,"my file.txt,s,w"

The 1 is the logical file number, the 8 is the device number, the 2 is the channel number on the device. Everything in the quotation marks is sent through to the storage device as a command. The command string is sent from the computer to the disk operating system on that specific device and it is the responsibility of the device to interpret what it means. The Commodore 64 itself does not attempt to interpret the command string.

In this case, the command string consists of three parts: a filename, a file type, and a mode. The three parts are separated by commas.

The "s" file type stands for "sequential," which should be used for all files that consist of just a serialized stream of data. We will return to talk about different types of files later. The mode "w" stands for "write."

There are a few things to note about the command string:

First, there is a space between "my" and "file.txt". This is no problem, the filename will have a space in it. Unlike in the command line environments of a PC or Mac, a space in a filename is treated like any other valid character.

Second, the first comma encountered is not interpreted as part of the filename but a separator between the filename and the next part of the command. Several characters have a special meaning in the command string and either cannot be used in a filename or are best avoided. These characters are: $ , = ? and *. Colon also has a slight limitation that we'll return to later.

Third, according to the manuals, the last two parts of the command should be in the order: file type then mode. In my personal experience file type and mode seemed to work regardless of the order they come in, but this only works on certain drives. Although on a CMD HD these can be reversed without ill effect, putting them in the wrong order on an IDE64 leads to problems. Therefore, to be safe, make sure you're using them in the right order: filename, file type, mode. (i.e., my file.txt,s,w)

We now have an open connection and the device knows that the data will be written into a file called "my file.txt". Assuming a file with that name does not already exist, the device will create a file with that name and file type automatically. We can now write data to this file exactly the same way that we sent data out to a printer.

print#1,"This is some text for my file."

Repeatedly calling the print# command, using the logical file number of our open connection, will add new text to the end of the file. Remember that the print and print# commands both automatically append a carriage return to the content. Those carriage returns are written to the file and will cause each string to be on a separate line. Just as with the printer, use a semi-colon at the end of the line to prevent the automatic output of a carriage return. Like this:

print#1,"This is some text ";
print#1,"for my file."

The semi-colon at the end of the first line above prevents the automatic carriage return and the file gets a single line like this:

This is some text for my file.

Routing the output channel to a file

Just as we were able to redirect the C64's output channel so that a BASIC listing goes to a printer or a modem, we can also redirect the output channel to an open file. In fact, once a file has been opened for write, it works precisely the same way.

cmd1
list
print#1

The cmd1 temporarily redirects the C64's output channel to the open connection of logical file 1. The list command then sends the BASIC listing into the open file on the storage device. And finally the print#1 redirects the C64's output channel back to the screen. You can repeat this multiple times before finally closing the file.

Speaking of which…

Always remember to close your open files

Remember, when you're finished writing to the file you have to close the connection. It's just close followed by the logical file number of the connection.

close1

If the storage device gets restarted or reset and it had an improperly closed file this can lead to problems. There is a way to correct this problem, called validation. But you're much better off preventing the situation in the first place. So always remember to close your open files, but especially ones opened for write.

Imagine that the computer crashes or gets reset, but the drive has not been restarted, and the drive still has a file open. You can tell that a file is open, if the drive's standard green activity LED is on. In this situation the drive got the message to open a file, but because the computer has lost its table in memory that associates logical file numbers to open device connections it is no longer possible to use the close command to close that file.

Here's a helpful tip. This is a way to safely close all the open files on a device.

close1:open1,8,15:close1

The drive's channel 15 is used to send it commands and to read drive status, two things that we will return to later. But a side behavior of closing a connection to the drive's command channel is that the drive automatically closes all of its own open files. After you open and close a connection to channel 15, the drive's green activity LED should turn off. Very handy.

What if a file already exists?

What can we do if a file already exists with a filename that we want to use? There are several options, but here I'll mention two. You can overwrite the file, effectively deleting the original in the process of opening it again. Or you can open the existing file such that new data will be appended to the existing data.

Appending to an existing file

Let's start with append, because it's the easiest. You can simply change the mode from "w" for "write" to "a" for "append." Like this:

open1,8,2,"my file.txt,s,a"

Note that in order to open for append the specified file must already exist. Otherwise, the drive will produce a FILE NOT FOUND error. That's all there is to it. The existing file will be opened again and subsequent print# commands will add new data to the end of the existing data. This is very handy for many situations.

Here's another tip: If you are in a program that writes out textual or sequential data, and it asks you for a filename, you can very often add the extra ",a" to the end of the filename and the program will append its output to the existing file without even realizing that that's what it's doing. You need to be careful when doing stuff like this, but knowing about it can add an extra dimension of control you might not have even realized was possible.

Replacing or overwriting a file

An alternative to appending data is to overwrite or replace an existing file. To do this we have to introduce a new segment of the command string. Special commands and instructions may precede the filename in the command string, the commands and the filename segment are separated by a colon, like this:

commands:filename,filetype,mode

The part preceding the filename is optional. But if you need to issue one of these special commands or instructions, you can put them in and then end the commands section with a colon followed by the filename. The command to replace an existing file is @.

open1,8,2,"@:my file.txt,s,w"
print#1,"This is now the only content in the file"
close1

Unlike the append mode, which can only be used if the file already exists, you can use the @ command even if the file does not already exist. If it doesn't exist, everything proceeds as normal. But if it does exist, the original is replaced.

There are a few things to point out here. First, recall that I said a colon can be used in a filename, but it has some limitations. Because the colon is interpreted in the command string as separating the commands from the filename, you can only use a colon in a filename if you have already used a colon to separate commands from the filename. Why is that? Because the first colon encountered is interpreted as separating commands from filename. Therefore only the part following the first colon is considered part of the filename. Let's take the following two examples to illustrate how this works:

open1,8,2,"my :file.txt,s,w"

In the above command string, "my " will be interpreted as special commands, they won't be recognized as anything and will likely be ignored. The actual filename will be just "file.txt". Compare this with the next example:

open1,8,2,":my :file.txt,s,w"

Here, the first encountered colon splits the commands from the filename. As it happens there are no commands in the command section, but that doesn't cause any problems as the commands are optional. The presence of the initial colon, though, causes the second colon to simply be incorporated as any character into the filename.

Although this does work, frankly, I recommend you avoid using colons in filenames.

The @ Replace Bug

The Commodore 64 user who has been around the block will recall that the disk operating system version found on some devices has a bug in the @ replace command. In order to understand the bug we need another concept, the drive number or unit number.

Before the well known Commodore 1541 disk drive, Commodore had a series of dual disk drive devices, such as the CBM 2040, CBM 3040 or the CBM 4040. These present themselves as a single device to the computer, but internally house more than one disk drive mechanism. The device's processor, memory and disk operating system can access data on either mechanism so the command string needs a way to indicate which one to use.

The two drive mechanisms are 0 and 1. Single drive devices, like the 1541 and 1571, use drive 0 by default. However, a bug exists on the 1541. A command that looks for a file by name starts on drive 0, but if not found the internal default drive number gets changed to 1. After this has happened, subsequent uses of the @ replace command could result in corruption of other files on the disk, and corruption of the disk's block allocation map.

Therefore, to avoid the bug on the 1541 specifically, if you ever use the @ replace command all commands issued should specify the drive (0:). Here are some examples:

load"0:my file",8
open1,8,2,"0:my file.txt,s,r"

Later versions of the CBM disk operating system, including the DOS found on CMD devices, IDE64, and SD2IEC, as well as the JiffyDOS 1541 drive ROM replacement, no longer have this bug. So, whether you specify the drive number as a matter of habit depends on whether you worry that one day you might be bitten by this bug when you try to use @ replace on a 1541. I usually omit it, because I am rarely doing serious work on a stock 1541. But it's a rite of passage that Commodore 64 users learn about this.

File Management

Once you start to have a few files collecting on a disk, it becomes necessary to manage those files. File management usually consists of a few standard operations:

List a directory
Delete a file
Rename a file
Copy a file
Move a file

Commodore's own disk drives, 1541, 1571 and 1581 do not support subdirectories on a disk. Each disk has just a single root directory in which all the files on that disk are listed. All of the above management operations apply to only a single directory, with the exception of moving a file. Here we can think of this as moving a file from one disk to another.

IDE64, SD2IEC and CMD's devices all support partitions and subdirectories within partitions. We'll come to those next, in extended file management.

List a Directory

The universal way to request a directory listing from a Commodore storage device is with the dollar sign, ($). The dollar sign is a special pseudo-file that can be loaded from a storage device. The result is structured like a BASIC program.

Recall that the different channels mean different things to a storage device. A directory can only be read via channel 0, the device's channel dedicated to loading programs. Even if you write a program that opens a connection and reads the directory one byte at a time, you still have to use the device's channel 0, otherwise it gets a FILE NOT FOUND error.

The easiest way to get a directory is to use the BASIC load command. Like this:

load"$",8

Because the directory is loaded into memory in the form of a BASIC program, this will, unfortunately, blow away any other BASIC program already in memory. How to improve upon this situation is discussed later, in the section DOS Wedge and JiffyDOS. Another effect of being structured as a program is that to see the directory you use the list command.

Loading and listing a directory on a disk.

Structure of a Directory

The first character on the first line is a number. On floppy disk drives this is the drive mechanism or unit number. On a 1541, 1571 or 1581, which are single unit drives, this number is always 0. On devices that support partitions, this is the partition number.

The remainder of the first line is shown in reverse text. The title of the directory is in quotes. This may seem strange to users of modern Macs and PCs, but on CBM floppy drives each disk has a title, assigned when the disk is formatted. Special utilities can change the title of a disk without reformatting it. IDE64 and CMD devices have a title per subdirectory, but SD2IEC is a bit different because it is based on a PC file system.

Four characters follow the directory title. The first two are the disk's ID, and are assigned when the disk undergoes a full format. The ID can be used in any way you want, usually for cataloging purposes. Some multi-disk software uses the ID to confirm that you have inserted the correct one when it asks you to swap disks. The final two bytes indicate the DOS format code of the disk. In theory this would allow newer drives with new features to know what features are supported by an older disk.

Following the title line are a series of directory entries, one per row. The leftmost column shows the file sizes measured in blocks. This is a convention that is probably unfamiliar to new C64 users. A block on a Commodore disk drive is 256 bytes, but in most file types only 254 bytes per block can be used for data storage. Therefore, to compute the approximate size of a file in kilobytes you can divide the blocks by 4. Or, to get an approximate size in bytes, you can multiply the blocks by 254. Thus, 52 blocks is ~13KB or around 13,208B. Usually slightly less as the final block of storage is likely only partially used.

The filename appears in the middle column in quotation marks. Filenames are 1 to 16 characters long and the valid characters and format of the name are very liberal. A filename can use an extension but an extension is not required. And an extension can be any number of characters. The only characters that should be avoided in filenames are those that interfere specifically with DOS commands. ($ , = ? * :) Even these special characters can sometimes be used in filenames with some workarounds.

The rightmost column shows the file's file type, which we briefly encountered earlier. A file type is not to be confused with a data type. The file type refers to how the file is laid out on the disk. Although there is a theoretically unlimited number of possible data types, there are only 4 main file types.

File Types

File types sometimes confuse new or inexperienced Commodore 64 users because they have no direct equivalent on a Mac or PC, but they're not too complicated. The most common file type used on the C64 is PRG. The next most commonly used are SEQ and USR. And the least common is REL. These stand for:

File Type	Meaning
PRG	Program
SEQ	Sequential
USR	User Defined
REL	Relative

PRG Files for Programs

A PRG file is so-called because it is typically used for an executable program. The C64's build-in operating system does not do any fancy code relocation. Although BASIC programs are more flexible because their code is interpreted, programs written in assembly language are assembled to start at a very specific address in memory. In order to get a program to load into the right place in memory, a PRG file's first 2 bytes are its start address.

There are two main ways to read in a file on the Commodore 64. You can use the open command, followed by repeated get# or input# commands. If you do this, in other words, if you treat a PRG file like any other data file, you find that the first 2 bytes are not program code, but the program's 2-byte start address.

The other way to read in a file is using the load command. The load command implicitly opens the connection to the device using channel 0. Storage devices dedicate channel 0 for loading PRG files. The load command reads in the first 2 bytes and uses them to determine the start address. The load command then proceeds to read in all the remaining bytes, automatically storing them in memory from the start address onward.

The DOS on the drive also puts two and two together. While there is no problem opening a PRG type file (with the open command) on one of the data channels, it will only allow you to open a file on channel 0 if the file is PRG type. It knows that channel 0 is used by the load command, and it knows that the load command expects the first 2 bytes to be a start address, so if the file requested on channel 0 is not PRG type, the drive produces a FILE TYPE MISMATCH error.

SEQ Files and Data Files

A SEQ file contains any kind of data that is sequentially stored. On traditional Commodore file systems, such as on 1541, 1571, 1581 and the CMD devices, you cannot seek backwards or forwards arbitrary distances through a sequential file, you can only read through them going forwards and starting from the beginning. On the C64, that is why other file types exist. Other files types are used if this or some other kind of advanced functionality is required.

On modern computers all files are sequential. But the file systems allow you to fast seek forwards or backwards to any point in the file, which obviates the need for other file types.

SD2IEC and IDE64

SD2IEC, because it is based on a PC file system, and IDE64, because it has a custom but more modern file system than is found on other C64 storage devices, both support fast seeking through PRG files and SEQ files.

On the C64, many kinds of data files are actually packaged as programs. A lot of graphic files have the viewer program built in. A lot of SID music is packaged up as a program you load and run to listen to. This is often taken one step further. The video chip can only display bitmap data from a few large sections of main memory. Therefore, even when graphics are distributed as only their data—such as in Koala format or Art Studio format—it makes little sense for the viewer program to load graphic data into one place in memory only to immediately move it to where the video chip can display it. For this reason, some files that are truly only data (such as Koala graphics) are still packaged in a PRG type file. The 2-byte start address is used to put the data into the right spot in memory, even though that data is not a runnable program.

All other types of data files, though, especially ones that are foreign but could still be usefully used on the C64, such as a .TXT, .WAV or .GIF file, should be SEQ type files. They are just a sequence of bytes of data.

USR Files and Custom Formats

USR stands for user defined. These files could be in any format. But what does that mean? Aren't regular data files in different formats? This is the difference between a file type and a data type. On a PC, although the interpretation of the data is different for each different type of data file, the file itself is structured like a sequential stream of bytes. On the Commodore 64, a USR type file could be structured non-sequentially. An explanation is in order.

The most common USR files on the C64 are created by GEOS. GEOS defines a special file type format called VLIR (variable length index record). Roughly speaking, the first block of data contains metadata about the file, and sequentially links to the second block. Rather than the second block sequentially linking to the third and then the third to the fourth and so on, the second block consists of a table of pointers to the first blocks of upto 127 sequentially linked chains. In other words, the way a VLIR file links its blocks together on the disk is structured like a tree, instead of like a chain.

The Commodore file system uses the USR file type to indicate that the structure of this file is custom. This is exactly why GEOS VLIR files are USR files. It is impossible for a standard or generic file copying program to reliably copy a USR file, because there is no way for a generic copier to know how the blocks are linked together for a given USR file. Not all USR files are structured like a GEOS VLIR file, a USR file could be structured in any imaginable way. It is safest for a generic file copier to skip over USR files.

REL Files and Tree Structures

The REL file type is fairly uncommon. It stands for Relative. The data in a relative file is not stored as a sequence or chain of data blocks. Somewhat more like GEOS VLIR files, relative files have a tree-like structure. When a relative file is created a record size must be specified. Records can be added later, and records within the file can be accessed much more quickly than would be possible with a sequential file.

Relative files are useful for certain types of database programs, and they have the advantage of having a standard structure supported by CBM DOS, CMD DOS, IDE64 and also partially supported by SD2IEC. Due to the standard structure, generic file copiers can be written with support for copying relative files, though many do not in fact have support for them.

DEL Files

Lastly, it is worth mentioning that in some directories, especially on disks for games or demos, the DEL file type shows up.

DEL stands for deleted. There are no DOS commands you can use to create a DEL file, they can only be created using special utilities. These "files" have a size of 0 blocks, and are usually used as organizational spacers in directory listings. Sometimes people get creative and make directory artwork in the filenames of several DEL files that appear one after the next.

The Command Channel

We saw earlier that all storage devices (except the cassette drive) support 16 channels (0 to 15). 0 and 1 are special purpose, for loading and saving PRG type files, or for loading a directory which is structured like a BASIC program. 2 to 14 are general input/output channels used for reading and writing data files. That leaves the last channel. Channel 15 is special and is called the command channel.

Open the Command Channel

You can open a connection to the device using the open command, assigning a logical file number to the connection as usual, but using channel 15 on the device. Data that you write to that connection is not going into a file on the device, but instead are commands sent to the DOS (the drive's own operating system) on the device. When you read data from a connection to channel 15 you are not reading data from a file, but are instead getting the response to a previously issued command, or reading the device's status message.

If you are going to perform numerous file management tasks, you only need to open the command channel once. You can leave it open, send multiple commands and close it at the end. Here's how to open a connection to the command channel:

open1,8,15

Pretty easy. We have a logical file number of 1, which we can use now to send commands to device 8's command channel (15). In all of the following examples, it is assumed that logical file 1 has already been opened to the command channel of the storage device to which we are sending the command.

Delete Scratch a File

Once you start creating some new files, and can see the files that are collecting in a directory, you are soon going to want to get rid of some of them. The terminology for getting rid of a file varies from computer to computer. Unix and Linux use "rm" which is short for remove. The Mac has always had the concept of moving the file to the trash bin, and later emptying the trash. MS DOS and Amiga DOS use a delete command. And Windows has a sort of mashup between putting a file in a the recycle bin, but when you go to empty the recycle bin it asks if you're sure you want to delete the files.

The Commodore 64, like other Commodore 8-bit computers, uses the word scratch to mean erase/delete a file from a storage device. To scratch a file you send a scratch command to the device's command channel.

The scratch command is the letter "s". The command is separated from the filename by a colon (:), like this:

s:somefilename

Of course, this command string has to be send to the device's command channel. Like this:

print#1,"s:somefilename"

Rename a File

Another common file management task is to change the name of an existing file.

In the command line interfaces of modern computers, the typical order when using a rename command goes: command oldname newname. CBM DOS is a bit different, it uses an equals sign between the names, which feels inspired by the syntax to set a variable in a program. When you set a variable, you do something like this: a = 5 or b$ = "hello". The new thing you are creating, the variable name, is on the left of the equals and its value is on the right. The CBM DOS rename command is like that. All the other C64 storage devices are consistent and compatible, and thus use the same structure which was pioneered by Commodore for their earliest disk drives in the late 1970s.

r:newname=oldname

The "r" is the rename command. The colon (:) separates the command from the filenames, and the equals sign (=) separates the two filenames. In the style of setting a variable, the file being created comes on the left and its value, the old file, follows the equals sign. This command string has to be sent to the device's command channel, of course, like this:

print#1,"r:newname=oldname"

Copy a file

We know how to scratch a file and we can give an existing file a new name. But before we change a file's contents—potentially messing it up—perhaps we want to make a copy of it first. The copy command is very similar to the rename command. After a rename command the old filename no longer exists, but after a copy the new filename and the old filename both exist.

c:newfile=existingfile

The "c" is the copy command. The colon (:) separates the command from the filenames, and the equals sign (=) separates the two filenames. Just like when renaming, the new file being created comes first, set equal to the value of the existing file. The existing file's filename comes after the equals sign. This command string is, as always, sent to the device's command channel.

print#1,"c:newfile=existingfile"

File concatenation

There's an extra little trick to the copy command which can come in very handy. When creating a new file with the copy command you can specify multiple existing files. Each one is concatenated, combined together one after the next, into the new file. Obviously it doesn't make any sense to do this with program files, but it makes sense for text files and could make sense for other types of sequential data files.

The syntax of the copy command is almost identical, but following the equals sign multiple files can be listed separated by commas. Recall that comma is a reserved DOS character that cannot be used in filenames. Like this:

c:newfile=existingfile1,existingfile2,existingfile3

How many files can combined using a single command depends on the device. Typically at least 5 files can be concatenated in this way, but I believe the limiting factor is how big the command string buffer is in the drive. If you really need to concatenate more than 5 files together, you can do it in several steps.

print#1,"c:newfile=existingfile1,existingfile2,existingfile3"

Move a file

Finally we come to moving a file. A 1541, 1571 or 1581 disk only has a single directory, no subdirectories. Therefore a copy command makes a copy of a file within that directory. What would it mean to move a file?

On an IDE64, an SD2IEC or a CMD device there are subdirectories and multiple partitions. Moving a file is therefore the act of copying a file from one directory or partition to another, and scratching the original. This is explored further in extended file management, where subdirectories and partitions are discussed.

On floppy disks that don't support subdirectories, though, moving a file still makes sense. You might move a file from one disk to a different disk. This therefore is the act of copying a file to a new disk and scratching the original. But here we run into a problem. Before now, a copy command was sent to a single device, and that device used its internal hardware to duplicate a file from one spot on the medium to another spot on the same medium. Besides sending the copy command, the C64 is not really involved in this process. To copy a file from one disk to another, the data has to be read into the C64 and then written out to a different disk, therefore the computer is definitely involved.

There is another complication. In the old days a floppy drive was an expensive investment. Most users didn't have two floppy drives. Today it's much more common to have two drives. You might have two floppy drives, or you might have one floppy drive plus some other drive like an SD2IEC or IDE64. How to copy a file from place to place therefore depends greatly on what hardware you have. On top of all that, the C64 does not have file copy software built in. You need to acquire a file copying program. An alternative solution to this problem is discuseed later in the DOS Wedge and JiffyDOS section of this guide.

1) If you have only a single floppy drive, to copy a file between disks you need a file copying program that supports disk swapping. The basic idea is that it asks for the source disk, you insert that. It reads a bunch of data into memory, then asks for the destination disk. You pull the source disk and insert the destination disk into the same drive. It then writes all the data from memory out to the new disk. This process of swapping is repeated as many times as necessary to copy the files.

2) If you have two floppy drives, the process can be greatly accelerated by using a file copying program that supports two drives. You put the source disk in one and the destination disk in another, and the program reads data into memory from one device, then writes from memory out to the other device, and repeats this as many times as necessary. It's much faster because you don't have to manually swap disks between each pass.

3) Another scenario exists. You may have one floppy drive and some other mass storage device like an IDE64, SD2IEC or CMD device, but, what you want to do is copy files between two floppy disks. In this situation, you could ignore your mass storage device and do the manual disk swapping, but that's pretty labor intensive, not to mention it puts wear and tear on the disks and the drives. You could alternatively use a two drive copier to copy all the files from a disk to a directory on the mass storage device. Then swap to the destination disk once, and do the full two drive copy again from the mass storage device out to the new disk. It's a bit slower than floppy drive to floppy drive, because the data has to be fully copied twice, but it's a lot easier than manually swapping disks with each pass.

In the history of the Commdore 64 there have been innumerable file copying programs. This guide cannot list them all. CMD shipped their storage devices with a useful two drive file copier called fcopy. Unfortunately fcopy does not work nicely with SD2IEC. IDE64 has a built-in two drive file copier. Another good option is DraCopy. It's a simple two drive file copier, with support for SD2IEC. It's open source and can be downloaded here.

DraCopy two drive file copier.

That summarizes the most essential aspects of file management when you work with just floppy drives or the most basic features of mass storage devices on your Commodore 64.

There are, of course, many more tricks and techniques and there are additional more advanced commands. There are also many commands that pertain to partitions and subdirectories on mass storage devices. These topics are covered next, in extended file management.

For further reading about DOS commands and features available to disk drives, these two user's guides are a useful start:

1541-II Disk Drive User's Guide

1581 Disk Drive User's Guide

Extended File Management

In the late commercial life of the C64 only serious power users invested in a mass storage device, such as a CMD HD or RAMLink. People who only used the C64 as a gaming platform had little reason to shell out the money for mass storage, when almost all games shipped on either tape, cartridge or 1541 floppy disk.

Today it's different. An SD2IEC or an IDE64 is much less expensive than a CMD HD or RAMLink was in the early 1990s. Plus, these newer devices make it easy to transfer data between a PC or Mac and your Commodore 64. And maybe now that we're not kids anymore, we have more disposable income to spend on our favorite home computer. In any case, it is easier than ever for a Commodore 64 user today to have access to a mass storage device.

About 1541 Ultimate and Ultimate 64

The 1541 Ultimate and Ultimate 64 also let you plug a mass storage device into your C64, via USB, but these are different. The "mass storage" aspect is in the backend, and they present themselves to the C64 in the form of a 1541 disk drive, with a mounted .D64 image.

There has been some effort made to grant the C64 native access to the mass storage of a 1541 Ultimate and Ultimate 64, but this support remains incomplete and compatiblity with C64 file systems and DOS standards is poor. Although, this may change in the future.

For a more detailed explanation of the 1541 Ultimate, consider reading this review.

Why Have Partitions on a C64 Mass Storage Device?

Partitions are not uncommon on PCs and Macs, although in macOS partitions are usually referred to as volumes. For several reasons, a single hard drive can be divided into multiple logical drives. Sometimes the operating system is installed on one partition and another is used only for data. That way, if anything goes wrong with your Windows installation, for instance, you can reformat that partition and reinstall Windows without losing your data.

There are other reasons to partition a hard drive. Sometimes the partitions have different file systems, different encryption or security features, and in some cases an older file system may have had an upper size limit smaller than the total capacity of the drive. For example, FAT16 under MS-DOS, Windows 95 or Windows 98, has a maximum partition size of 2GB. But if you have an 8GB drive the only way for FAT16 to use the full space is to create 4 partitions.

All of these (with the exception maybe of encryption) are the same reasons for multiple partitions on a Commodore 64 mass storage device. On a CMD HD you might create some partitions with a 1541, 1571 or 1581 file system for software that requires one of those track and sector layouts. And CMD native partitions, despite being newer retain some file system features that limit their maximum capacity to just 16MB. The first CMD HDs were fairly small, just 20 and 40MB. That's enough for one or two native partitions and a few emulation partitions to fill the remaining space.

Multiple partitions also increases your data security. If one partition becomes irreparably corrupt, the data in other partitions is unaffected. If you install an operating system in one partition and data in another, you can format and install a new operating system in one partition without affecting the others, and so on. All CMD devices, as well as the SD media used with SD2IEC devices, and hard drives and CF cards used on IDE64, these can all be partitioned.

List a Partition Directory

As soon as you have more than one file on a disk you want to be able to list a directory to see what's there. The same is true for partitions. As soon as a device has more than one partition, it would be handy to see a list of them.

Loading the partition directory is nearly the same as loading a regular directory but with an extra parameter added like this:

$=p

Just like an ordinary directory the partition directory can only be read from channel 0 of a device. And the easiest way is with the load command. Load implicitly uses channel 0, and the partition directory is again returned in the structure of a BASIC program, which must be listed to view it.

load"$=p",8
list

Loading and listing a partition directory on an SD2IEC.

Down the left side, instead of these numbers being file sizes, in the partition directory they are the partition numbers. Each partition can be given a name which appears in quotes, and the right side shows the partition type. On CMD devices and SD2IEC, NAT stands for native. The equivalent of a native partition on IDE64 is CFS.

Change Current Partition

The Commodore 64 itself doesn't have a concept of directories or partitions, which is why directories are returned as BASIC programs. The C64 does not have a disk operating system at all. Each individual device comes with its own disk operating system. The C64 sends DOS commands to the device via its command channel, and the device knows how to interpret those commands. Let's open a connection to device 8's command channel first.

open1,8,15

The mass storage devices have a built-in property that stores the currently selected partition. When you load a regular directory, you don't need to specify the partition. The device gives you the directory from its current partition. You can tell the device to change the current partition with the "cp" command followed by the partition number.

cp5

The change partition command has to be sent the device's command channel, like this:

print#1,"cp5"

Creating and removing partitions requires special tools. CMD devices came packaged with tools on 1541 disk for managing partitions and other low-level device features. IDE64 comes with tools on disk, as well as having some configuration tools built into its firmware. Because SD2IEC uses a PC-based file system, it is possible (and also necessary) to use a Mac or PC to manage the partitions on an SD Card. Otherwise, SD Cards ship with a single partition and file system that is ready to be used on your C64.

Most SD2IEC devices are only able to see and access the first 2 partitions on an SD Card. But some, such as uIEC/SD from Retro Innovations, are able to see the first 15 or 16 partitions.

Change Current Directory

Unlike CBM's floppy disk drives, the native partitions on CMD devices, SD2IEC and IDE64 all support nested subdirectories. These are just as you would find them on an Amiga, Mac or PC, but the path format is unique.

Just as the devices remember the current partition, the devices remember the current directory, too. What's more, each partition has its own current directory. This is very handy for working with files across partitions. The change directory command is "cd", followed by an absolute path, a relative path, a parent directory relative path, or the name of a subdirectory that is in the current directory. Let's look at the format of a path. The format is the same on CMD devices, SD2IEC and IDE64.

The root directory is specified with two slashes:

//

The current directory is specified with one slash:

Every path must begin either with the root directory (//) or the current directory (/). Each subdirectory is then added to that by specifying the name of the directory followed by one trailing slash. The trailing slash is optional only when not followed by anything else in the command string, otherwise it is required.

somedirectory/

These parts are then combined and follow the "cd" command immediately with no space. Here are some examples.

cd//full/directory/path/
cd/relative/directory/
cd//

The parent directory relative path is the back arrow (←) found at the top left of the C64's keyboard. But, unfortunately, unlike ".." on modern command line interfaces, it cannot be combined with other relative paths. The following command takes you to the parent directory of the current directory.

cd←

There is one alternative way to change into a directory, by specifying the directory name in the filename section of the command, following the colon that separates the command section from the filename section. Like this:

cd:subdirectory

With the above method, only a single directory name can be given following the colon, and no slashes are used. The directory name specified must be found within the current directory. Remember that all of these commands must be sent to the device via its command channel. Like this:

print#1,"cd//full/directory/path/"

Make a subdirectory

You can make a subdirectory within the current directory using the "md" command, which stands for make directory. The syntax is very straightforward, first the command, then a colon (:) and then the name of the directory immediately following the colon.

md:newdirectory

print#1,"md:newdirectory"

A subdirectory in a directory listing appears with the DIR file type.

Most of the same rules for filenames also apply to subdirectory names. However, while it is possible to use a slash (/) in a filename without any side-effects, a slash in a subdirectory name leads to problems. If a subdirectory has a slash in it, it can only be changed into if its name follows the colon (:). It cannot be used in a path. Therefore, slash in a subdirectory name, while possible, should be avoided.

Rename a subdirectory

Renaming a subdirectory is precisely the same syntax as renaming a file.

r:newdirectory=olddirectory

print#1,"r:newdirectory=olddirectory"

Remove a subdirectory

Just as surely as you want to scratch a file from a directory, after you create a few subdirectories you will soon want to get rid of some of them. The command to remove a subdirectory is "rd", followed by a colon, and then the name of the subdirectory to remove, found in the current directory. It's a lot like scratch, except that scratch can't be used on a directory, and rd can't be used on a regular file.

rd:nameofdirectory

print#1,"rd:nameofdirectory"

There is a catch though. Unlike on modern command line interfaces, none of the DOS's (not on SD2IEC, IDE64 or CMD devices) supports recursively removing subdirectories and the files therein. This is definitely a shortcoming of file management from the READY prompt. If you have a large tree of subdirectories containing many files, manually removing the whole tree becomes quite labor intensive.

Most file management programs for the Commodore 64, such as the aforementioned fcopy and DraCopy, although they support removing directories and scratching files, they do not support doing so recursively. Recursive scratching, copying and moving is a feature of C64 OS, however. And that is one of its strengths, making it a very useful and powerful tool for users who want to do serious file management on their C64.

Combining Paths with Commands

Up until this point, all of the file management options, both standard and extended, have been shown relative to the current partition and the current directory. They were introduced this way for simplicity's sake. However, in all of these commands a partition number and path can be used to override or relatively extend the current partition and path.

In the string sent to the device's command channel, the command comes first and that section is ended when the colon (:) is encountered. Following the colon comes a filename. A partition and path can be included before the colon. Here are some examples, with the full BASIC line included. The print#1 lines assume that the command channel has already been opened, with logical file 1.

load"3:somefile",8
load"3//:somefile",8
print#1,"s3//some/path/:somefile"
print#1,"cd3/path/"
open2,2,8,"@3//some/path/:filename,s,w"

This usually works. There are a couple of rare exceptions. For example, you cannot remove a directory at the end of a path. You must be in the current directory to remove one of its subdirectories. But for almost all other commands you can specify the partition number and a full path or a relative path (relative to the current directory of that partition) before the colon (:) in the command string.

It is not necessary to specify both. You can leave off the partition number and only specify a path, and it will use the current partition. Or you can leave out the path but specify a partition and it will use the current directory of the specified partition. Notice in the examples above, that these paths are not only for commands sent over the command channel. A path can be used when loading a file with the load command, or opening a file for read or write using the open command.

Some commands, such as renaming a file or copying a file, take two filenames separated by an equals sign. The colon (:) before the first filename can be preceeded with a path. But what's more is that you can also add a path to the second filename. Following the equals sign, start with a path, then another colon (:) to separate that path from that filename. Like this:

print#1,"c1//tools/:sometool=2//programs/:someprogram"

The above command copies a file called "someprogram" in the //programs/ directory of partition 2, into the //tools/ directory of partition 1, and also assigns the copied file the new name "sometool". That's pretty great. If you omit a path from part of the command, but include a partition, the copy either comes from or goes to the current path within the specified partition.

This command structure takes a bit to wrap your head around, but it provides a lot of flexibility for moving around the file system.

Remember also that, the path is part of the command string that is sent from the C64—typically without any interpretation or modification—directly to the storage device. Therefore, in a program that asks you to type in a filename, you can often include a path like this:

4//:myfile.txt

And the program will not know the difference between this being a plain filename or a filename with a path. The only unfortunate catch is that many programs, assuming that a filename can only be 16 characters long, limit your path and filename reference combined to just 16 characters. Nonetheless, it's nice to know that you can try this, to see if it works.

DOS Wedge and JiffyDOS

Although the Commodore 64 is usable without any storage devices, it came at the beginning of a long road of home computer development. Over time, the fraction of all computer users who program has shrunk, and the fraction who use only prepackaged commercial software has grown.

The software built into the C64 via its ROM chips do not provide disk operating system features, because the disk operating systems are part of the storage devices themselves. This makes the Commodore 64 more like a messaging center at the hub of a small network of desktop peripherals: printers, modems and disk drives. It's a pretty cool design, and quite sensible. But considering that commercial software was on the rise, the C64's use of BASIC commands—open a channel and print command strings to the channel—is quite verbose and cumbersome.

The C64 treats modems, printers, disk drives and hard drives all as roughly equal peers. But in the experience of most users they are not at all peers. A printer is usually used from software that offers a print feature. Without that, most users never touch the printer. Similarly with a modem, a user typically gets some terminal software to connect to a BBS, or they used QuantumLink. But rarely does a user manually open a connection to a modem. Meanwhile, the typical user accesses a disk drive or hard drive constantly. Loading files, saving files, renaming files so they're better organized, or scratching old files they don't care about. These are all very common everyday tasks.

Even Commodore knew this, and as early as 1982 when the 1541 disk drive was released, a program called DOS Wedge was included on the Test/Demo disk that shipped with the drive. This DOS Wedge has to be manually loaded, and puts a small assembly program way up in an area of memory not typically used by the C64's own operating system. It's called a wedge because it does not implement a disk operating system, instead it extends BASIC by adding 6 or 7 single character commands. Each command provides a shortcut for communicating with a storage device, without changing anything fundamentally about how the computer and the storage device work together.

The @ Command

Without a doubt the most useful is the "@" command. A string following the @ sign, even without quotes, is sent to the device's channel 15, the command channel. To scratch a file, the full BASIC syntax is:

open1,8,15:print#1,"s:filename":close1

But when the DOS Wedge is installed that gets reduced to just this:

@s:filename

That's a huge improvement. To be fair, opening and closing the connection to channel 15 does not need to be done before and after each and every command. Nevertheless, the @ command can be used without needing to explicitly open or close channel 15.

Notice also that in the @ command no device number needs to be specified. By default device 8 is used.

The @ Directory

The @ command has a special feature for listing directories. If a dollar sign ($) is the first character of the command string, rather than send it to channel 15 it sends it to channel 0 just as the load command does. Rather than load the result into memory, the result is interpreted and printed immediately to the screen.

@$

When the load command is used the directory replaces the current BASIC program in memory. This is often not ideal, because if you just wrote a BASIC program and want to save it to disk, you can't load a directory to see what filenames are available. With the @ directory command you can view a directory at any time without overwriting your BASIC program. This is a huge usability improvement.

There are several other handy commands that make it easier to load, save and verify programs, check the drive's status, and more.

Speedloaders and the DOS Wedge Standard

The main problem with the original DOS Wedge is that it isn't built in. You have to load it into memory each time the computer is turned on. If you only have one disk drive you either have to put a copy of the DOS Wedge onto many different work disks, or you have to put a disk in that has the DOS Wedge first, and swap disks before you get started. There is also the risk that some program you load will overwrite the memory where the DOS Wedge is installed.

Another big problem for the Commodore 64 is that the serial bus protocol that shipped with a C64 is notoriously slow. Loading a PRG file from a 1541 has a transfer rate of around 430 bytes per second. Loading a large program could therefore take over 2 minutes to complete. Why exactly it is so slow is rather technical, but it turns out that it didn't need to be as slow as the way it shipped. Every C64 that shipped after that works the same as the original, and has retained its very slow stock speed.

This opened the door for a cottage industry of fastloader solutions, in the form of plugin cartridges that patch and augment the built-in software. Some popular speedloading cartridges include:

Action Replay, EPYX FastLoad, and Super Snapshot

Cartridges such as these provide other features, but speeding up the IEC serial bus is a big part of why they exist. These also include a DOS Wedge which is clearly inspired by the original. They use mostly the same set of single character commands, and thus the original DOS Wedge established a de facto standard that users can generally use with many different fastloading solutions.

What is JiffyDOS?

Here's how JiffyDOS is described by RETRO Innovations, its main licensed reseller:

JiffyDOS is a Disk Operating System (DOS) enhancement which gives your C64 or C128 the disk access speed it has always needed. A chip-for-chip replacement for the Kernal ROM in your computer and the DOS ROM in your disk drive(s), JiffyDOS achieves levels of performance and compatibility unmatched by other disk speed enhancement products.

Outstanding speed, solid compatibility with virtually all hardware and software, and a new set of desperately needed commands and features, gives your system a new lease on life and the power to compete with today’s newer, more expensive machines. RETRO Innovations — JiffyDOS Product Page

The final line about power to compete with today's machines is a delightful look into the past. At one point in time, perhaps in the late 80s, a stock C64 was perilously slower than machines of that era. Adding JiffyDOS was an inexpensive way to dramatically boost the disk access speed of a computer you already owned and make it more competitive.

There are so many disk speed enhancing options for the C64, how is one different than any other? Some of the alternatives are less expensive than JiffyDOS, some are easier to install—just plug in a cartridge—and some of them are actually faster. Well, if that's true, then why do I recommend JiffyDOS?

It's right there in the description of the product, but it's easy to overlook. JiffyDOS achieves a level of "performance and compatibility" unmatched by other products, as well as adding some desperately needed features.

JiffyDOS is not overwhelmingly difficult to install, but it requires more than just plugging in a cartridge. The instructions are clear and easy to follow, but you have to open the computer and locate the KERNAL ROM. Then you pull out the old KERNAL ROM and put the new JiffyDOS KERNAL ROM in its place. (Unfortunately, on many C64c mainboards the KERNAL ROM is not in a socket, this adds some complication.)

Part of the reason why JiffyDOS is a bit more costly is that it isn't enough to replace only the KERNAL ROM in the computer. In order for a drive to benefit from enhanced speed the drive must also support the JiffyDOS protocol. The SD2IEC devices, as well as the CMD HD and FD drives, already have JiffyDOS built in. Therefore, if you have an SD2IEC, you only need to update the KERNAL ROM in the C64 to greatly speed up your computer's access to it.

The IDE64 and RAMLink do not require speed enhancement because they are already fast due to being connected via the expansion port. Also, the RAMLink provides the computer with JiffyDOS, so if you are lucky enough to have a RAMLink you don't need to update the computer's KERNAL ROM.

New mainboards, such as the C64 Reloaded and the Ultimate 64, allow you to install more than one KERNAL ROM virtually, via a software image of the ROM. And some plugin cartridges, such as Easy Flash 3, can give the computer a new KERNAL ROM without having to physically swap the chip on the mainboard. Just remember, JiffyDOS is a commercial product. Even if you use an image of the ROM, you should support the community by purchasing the physical ROM from one of the licensed resellers.

The drives that need a ROM update are the classics. In order to have its speed increased, each 1541, 1571 and 1581 drive needs to have its drive ROM updated to JiffyDOS. If a drive does not have its ROM updated, it continues to work just fine but runs at the slower, stock speed.

The Benefits of JiffyDOS

First the disadvantages of other speedloaders. There is more than one way to improve the speed of the IEC serial protocol: Some speedloaders improve the speed but at the expense of compatibility. Some of them only speed up the 1541. Some don't work if there is more than one device on the IEC serial bus. A plugin cartridge occupies the one and only expansion port on the computer, requiring you to use a port expander to combine the fastloading cartridge with any other cartridge, such as RAM expansion. Some software is simply incompatible with how some speedloaders work.

JiffyDOS strikes the best balance of all of these considerations. It is 10 to 20 times faster than a stock C64, depending on the storage device. It occupies no ports on the computer and uses no additional addressing space. It is compatible with all drive types, and can improve the speed of most drive types. It is compatible with multiple drives on the bus at the same time, and offers features that improve the usability of multiple drives hooked up together. It uses no extra or non-standard cabling. It can be disabled with a switch in the rare circumstance of software incompatibility, but in all practical experience it is extraordinarily compatible with existing software and virtually never needs to be switched off.

JiffyDOS provides the computer with a built-in, always available, DOS Wedge. And it provides several additional features that greatly improve the usability of a Commodore 64, right from the READY prompt.

Text and BASIC listings

The original DOS Wedge introduced the ability to stream directories from the device to the screen, without overwriting the BASIC program in memory, with the @$ command. JiffyDOS extends this by allowing text file and BASIC program file listings, that are streamed from the storage device.

@t:textfile.txt
@d:basicprogram

If you have a file containing any textual data, you can immediately view the contents of the text file right from the READY prompt. The BASIC program listing does the same thing, but for BASIC programs. It allows you to see a BASIC program's listing without disrupting the existing BASIC program. You can use this to get some lines from another program onto the screen, which you can then incorporate into the current program by moving the cursor up and pushing RETURN on those listed lines.

Scroll pause and lock

On a stock C64, while content is printed out to the screen that would cause the screen to scroll, holding the CONTROL key slows down the scrolling so you can read it more easily. With JiffyDOS, holding CONTROL fully pauses the listing. This works for directories that are listed with the @$ command, a BASIC program being listed with the list command, as well as the above mentioned @t and @d text file and BASIC program listings. Because it's part of the KERNAL this works inside many other programs that output scrolling content to the screen.

While holding CONTROL you can press S to lock and unlock the screen's scroll pause. This is very handy. You can, say, pause and lock the scrolling of a BASIC program listing, then take your hands off the keyboard to write something on paper, or take a photo of your C64's screen with a smartphone, go to the bathroom, answer the phone or the doorbell, etc. It's just handy.

Device detection, cycling and default device

JiffyDOS automatically detects what device numbers are in use by storage devices on your C64. Hold CONTROL and push the D key to cycle through the detected device numbers. On each press, the next device number is printed to the screen. This changes the current default device number.

The default device number works in tandem with the current partition and current path of a mass storage device. By setting the current device number, all of the DOS Wedge commands are directed to that device, without needing to specify the device number in each command. This makes it much easier to work with multiple storage devices.

There is also a command (@#) to explicitly set the current device number.

Two drive file copier

JiffyDOS includes a built-in two drive file copier. This alone makes JiffyDOS worth buying. In addition to JiffyDOS having a current device number, it also has a configurable target device number. You set the target device using the @x command. With the current device as the source, you can then use the asterisk (*) command to copy a file to the target device. Like this:

@#8
@x10
*"somefile"p

The above copies a file named "somefile" from the current partition and current path of device 8, to the current partition and path of device 10. The "p" following the filename sets the file type of the new file on the target device to PRG. The other file types can be specified by their first letter. (s for SEQ, u for USR, r for REL.)

It is incredibly useful to be able to quickly copy a file from one drive to another, right from the READY prompt; you don't have to load, run and configure a file copy utility. You can use this file copy command in direct mode and copy a file without disrupting the program currently in memory. But here is what is even more powerful. JiffyDOS Wedge commands can be used within BASIC programs. Combining BASIC with JiffyDOS allows simple BASIC programs to perform repetitive or recursive file management tasks. BASIC can be used much like a shell scripting language on a more modern computer.

File copy from a directory listing

The syntax of the file copier command is also designed to make it easy to initiate a copy from a directory listing. With the source and target devices already set, list a directory using @$. Cursor up to the line containing the filename you want to copy. Type an asterisk (*) over the first character on the line and push RETURN. The command ignores irrelevant extra characters so you don't have to remove them.

As if this wasn't enough, you can use a loaded directory as a file copying program. Load a directory (/$ which is the DOS Wedge equivalent of load"$",8) then list the directory. Hold CONTROL and push A. The directory lists again, but with an asterisk automatically displayed before every filename. You can also cursor up to any line and hold CONTROL and push W to toggle the asterisk on or off for that line. After configuring the files to be copied, cursor back down to the bottom and type run. The directory listing, because it is structured like a BASIC program, runs and copies all of the selected files to the target device.

That's very clever. Not only is it useful, but the asterisks before the filenames look like stars that mark selections, and it piggybacks on the directory being structured as a BASIC program. It is a solution that feels very much at home on a Commodore 64.

If you're going to really use your C64, you almost certainly need a DOS Wedge and a speedloader of some kind. Although you may think that an Epyx Fastload cartridge is good enough, you should seriously consider investing in JiffyDOS.

For the full explanation of all the features, options and DOS Wedge commands be sure to checkout:
JiffyDOS User's Manual

JiffyDOS installation guides, additional information and links to authorized resellers can be found on the product page:
http://www.go4retro.com/products/jiffydos/

Expanded RAM

The Commodore 64 has an 8-bit CPU; it operates on 8-bit units of information. It uses a 16-bit address bus to read and write 8-bits of data at a time from up to 65,536 memory locations.

RAM, ROM and Addressing Space

In the early days of home computers, RAM—the kind of memory which can be both read from and written to—was extraordinarily expensive. In the mid 1970s, just a few kilobytes cost hundreds of dollars. Computer books used to talk about the two main types of memory: RAM and ROM. ROM is read only memory and made from a much simpler and less expensive technology. It was typical for a computer to have more ROM than RAM because RAM was so costly. For instance, the VIC-20, the predecessor of the C64, came with 20KB of ROM and only 5KB of RAM. Nobody talks much about ROM anymore. Although ROM grew over the years to a couple of megabytes at most, the price of RAM fell and the amount of RAM in a typical computer exploded into the hundreds of megabytes and then into the tens of gigabytes. So, where once the ratio of ROM to RAM was 4:1, now that ratio is more like 1:10000.

For 1982, the Commodore 64's 64KB of RAM was a lot. This was made possible by switching from the more expensive static RAM to new less expensive dynamic RAM. The C64 has over 12 times the amount found in the VIC-20 released just the year before. In fact, the C64 has so much RAM that it fills the entire addressing space of its processor.

The VIC-20's ROM and RAM combined occupy less than 50% of the available addressing space, with space left over to be used by software on plugin cartridge. But the C64's internal ROM and RAM combined occupy 130% of the addressing space. In order to fit that all in, the C64 has special circuitry to allow the processor to see different things at different times in some addressing ranges.

BASIC Memory

When you turn on an ordinary C64 it performs a RAM test and then reports that it has "38911 BASIC BYTES FREE". That's 38KB, but the C64 comes with 64KB of RAM and the starting screen confirms that it is a "64K RAM SYSTEM". What accounts for this disparity?

The total space available to a 16-bit address bus can fit 64KB of content. On the Commodore 64 that capacity is divided, roughly speaking, into three major regions:

Workspace Memory
BASIC Memory
Operating System

2KB of working memory for the operating system come first, followed by 38KB of BASIC memory. The final 24KB are for the operating system and other hardware, via ROM chips and I/O chips. The topmost 24KB of RAM shares overlapping address space with the operating system and is, therefore, totally unused by the C64 in its default state.

Note that the starting screen says 38911 BASIC bytes free. That is because BASIC knows how to manage only a single contiguous block of memory. It isn't very sophisticated; it can't move memory around, or make use of the memory that is sharing the same address space as the operating system. Other software can make use of the full 64KB of memory, but BASIC programs alone cannot.

A Stock C64, Power-On Screen

How does a Commodore 64 make use of more than 64KB?

The C64 has has a 16-bit address bus. How can a machine whose addressing space is already full make use of expanded RAM?

How more memory is used on a modern computer:

A modern computer has far less memory than its processor's addressing space would permit. The operating system detects how much physical memory there is and uses a hardware memory management unit to virtualize more memory. When the physical memory fills up, some of it gets written out to disk to make room for more content to be loaded into the physical memory.

The operating system and the memory management unit always abstract applications from the physical memory. Each program ticks along as though it has almost no memory constraints. But if the physical memory gets filled up, the operating system pauses the application while it transparently shuffles information between memory and disk. The application is none the wiser, but the user notices the brief but annoying pauses.

Adding more physical memory has an obvious result. The operating system detects the greater capacity and the memory management unit adapts to take advantage automatically. Everything works exactly as it did before, but because it takes more to fill up physical memory, less needs to be swapped out to disk, and that results in fewer annoying freezes when switching between applications, and this makes the user happy.

How more memory is used on a Commodore 64:

The benefits of expanded memory are much less automatic on a C64. Barring some multi-tasking operating system projects, the C64 is generally not a multi-tasking computer. Each program typically has full reign over the entire machine. The C64 does not have a memory management unit of any kind, and all C64s come with 64KB of main memory. The software developer knows how much memory there is and writes the program to make use of as much of it as they need.

Some types of programs need to work with a lot of data. If there is more data than will fit in the available space, the developer has to decide how to handle this. A typical approach is to only load in some of the data from storage at a time. A game, for example, might load in the music, level map data, sprites and character tileset for just a single level. When the user beats the level and progresses to the next, the game then loads in all of that content for the next level, and expunges the content from the last level to make room.

Reading and writing from storage, however, is quite slow. There are certain types of data that are both very large and need to be accessed very quickly. Either the C64 can't handle this at all, or, the software can depend on expanded RAM. But the software's use of expanded RAM is not automatic, it has to be intentionally supported.

For example, a program that plays digital audio requires access to a lot of data, perhaps hundreds of kilobytes of data to playback for just 10 seconds. Reading the data from storage is not fast enough for realtime playback. Instead, the program can read the data into expanded RAM and then play it back from there. In this case, such a program absolutely requires expanded RAM and won't do much of anything unless it's available.

Some programs that can get by without expanded memory can be greatly sped up by making use of extra memory if it happens to be available. For example, if you want to duplicate an entire disk but have only one disk drive, a disk copying program can accomplish this by loading some content into main memory, then asking you to swap disks to write that out. It can then repeat this multiple times until the whole disk is copied. But if you have expanded RAM, the same program could detect that and change its strategy. It can load the contents of the entire source disk into expanded RAM in one go. You then swap the disks once, and the entire contents are written from memory out to the new disk. In this case, it's the same program and it accomplishes the same task, but if it detects expanded RAM and is written to use it, it can make the whole process a lot faster.

Two Main Kinds of RAM Expansion

RAM expansions plug into the cartridge port of the C64. There are two main kinds of expanded RAM. There are a couple of other kinds, but this guide will not discuss them because they are much less common.

Commodore 1764 RAM Expansion Unit, and a 2MB GEORAM Clone.

Above on the left is an original Commodore RAM expansion unit, shortened to REU. Above on the right is a recent clone of the GEORAM from Berkley Softworks that was originally released with the GEOS operating system. These are both popular options, but they do not work the same way and are not drop-in compatible replacements one for the other. They can, however, both be used at the same time.

The Commodore 17xx REU

The 1764 REU shown above is one member of a family of similar RAM expansion units that were released by Commodore, starting with the release of the Commodore 128. There are also several cloned versions of the originals with more memory, in a more compact and power efficient form factor.

All of the REUs in 17xx family work the same way, and they can all be used on a C64, but the original higher capacity ones require the C64 to have its power supply updated to a heavy duty supply. There are power supply replacements that are commercially available today, and many are listed in the Commodore 8-Bit Buyer's Guide. If you still have an original power supply and are trying to decide whether to replace it or just get an overvoltage protector, this is a great excuse for upgrading to a whole new power supply.

In addition to memory, the 17xx REUs provide the C64 with a special I/O chip called the RAM Expansion Controller, or REC. The RAM expansion controller is instrumental in how this type of memory expansion works.

The REC chip is instructed to copy the contents of an address range from main memory to expanded memory, or vice versa. When the copy begins, the REC uses a procedure called Direct Memory Access (DMA). The REC chip temporarily puts the C64's processor on hold, takes over the bus and is able to read and write directly to the main memory chips. When the copy is complete, the processor resumes and the program continues immediately where it left off, but the contents of memory have changed.

The RAM expansion controller chip can move blocks of memory faster than the C64's own CPU. Therefore, programs can make use of an REU simply to speed up moving a block of memory from one place in main memory to another.

The 17xx REU family ranges in memory capacity from 128KB to 16MB.

REU Model	Size	Banks	Notes
1700	128KB	2	Very small
1764	256KB	4	Small
1750	512KB	8	Medium
1750XL	2MB	32	Large
Ultimate 64 / 1541 Ultimate	Upto 16MB	256	Very Large

GEORAM, NEORAM and BBGRAM

The original GEORAM was released by Berkley Softworks in 1990. It was bundled with drivers for use in the GEOS operating system. This has led to some confusion that GEORAM can only be used within GEOS. Although GEOS can make use of GEORAM, any other regular C64 program can also be written to make use of a GEORAM.

GEORAM is conceptually much simpler than a 17xx REU. It does not use a RAM expansion controller chip, and provides none of the benefits that that chip provides. The GEORAM provides a sliding window of 256 bytes of memory at a fixed address in the C64's addressing space. Depending on the needs of the application, GEORAM's small sliding window can be much easier to work with and simpler to program than a traditional 17xx REU. But there are other situations in which GEORAM's simpler approach is slower, less powerful and less convenient.

NEORAM and BBGRAM are mostly compatible with GEORAM and provide the memory with a battery backup so that the contents are not lost when the computer is powered off.

More than one modern clone of GEORAM and NEORAM are commercially available today. The original GEORAM provided 512KB of expanded memory. Newer remakes provide 512KB, 1MB, 2MB and 4MB.

Unlike how additional RAM added to a modern computer is automatically incorporated into the whole system, only some programs, applications and operating systems on the Commodore 64, that have been written to support RAM expansions, benefit from them.

A RAM expansion on your C64 is like adding a huge storage garage to the back of your house, and hiring a fulltime staff of very quiet and extremely fast movers. It isn't that your house suddenly becomes any bigger; all the rooms and living space are still the size they were before. But you can have tons of furniture and stuff that doesn't fit in your house out in the storage garage. With the snap of your fingers, and in the blink of an eye, the movers run in, grab everything in the room and stash it in the storage garage, and pull a bunch of stuff out of the garage and neatly and beautifully arrange it in the room. It's still the same house, and the same room, but in the blink of an eye the complete inner contents of the whole house can be replaced with all new contents. Your experience as you wander through the house is that you just keep entering more and more different rooms, giving the impression that the house is much larger than it is.

There is a wide variety of software for the C64 that takes advantage of expanded RAM. And more is being written all the time. A lot of interesting and powerful opportunities open up by having access to the speed of much more than just 64KB of memory. I highly recommend that every serious C64 user invest in some form of RAM expansion.

Networking

Although it took almost 20 years from the earliest home computers until the internet became widespread, nearly as soon as the first home computers became available they were used for telecommunications. Telecommunications, in the form of the teletype network, existed long before the emergence of home computers.

By the time the Commodore 64 was released, Commodore had already released modems for the PET and VIC-20. The model 8010 uses an acoustic coupler to be paired with a standard (at the time) telephone handset and has a transfer rate of 300bps. The VIC-Modem, model 1600, was released in 1981 and has an RJ-11 jack for connecting directly to the telephone line, but still only transfers at 300bps.

Commodore model 8010 modem, model 1600 modem and model 1670 modem.

The 1670 model of modem was released around the time of the Commodore 128 and stepped up the speed to 1200bps. These modems connect to the Commodore 64 via its user port, and use RS-232 to communicate with the computer. RS-232, at 5 volts, is supported over the C64's user port right out of the box. As discussed earlier in this guide, device #2 is RS-232. With a modem plugged in, it takes only a few simple lines in BASIC to send commands to the modem to instruct it to dial out and connect to a remote computer.

In practice BASIC is not fast enough to process the data coming in from a modem at 1200 bits per second. The buffer is soon overrun and data is lost. However, terminal software that is written in assembly can easily support 1200bps and higher without any loss of data.

Direct one computer to one computer communications, via modems, was the standard of telecommunications for many years. Commodore played a large role in the proliferation of Bulletin Board Systems (BBSes), in large part because Commodore computers were affordable. They were sufficiently inexpensive that many parents could justify buying one for their kids.

Same Concept, More Speed

One of the earliest complex circuits to be integrated into a single chip was a Universal Asynchronous Receiver/Transmitter, also known as a UART. Western Digital developed one in 1971. A UART is used to facilitate RS-232 communications by handling all the timing and shifting to transfer one full byte. When the UART has received a byte the computer transfers it to memory.

In order to keep costs down, Commodore did not include a UART chip in the Commodore 64. Instead, the software in the C64's KERNAL ROM supports RS-232 by involving the processor in the transfer of each and every bit. Without a UART, RS-232 communications are slow and CPU intensive. The C64 supports up to 2400bps using the KERNAL, and up to 9600bps can be eked out if a highly efficient custom routine is used. At higher speeds like 14.4Kbps and 28.8Kbps, there is no way the C64's user port can keep up.

The SwiftLink highspeed RS-232 cartridge was created in 1990, which adds a UART chip to the C64 and can handle up to 38.4Kbps. That's 16 times 2400bps. The Turbo232 replaced the SwiftLink in the mid 90s as the gold standard in highspeed RS-232 on the C64, and can handle 57.6Kbps, 115.2Kbps and even 230.4Kbps (24x, 48x and 96x 2400bps respectively.) BBSes over a 56K modem and computer–computer transfers over a null modem cable zip right along.

The only downside to the highspeed RS-232 cartridges is that, although many terminal software packages support them, they are not supported as first class devices by the C64's built-in operating system.

GLINK 232 and LINK232 Swiftlink Clones

Modern clones of both the Turbo232 and the SwiftLink are currently commercially available, and can be found in the Commodore 8-Bit Buyer's Guide in the network section. These are still great devices and highly recommended if you intend to use a modem, or talk to some other highspeed RS-232 device such as connecting two C64s directly together.

Ethernet, the Internet and Modern Media

The problem is that modems stopped being commonly used sometime in the early 2000s. They were replaced by ethernet connections for highspeed internet over cable and other broadband media.

There are several ethernet adapters for the Commodore 64, such as the 64NIC+, the RR-Net and ETH64 for the IDE64. Without them, ethernet on the C64 would not be possible. They detect and receive ethernet packets while automatically filtering out packets not addressed to your computer. However, these adapters only handle the hardware layer of ethernet. Ethernet packets that match your C64's MAC address are fed to the C64 in their raw form. No further work is done in the ethernet adapter on behalf of the computer.

Let's compare this to the way modems work to see where the difficulty lies. Modems connect two computers together. For example, your C64 connects to a computer hosting a BBS. (Sometimes that's even another Commodore computer.) Each byte received from a BBS is directly displayed on the screen with only some light interpretation of control sequences for changing color, moving the position of the cursor, etc. Originally these were control sequences for hardware terminals, now they are supported by terminal emulation software that runs on the C64. Everything is very direct—an "A" comes in and an "A" is put on the screen—because the original hardware terminals were not computers in the proper sense. Data from a BBS doesn't need to first be buffered, sorted, assembled, interpreted or rendered, because hardware terminals couldn't do any of that stuff.

The shift to ethernet was not merely a change in the physical networking technology from modems over RS-232 to an ethernet adapter on the expansion port. Ethernet connects multiple computers together, and usually includes a router or high speed cable modem that is also on the network, the gateway to the internet. The ethernet packets need to be buffered and decoded by the Commodore 64, but they, in turn, typically are wrappers for TCP/IP packets. TCP/IP is a complex protocol with numerous large (for the C64) packets that need to be buffered, decoded, acknowledged and assembled in numeric order to reconstitute the full payload. While this is possible for the C64, it is onerous and requires time and memory, neither of which the C64 has in abundance.

In the early days of ethernet this was at least tractable, but there is a further complication. Even though the internet comprises many different services, many of which are fairly lightweight, the world wide web has taken over as the primary service for getting information (textual, human readable information. I'm not including streaming video, app stores, podcasts, etc.) The web is a medium that is accessed by modern computers with gigabytes of memory and substantial processing resources. Even simple, text-oriented websites are often enormous by the standards of the C64. It is not uncommon for just the initial HTML content to be hundreds of kilobytes. Styles, scripts and images increase the weight of a typical website to many megabytes. Far outside the grasp of a C64 to deal with.

Although C64s can use ethernet, and although they can implement TCP/IP, and although they can decode HTML, doing all three of these tasks is only possible on toy-sized scratches of HTML. Even with a RAM expansion unit and an ethernet cartridge, there is no way for a C64 to consume the resources of the modern web, unmediated, in any practical way. If you add in the transition away from plaintext to fully encrypted connections, it becomes positively impossible.

WiFi Modems and TCP/IP Firmware

If we have learned anything from this guide, it is that the C64 is like a messaging center at the hub of a small network of other smart devices. The printers and storage devices bring with them their own processor, memory and operating systems. This is the heart and soul of the way an 8-bit machine works. It delegates. The more that can be done off the main processor the better. This is why adding a UART chip in a Turbo232 cartridge allows a computer that originally only supported 2400 bits per second to suddenly support transfers at almost 100X that rate.

For reasons unrelated to retro computer hobbyists, a small and inexpensive chipset was developed that bridges TCP/IP over WiFi to RS-232. This chipset very quickly became a new dawn of modern networking for the Commodore 64 and other machines of a similar vintage. With very little additional circuitry, a TCP/IP WiFi module can be connected to the C64's user port. All of the TCP/IP work, plus all of the WiFi packet handling work, is done on the device. Simple Hayes-style modem commands can be sent over RS-232 to instruct the modem to open a TCP/IP connection to a domain or IP address on a port. A socket connection is opened, and the C64 receives the streaming content of that socket connection over RS-232 just as it would receive it from a dial-up modem.

BBSes and 2400 baud

The first way that these WiFi modems have been put to use is to reconstitute the world of Bulletin Board Systems. Only now, the underlying information transfer network is the internet rather than the plain copper-wire telephone network. Instead of giving the Hayes command to dial a telephone number, we give the Hayes command to open a connection to an internet address. After the connection is established, it's right back to streaming two-way communications between you and the host computer.

The very same Commodore computers that hosted real BBSes back in the 80s can use the exact same BBS software, but instead of a dial-up modem they have a WiFi modem. And the C64s that want to connect to those BBSes can use the same terminal emulation software that was used with dial-up modems to do so.

BBSes are lightweight, and many or perhaps most users who connect to them are only doing so for nostalgic purposes. For this reason, it is perfectly suitable for the WiFi modems to connect to the user port, to run at 1200 or 2400bps, and to support a single streaming peer-to-peer connection. That is, to support a single TCP/IP socket connection. This combination of features reconstitutes the experience of using a Commodore 1670 modem, but with a few nice perks. There are no long distance telephone fees. And while you're connected, it doesn't monopolize the household's only communications channel, the landline telephone.

So, it gives you just what you once had, without some of those pesky downsides. That's a solid win, and it revives the Commodore 64's ability to communicate with the outside world.

But… this technology has the potential for being much more.

Highspeed and ZiModem

The next step for dial-up modems was to use faster ones, but in order to do that you needed a UART chip. For this, you could get a SwiftLink cartridge, or later a Turbo232, or today you can get one of the clones of these cartridges. The equivalent move would be to connect a TCP/IP WiFi module over RS-232 to a highspeed serial cartridge.

The logical step past that has already been done: Combine a TCP/IP WiFi module directly with a UART chip into a single cartridge. Now, with a single plugin cartridge you get a UART chip that is SwiftLink or Turbo232 compatible, but the modem is built in and ready to make internet connections over WiFi. That is exactly what these are:

Link232 WiFi and SwiftLink-L Internal WiFi

Above on the left is a cartridge that can be plugged into the expansion port that provides a SwiftLink compatible UART, paired to a built-in WiFi modem. And in a very clever form factor, the one on the right above is the same thing, but it can be installed inside the C64 by removing one of the socketed CIA chips, inserting the daughter board into the socket and putting the original chip into it. The two wire clips are to map it into the appropriate I/O slot. The C64 gains the SwiftLink UART and WiFi modem, and everything is neatly tucked away inside.

These allow you to enjoy the world of BBSes at a speed that is downright enjoyable. But that's just the tip of the iceberg of the new possibilities for C64 networking.

The firmware that comes on most of the WiFi modems on the market, and listed in the Commodore 8-bit Buyer's Guide, provide only a single socket connection. I have categorized the modems that come with this simple firmware as "BBS/Telnet WiFi Modems," to distinguish them from the modems that come with the much more advanced ZiModem firmware. The two modems pictured above come with the ZiModem firmware. They have the ideal combination of highspeed RS-232 with advanced firmware features.

ZiModem is a firmware that was created by Bo Zimmerman for the C64Net WiFi modem. It provides a very clever feature set that unlocks much more of the power available from TCP/IP. It can be used as a simple BBS modem, too, so you don't lose any compatibility with plain terminal emulation software. But in addition to the simple, single-socket mode, it also has the ability to open multiple socket connections, including multiple listening sockets. Each socket is assigned a number and data can be sent and received on different sockets simultaneously.

This is made possible by sending and receiving data in packets. But unlike fullblown TCP/IP packets, these are very lightweight; they're designed for the C64 to handle with ease. They always come in the right order, and use a simple comma delimited list of numbers to identify the socket connection and the size of data in the packet.

This and numerous other commands make ZiModems the future of advanced Commodore 64 networking. It will require special software to take full advantage of the advanced features of ZiModem, but you can look forward to that in C64 OS.

For terminal emulation software, Novaterm 9.6 is one of the best.
Download Novaterm 9.6

Conclusion

I hope this guide has given you an overview of how to use the most important features of your Commodore 64. And has given you some insights into what some common expansion hardware can bring to your C64.

If you are new to the C64, it is a wonderful machine, with a vibrant community of hardware and software development, and plenty of other users. If you are returning to the C64, I hope this overview has reawakened memories of the past and encouraged you to dig back in.

Here's a summary of three simple steps to get started:

Bust out the real hardware
Make sure to deal properly with your old power supply
Get a new up-to-date storage device like an SD2IEC

With an inexpensive SD2IEC you can transfer content quickly and easily from the internet (via a PC or Mac) to your C64, and the world will open itself up and allow you to explore the vast library of Commodore 64 software.

Most of all, enjoy using your Commodore 64.

For a library of classic Commodore 64 games:
C64.com

For a collection of Commodore 64 programs, applications and utilities:
Commodore.software/downloads

This document is subject to revision updates.

Last modified: Sep 10, 2023

An Afterlife User's Guide to the C64

Introduction: Part II

Part II: Beyond the C64

Storage Devices

Floppy Disk Drives

Hard Drives, SD2IEC and Mass Storage Devices

Highspeed Mass Storage Devices

Reading and Writing data files

PETSCII not ASCII

What if a file already exists?

The @ Replace Bug

File Management

List a Directory

Structure of a Directory

File Types

SD2IEC and IDE64

The Command Channel

Open the Command Channel

Delete Scratch a File

Rename a File

Copy a file

File concatenation

Move a file

Extended File Management

About 1541 Ultimate and Ultimate 64

Why Have Partitions on a C64 Mass Storage Device?

List a Partition Directory

Change Current Partition

Change Current Directory

Make a subdirectory

Rename a subdirectory

Remove a subdirectory

Combining Paths with Commands

Further Reading

DOS Wedge and JiffyDOS

The @ Command

The @ Directory

Speedloaders and the DOS Wedge Standard

What is JiffyDOS?

The Benefits of JiffyDOS

Expanded RAM

RAM, ROM and Addressing Space

BASIC Memory

How does a Commodore 64 make use of more than 64KB?

Two Main Kinds of RAM Expansion

The Commodore 17xx REU

GEORAM, NEORAM and BBGRAM

Networking

Same Concept, More Speed

Ethernet, the Internet and Modern Media

WiFi Modems and TCP/IP Firmware

BBSes and 2400 baud

Highspeed and ZiModem

Conclusion

Table of Contents

This document is subject to revision updates.

About this document

Table of Contents

Part I: The C64

Part II: Beyond the C64

C64 OS Guides

Other Manuals

Notices

Content

Legal

About