C64 OS USER'S GUIDE
Chapter 9: The Philosophy of C64 OS
The Commodore 64 is a remarkable machine that had an enormous impact on the culture, and shaped the lives of many people who were young from the early 80s through to the early mid 90s. The C64 was an inexpensive home computer that first appeared on the scene with extraordinary specifications that provided great value for the money. Despite the arrival of newer, more expensive and more powerful machines, the Commodore 64 remained a commercial success for over a decade and sold many millions of units.
Part of the on-going appeal of the Commodore 64, now as a retro and hobby machine, is its vast wealth of software: tens of thousands of games, a vibrant demo scene, and a huge array of utilities and productivity packages. Thousands of beautiful graphic images and SID-chip tunes have been created as well, giving the computer a rich history that fills us with nostalgia and keeps us coming back for more.
Today, there are still more games, demos, graphics and music being produced every year for the Commodore 64 than I can keep up with. Together with blogs, print and online magazines, and a plethora of third-party hardware designers and manufacturers, they keep us filled up with games to play, music to imbibe, material to read, and new gadgets to play with, build, hack and enjoy.
But...
I want something more.
I love the C64 so much that I want to spend even more of my time with it. I want to be able to explore more of the world, fulfill more of my creative impulses, get more out of the many hardware expansions I've acquired, share and communicate more easily with other computers, my friends and my readers. And I want to do all this while enjoying the warm glow of my Commodore 64.
Let me explain how C64 OS helps accomplish these goals.
A brief history of early home computing
A lot has changed over the decades since the Commodore 64 first became available. Home computers in the late 70s and early 80s were imagined as low-cost microprocessor-based versions of the mainframes and minicomputers that powered the world of business, science and government.
Study the past if you would define the future. Confucius
Computer output during the 50s, 60s and most of the 70s was to a roll of printer paper, and that was a hard mindset to break. When video display terminals and later video controller chips were first introduced to computers, they virtualized the essential behavior of that continuous roll of paper. In part because, all software up to that point was written to function with printing as the only output.
That's why the BASIC command to put some text on the screen is called print. It's why the screen editor built into the C64's operating-system-in-ROM behaves just like a video display terminal; new text gets added to the end, until it reaches the bottom of the screen, and then the whole screen scrolls up and off the top to make room for more to be added to the bottom. The whole model of BASIC and its interaction with the screen editor, is based upon a vision of human-computer interaction that was limited by the hardware constraints of the preceding decades.
But home computers aren't limited to printing their output; they do have screens. And those screens are capable of much more than fullscreen continuous scrolling output. It took a lot of experimentation with different models of interaction, and a lot of research at places like Xerox PARC1 to develop the graphical user interface. The graphical UI is a non-linear interaction mode, in which objects are moved in a two-dimensional space, and the new layout is computed and painted to the part of the screen that has changed.
By the mid-80s a new crop of home computers appeared, and they had all adopted the graphical user interface. The Amiga, the Atari ST, the Macintosh, and others. But all three of these systems were built on a new generation of processor, the 16-bit 68K series from Motorola. And they were all more expensive than the Commodore 64, some of them a lot more expensive.
In response to the new wave of higher-end personal computers, Commodore began bundling the C64c with a new 8-bit graphical operating system from Berkley Softworks, called GEOS. They also introduced the 1351 mouse as an optional add-on that can be used in GEOS and which looks remarkably like the Amiga's so-called tank mouse.
GEOS was an incredible accomplishment, a marvel of technical engineering. A graphical operating system, with proptionally sized fonts and a word processor and painting application bundled in, that runs at a mere 1MHz, in 64 kilobytes of RAM, from a single 5.25" floppy disk drive. If it weren't true, you would hardly think it possible.
But for all of GEOS's accomplishments, its shiny surface and slick screenshot appeal veil some unfortunate underlying realities:
1. The 1541 disk drive's lack of a robust file system required the development of the VLIR file format. It was a clever innovation at the time, but it suffers from general incompatibility with non-GEOS software. It ties the OS at a low-level to highly specific traits of disk drives that are thousands of times less capacious than what is now available, and does not take advantage of modern storage devices. Even third-party GEOS upgrades offer only modest improvements in support for newer devices.
2. Many of the most innnovative features in GEOS, such as dragging and dropping icons on the desktop, selecting text in different fonts for cutting/copying and pasting in GeoWrite, access to desk accessories from within applications via the GEOS menu, the display of the date and time, and much more, are not actually provided by the OS proper. These features are built directly into the suite of first-party applications. Building them in your own applications requires serious coding effort.
3. And lastly, the bitmapped nature of the GEOS user interface is unavoidably, perilously slow. Redraws take considerable time, and consequently most things on screen are statically positioned and immobile. The position of each individual menu, for example, is hardcoded and determined by trial and error. Although the notepad-like interface of the desktop looks like a window, it only appears as such and cannot be moved. And so on. In order to speed up redraws to be acceptably usable, the bitmapped screen makes use of a bitmapped buffer. 16KB or fully 1/4th of the C64's total memory is taken up by bitmap data buffers alone.
I say these things not to criticize GEOS. It is a wonderful achievement. However, its goal was to make the C64 strive for parity with features available on machines that had significantly more horsepower. For example, the bitmapped UI—although it's a RAM hog and makes the interface frustratingly slow—was essential to accomplish a WYSIWYG word processor, paint program and desktop publishing application with proportional fonts and clipart.
But the era of producing printed documents on the C64 is behind us. The kids today have never even heard the acronym WYSIWYG. What-you-see-is-what-you-get... means what you see on the screen is what you get on the sheet of paper. There is a lot more to personal computers today than producing pieces of paper.
C64 OS does not eschew the history of the Commodore 64's rich library of software. If you want your C64 to produce a document with multiple proportional fonts and print it to a sheet of paper, there is no better way to do this than in GEOS. So, for the couple of times a year when you may need to do that, why not just boot GEOS? C64 OS will not be offended. Meanwhile, this allows us to put the Commodore 64's scant resources to use solving more modern problems.
Balances and tradeoffs
C64 OS aims to strike a balance between features that are useful and expected by modern users, while remaining true to the Commodore 64 and its humble specifications.
At just 1MHz and only 64KB of memory, everything on the C64 is a fine balance; everything is about tradeoffs and compromises and figuring out ways to accomplish tasks with what we have.
Art lives on constraint and dies of freedom Michelangelo
User Interface
A graphical user interface, one that uses a mouse for its input and allows you to click on buttons and controls in any order, is a modern necessity. Hierarchical pull-down menus are also an indispensible ingredient. They save screen real estate, provide a hook for keyboard shortcuts, and make an application's features discoverable.
But a user interface drawn in the C64's HiRes bitmap mode occupies too much memory, and takes too much CPU time to be sufficiently fluid and responsive for today's expectations.
Response:C64 OS's primary UI is drawn in text-mode, with a custom character set for adding the necessary graphical flourishes. The memory saved and the speed gained allows room for the implementation of an object-oriented widget toolkit. Standard controls like splitters can be dragged with live redrawing of the content on either side of the split. Proportional scroll bars can be dragged and content in tables scrolls in realtime.
Multitasking
A C64 has only 64KB of memory, runs at 1MHz, and has a single stack of just 256 bytes at a fixed memory page. Numerous projects have demonstrated that it is possible to implement a pre-emptively multitasking kernel for the 6502. The reality is that the 6502 was underpowered the day it rolled off the assembly line. It cost just $25, and was primarily suited for low-cost entry-level home computers. As the expectations of the user have grown, the capability of the 6502 to meet those requirements has shrunk.
Further subdividing the resources of the 6502 into numerous tasks means each task gets less memory, less CPU time, less storage I/O bandwidth, and less screen real estate than programs had when they were written to use the whole machine.
Response:C64 OS embraces the Commodore 64's heart and soul as a single-tasking computer. Each Application gets the full screen, the full stack, the full CPU, full access to the CIAs, full I/O bandwidth to storage, full access to the SID chip, etc.
But C64 OS allows any Utility to run concurrently with any Application. This single concession brings much of the benefit of multi-tasking with virtually none of the downside. An Application and a Utility work together as though two parts of the same program. But Utilities are reusable allowing Applications to defer common functionality to these small programs that can be called up from inside other Applications.
Taskswitching
The operating system, with one Application and its data, and optionally a Utility, easily occupy the majority of a Commodore 64's memory. Storage bandwidth is relatively slow, and typically requires several seconds for the current Application to save its state and data, and then several seconds more for the next Application to load in.
With conventional C64 software, resetting or power cycling the machine is typically required before loading the next program. Switching tasks in C64 OS is a major step up from this, but is slower than modern users want.
Response:The Commodore 64 was designed to take expansion hardware devices. Commodore themselves released RAM Expansion Units as early as 1986. Memory bandwidth to an REU is almost 1MB per second. If an REU is available, the Commodore 64 has the ability to exchange its entire memory contents with an external RAM buffer in around 1/8th of a second.
C64 OS v1.0 laid the groundwork for Applications to be frozen and banked to an REU, and then later to be restored to main memory and woken back up.
Fast App Switching became fully realized in C64 OS v1.05. See Chapter 4. User Interface → Fast App Switching and Chapter 7. Utilities → Stand-alone Utilities → Switcher for more information about how C64 OS handles task switching.
Graphics
Proportionally sized fonts have turned out to be less important to the future than common networking protocols, text-based mass communications, and multiple means of representation. This is a benefit to the C64 because there is now a greater focus on the content of a message—and on making it available to multiple devices—than on a canonical presentation.
Nonetheless, the ability to see pictures (a person's face, a company's logo, the shape of a country), to visualize information (how a cough spreads, a 7-day forecast, a heatmap of Earth), or to show the images of a mixed media game (a chess board, an overhead map, the scene from an adventure), bitmap graphics are still indispensible, in some cases.
Response:
C64 OS has built-in (at the level of KERNAL + Library) support for raster splitscreen and fullscreen graphics mode. The split can be configured by dragging the status bar and fullscreen graphics mode can be toggled with a globally configurable keyboard shortcut. And both can be managed programmatically.
The mouse is still active in graphics and splitscreen mode. Mouse and keyboard events are routed through both the text-based Toolkit user interface and the graphics screen. This allows text-based UIs to respond quickly and consume very little memory, while making it easy for any Application to employ graphical imagery and interactive bitmapped content however and whenever it's useful.
Storage and Devices
Although a Commodore 64 + 1541 Disk Drive is the canonical pair of devices for most C64 games and demos, C64 OS aims higher. A Commodore 64 is more and is capable of much more than only that which can be accomplished by yoking it to a slow, low capacity, storage device.
A C64 with only a single floppy drive doesn't really need a more advanced system to operate it. 1541 disks have no subdirectories, hold only a few files and have very little storage capacity. Although there is some need to transfer files between disks, there are countless file copying utilities specifically geared to work with and eke out as much speed as possible from a 1541 disk drive.
The majority of conventional C64 software does not open, edit and save documents or data files. And those that do, rarely if ever exchange data with other programs. It is sensible then for one disk to hold one program, plus its documents. For a different program, you need to swap in a different disk, you probably need to power cycle the computer, and you are very unlikely to need or be able to transfer data from one of those island environments to another.
Response:Although C64 OS is clearly a retro-computer's operating system, its orientation around documents and data files, file systems, file management, user interface continuity, data exchange via common formats, standardized data types, a universal clipboard, and shared open/save dialogs, makes it undeniably more modern than what is typically found on a Commodore 64.
Back in the day, every C64 user who had a cassette drive could have benefitted from a disk drive, if only they were more affordable. As time passed, hard drives became available. And every C64 user with a disk drive could have benefitted from a hard drive, if only they didn't cost several hundred dollars. Today, you can buy a basic SD2IEC for as little as 45 US dollars. Adjusted for inflation, this is the equivalent of just $17 from 1985.
Although SD2IEC is the closest equivalent of a CMD Hard Drive—yet it costs next to no money these days—there still isn't very much software that actually capitalizes on the powerful capabilities of these mass storage devices. C64 OS doesn't merely need a modern storage device, its raison d'être is to unleash the potential of a Commodore 64 by not saddling it with an ancient storage solution.
C64 OS is to KERNAL what Workbench is to Kickstart
Computers in the 1980s came with a good chunk of their operating system installed on a ROM chip. The classic Macintosh had its Toolbox in ROM. The Amiga has its Kickstart in ROM. And Commodore 8-bit computers, like the VIC-20, C64, C128 and others have their KERNAL in ROM. The ROMs provide essential software for driving the hardware and doing low-level tasks, but usually require software loaded from a storage device to provide the rest of the experience.
The Macintosh required a system boot disk to load the Finder. The Amiga needs a disk to load Workbench. The Macintosh ROMs evolved—and grew—relatively quickly and KickStart ROMs had a similar trajectory.2 The first Amiga 500 shipped with Kickstart v1.2, but the last Amiga 500's came with Kickstart v2.04, and can be upgraded to Kickstart v3.1.
Response:C64 OS is to the KERNAL ROM much like what Amiga Workbench is to the Kickstart ROM. A game can be loaded on the Amiga that uses the Kickstart ROM, but that doesn't need or use Workbench. Similarly, games can be loaded on the C64 that may (or may not, but they have the option to) use the KERNAL ROM, but they have no need for a desktop-like user interface.
Booting into C64 OS, with its mouse and menus and toolkit-based user interface, is analogous to booting an Amiga into Workbench. But, while newer versions of Workbench require newer Kickstart ROMs, software for the C64 is expected to rely only on the original KERNAL.3 For this reason, C64 OS is capable of running on an original KERNAL. The practice of upgrading your KERNAL ROM was not culturally a part the C64's history the way it was on the Amiga. However, there are in fact KERNAL upgrades available, and these are analogous to Kickstart upgrades.
JiffyDOS is a highly backwards-compatible KERNAL ROM update to the C64. JiffyDOS also went through a few revisions and the currently available version is 6.01. Although C64 OS proper works with a stock KERNAL ROM, disk access is slow and not all of the included tools and extras work without JiffyDOS. In the C64 OS philosophy, an upgrade to the JiffyDOS KERNAL is analogous to upgrading the Kickstart ROM in your Amiga. It's a highly recommended upgrade.
See: Chapter 8: File System → Speed and Compatibility for more information about JiffyDOS and C64 OS.
Networking
One of the principle reasons for developing C64 OS was to provide a more modern platform upon which to write network-oriented applications. These include, though not exactly in their modern form, some equivalent to an email client, an instant messenger, a file transfer program, a news reader, a group chat client, and web browser.
Before networking applications can be written, the C64 needs network access. Ethernet solutions have been around for a while, but they handle only the hardware layer of the networking. The TCP/IP packet handling has to be implemented in software on the C64. This is a complicated task that requires CPU time and memory, both of which the C64 is extremely short on.
Response:Ethernet, although it was my first consideration, is no longer a priority. Firstly, wired network connections are already considered antiquated for most personal computer use. Secondly, ethernet requires the aforementioned TCP/IP support implemented within the C64. This has been demonstrably done before, but it leaves very little memory left over for the practical use of that network ability.
The philosophy of C64 OS is not to demonstrate what can technically be achieved with a C64, but to give us practical help to enjoy a more modern digital lifestyle all while using our beloved Commodore 64. WiFi modems are the clear solution to these demands, not ethernet. Firstly, WiFi modems are wireless, making it easier to connect a C64 to a network from anywhere in your house, at a friend's house, at a tradeshow or expo, or even at a coffee shop. Secondly, WiFi modems perform all of the TCP/IP processing on behalf of the C64. This releaves the C64 of that burden, giving it more memory and CPU time to focus on handling the pure data. A smart networking device is also analogous to the smart storage devices the C64 has always relied on.
Services
Networking support is not yet available in version 1.0 of C64 OS. But the groundwork has been laid, and the C64 OS environment is ready to take advantage of persistent network access. Even with the TCP/IP work handled by a smart networking device, the C64 has very little memory available to work with modern protocols and modern quantities of data.
It is common for websites to have hundreds of kilobytes in just the base HTML page. Each image file might be hundreds of kilobytes to megabytes, and compressed with advanced techniques only to encode image data that the C64 is unable to display, both in resolution and color. Even an IRC server today, a technology built for computers from long ago, now will often send an initial welcome text that is hundreds of kilobytes. Modern services simply have no regard for computers with limited resources. This makes the experience of using modern services on a C64 either terrible or impossible.
Response:Therefore, the networking philosophy for C64 OS is to develop a suite of low-bandwidth network service proxies, and make them available via services.c64os.com. Image conversion, HTML conversion, and other low-bandwidth services to take a modern resource and scale it down in the cloud to make it consumable directly and efficiently by a C64.
With the help of these custom-designed proxy services, the future of what we will be able to do with our Commodore 64s, running C64 OS, is very promising. Stay tuned for releases of new drivers, libraries, Applications and Utilities that can be installed on C64 OS version 1.0 to bring it new networking capabilities.
Do more with a Commodore 64
The point of C64 OS is to enable you to do more with a Commodore 64, in a more consistent, modern and easy-to-use manner.
To understand the role that C64 OS plays, it may be useful to have some context by comparing it to what it's like when you typically use a Commodore 64.
What is it like to use a C64?
When I started programming C64 OS, I decided that I wanted to program natively, on my C128 (in 64-mode). I've been using a Mac for my professional work for over 20 years. The biggest shock when returning to the C64—I tried to dig in and learn again how to truly use one—was the discovery that a huge number of mundane tasks on a modern computer are either impossible or extraordinarily inconvenient on a C64.
I don't mean the obvious things; No one is going to transcode 4K video using a Commodore 64. Just simple things that, in principle, the computational resources of a C64 should be able to easily handle, are in fact not easy at all. This is the result of a lack of standard programs to do these tasks.
Text manipulation
Consider examples of basic text processing. Convert an ASCII text to PETSCII. Convert Windows line endings (CRLF) to a C64's line endings (CR). Unhard-wrap a text, by converting two adjacent line endings to one and removing single line endings, while ensuring that a single space is left between the last word of the previous line and the first word of the next. These are simple tasks that can be done in a dozen text editors for the Mac. I had to write BASIC programs to do this work on a C64. They're not hard to write, but I had to write them, and they are very slow because BASIC is slow on the C64.
Recursive file managementOnce I started developing, I nested my code files in a hierarchy of subdirectories which eventually evolved into the system directory that C64 OS has today. Experienced computer users know the importance of backing up important data. Finding a Commodore 64 backup program capable of recursively copying nested subdirectories proved impossible. So I wrote one in BASIC, which backends on the JiffyDOS file copier extensions to do the heavy lifting of copying individual files.
File comparisonThere are other tasks for which I found some programs, but they were scattered about on old FTP servers and other online archives. For example, after you have a few copies of a file, how do you compare them to determine if the copies are identical to each other? I found a CRC32 program for the C64. Comparing CRC checks on two files can determine if they are identical. It's a poor man's diff, but it's better than nothing.
Recursive file searchAfter a while, the number of includable files with constants and macros grew. But sometimes I forget which file defines a constant I need. Searching for a word in a directory full of files is a trival task on a modern computer. Doing this on a C64 is impossible. It may be the case that a file-search program exists out there, but I haven't found it and don't know where to look for it. If I do find such a program, the chances that it can search recursively through a directory tree of files is extremely low. I haven't written my own yet, so far I've just gone without.
There are other problems besides not being able to find the software you're looking for.
I downloaded a self-extracting program, which I transferred to my C64 with an SD2IEC. The SD2IEC is on device 10 and a CMD HD was on device 8. I loaded and ran the program from device 10, but it immediately started performing activity on the CMD HD. I let it run to completion, only to discover that it had corrupted my primary CMD HD partition. Why did it do this? Because it assumed it was a 1541 disk drive. And without even attempting to confirm what kind of drive it was running on, it performed low-level block writes to completely inappropriate sectors.
The point is, not only is a lot of software out there hardcoded to device 8, and not only does a lot of software support only the 1541, but some software is actually dangerous and destructive when run on a more modern storage device. If you experiment with odds and ends of C64 software, looking for some tool that might do the job, it's just a matter of time before you corrupt a hard drive partition.
The list of these issues goes on and on.
The C64 was hugely popular; many tens of thousands of programs have been written for it. But its current state of affairs is sadly in shambles.
For tasks that are common and should be easy to handle, there either:
- isn't any software to do it, or
- you can't find the software that exists, or
- the software doesn't support modern hardware, or
- the software is actively harmful when run on modern hardware.
The software that does work, if you can find it, provides wildly inconsistent user experiences. Some programs:
- have no user interface, or
- have a simple menu in BASIC, or
- have bouncing sprites and flashing borders, or
- have thumping SID tunes, making them half demo and half utility, or
- crash instantly on an NTSC machine because they expect PAL and couldn't be bothered to check and bail cleanly.
The amount of reduplication of effort, and the inconsistency of experience from one tool that's zany to another that's flamboyant, is actually shocking to the sensibilities of a modern user.
What is the point of C64 OS?
A computer is only as powerful as the software that is available for it. Greg Nacu, C64OS.com, 2022
The point of C64 OS is to be a platform upon which a new generation of useful and common tools can be written that enable you to do more with a Commodore 64. The goal is to raise the bar on the expectation of software quality. It's to help you find that software and then to use it with more confidence.
And also to be a searchable respository of a library of new software that works more consistently, more reliably, and with good support for modern hardware. The added bonus: if a developer takes advantage of C64 OS technologies, it is much easier to write that software in the first place.
Here's an example of this philosophy. There is no standard way for a C64 program to indicate who wrote it, when it was written, what version it is, or very often what it's even called. Consequently, every program tries to squeeze some of this information into its user interface here or there. In C64 OS, an Application is a bundle. Within the bundle you can place the standard about.t file. The About This App Utility, shown above, is a standard way for the user to view this information about any App.
You don't like the layout or appearence of the About This App Utility? You wish it would give you additional information such as the size of the whole bundle on disk, or an option to clear the recents for this App? Make a backup of the original and write a new version to take its place with the same name. Now every Application can benefit from its enhanced features. Offer your improved Utility to the rest of the C64 OS community.
If you still don't see the point of C64 OS, that's fine. C64 OS is opinionated software, but it's not making a normative claim about how an enthusiast ought to enjoy their Commodore 64.
However, if you see the Commodore 64 as a general computing platform, if you feel that—despite its nostalgic and quirky nature—you'd also like to be able to do more with your C64, then C64 OS was made for you. Its mission is to bring the C64 a unified environment that lets you do powerful things in a straightforward way.
Is C64 OS complete? Is version 1.0 what it's all about?
The journey of C64 OS will never be complete. Just like macOS is never complete. Just like Windows is never complete. Just like Linux is never complete. Version 1.0 of C64 OS is a usable foundation of a new platform designed, primed and ready to build a new generation Commodore 64 productivity and lifestyle software that can take advantage of and empower new hardware innovations.
The development cutoff for version 1.0 is the point at which it would provide useful value. I have tried to craft a suite of Utilities and a few tentpole Applications, (plus all of the necessary plumbing and underlying technologies to make these work,) so that ordinary users can buy version 1.0 and immediately put it to use on common and important tasks that are difficult to accomplish without C64 OS.
What version 1.0 can do today, is just the very beginning.
C64 OS provides an environment that maximizes one Application's ability to profit from and to improve other Applications. With each new Application and Utility, C64 OS will continue to become more powerful and more useful. The more powerful and useful it is, the more people will use it, which will spur the development of more C64 OS software in a virtuous cycle.
With minimal development effort, a new C64 OS Application can acquire many amenities such as a fast and customizable menu system, cut, copy and paste to a universal clipboard, device independence through drivers, data type loaders, recursive file management tasks through jobs handed off to existing Utilities, and libraries of common code that can be shared by multiple Applications. Such libraries already exist for calendar, date and time functions, for path and file reference manipulation, for reading directories from any device, sorting lists, text processing, math functions, and playing SIDs. And more will continue to be added.
Next Chapter: Appendices
- Palo Alto Research Center. Whence Apple famously bought and paid for a license to use the technology in their own OS. Counter to the narrative that they stole the technology. That was just made up for the film, Pirates of Silicon Valley. [↩]
- Macintosh Toolbox started at 68KB in 1984, 128KB in 1986, 256KB in 1987, 512KB in 1989. Which became 1MB, 2MB and 4MB of ROM throughout the 1990s. Kickstart was 64KB in 1985, 256KB in 1986 and 512KB in the early 1990s. [↩]
- The C64 also includes a BASIC ROM, this was standard practice on 8-bit computers because most of them didn't ship with a built-in storage device. BASIC made these machines usable without any additional software. [↩]
Table of Contents
This document is subject to revision updates.
Last modified: Dec 07, 2023