C64 OS TECHNICAL DOCS
Last modified: Apr 26, 2019
I have had a fascination with OSes going back to the early 90s when I first discovered GEOS 1.2 for my C64c. I was never a fan of Microsoft but I really liked Windows 3.1, it had a charm, novelty and simplicity that peaked my curiosity. But I probably became most enamoured when I first played around with a Performa running MacOS 8.5. On the other hand, I never liked Windows 95 or its spiritual heirs, 98, ME, or 2000. And XP was particularly ugly and boring in my opinion. But to each his own, of course.
I learned to use a Unix command line when I was in high school in the mid to late 90s. I was using my c128D with a Turbo232 and a 33.6K—and later 56K—modem to dial into a shell account at a local ISP. Vanessa Ezekowitz helped me learn about bash and how to manage a Unix command line. When WiNGs (née JOS) first caught my attention in the early 2000s I became obsessed with OSes. They have the ability to empower a computer to do more than any one programmer would ever want to do on their own for just one program.
But there are some downsides to OSes. They add overhead and take up precious memory. They also abstract the developer and the user away from the hardware. In the long arc of computer history hardware abstraction will correctly be seen as one of the most instrumental technical developments that enabled the modern computing era. But from a hobbyist or hardware enthusiast standpoint if an operating system can be ported from one physical computer system to another, it washes away or hides what is unique and special about that computer. As much as I loved WiNGs—and I really loved it—in many ways it transformed a Commodore 64 with SuperCPU into a more powerful but generic PC. Using jsh (the JOS Shell), while powerful, useful and familiar, made using a C64 feel essentially like using a slow Linux PC with crappier graphics.
I believe in the utility of the OS to unleash the power of a computer, especially a Commodore 64 or 128. But I am very cognizant of the tendency of an OS to standardize the experience across computing platforms. I want C64 OS to maintain the C64's quirky and spunky nature. But at the same time, I do not want to have to rewrite or even reinitialize a TCP/IP stack from scratch with every network–based app that I write. And I do not want to reimplement memory management, or mouse input for every app I write. We need a KERNAL of code to help make writing modern apps easier.
First, OS stands for Operating System. But what an Operating System is is another issue. I've read in forums people arguing over whether the C64's KERNAL and/or BASIC roms are an operating system or not. In my opinion, the answer is a clear and resounding YES. They are definitely an OS. But this leads us to a more general question, what is an OS? How have we gotten to the point where there is confusion and disagreement about whether the C64 has one built–in? You may not agree with my answer, but my view on this matter will color the rest of everything you read in this documentation.
Without software, a computer is just a bunch of chips soldered together on a bus. Those chips don't do anything at all without software to guide the behavior of the CPU to pull data from some chips, interpret the meaning, apply transformations and push data out to other chips, before moving on to the next step. Indivdual programs are software, and operating systems are software. So what is the difference between the two? An operating system is a body of code that is meant to be reusable, partially resident at all times and to augment the development of other programs. It gets a little bit more complicated though because operating systems usually come packaged with their own applications that make use of their services to help the user work with and manage their computer. And so, is the operating system just the bits of code that get reused by other applications or is the operating system the whole package including the useful extra applications it comes packaged with? For our purposes here it doesn't much matter, although I tend to think of an OS as the whole package.
GEOS is more clearly an OS than the KERNAL and BASIC roms, "OS" is right there in the name "GEOS". It contains useful system–level reusable code, but it also includes the deskTop program and other utilities like the calculator and notepad apps. Although, these really are just GEOS apps that can be swapped out for others and/or don't need to be used at all. The KERNAL and BASIC roms do not need any extra programs to be used, because they contain a built–in user interface. But if you aren't fully aware, here are some of the things the KERNAL does: implements the keyboard driver, implements the screen renderer, interprets PETSCII in a kind of terminal emulator, contains hardware drivers for RS232 communications, IEC bus serial communications, tape drive communications. Has hardware test and initialization routines, manages memory regions, maintains a system jiffy clock, and manages file–based I/O. All of these are the sorts of functions you would expect to find even in a modern OS, although many features of a modern OS are missing. The BASIC rom depends upon the presence of the KERNAL rom. It works as a combination command line user interface and script language interpreter that backends on the KERNAL routines to perform its low–level work. Together they allow the user to interface with the computer, to load programs and more. Together, they are an OS. There is absolutely no room for doubt about this in my mind.
There are some things that seem obviously missing. For example, everything related to file and disk management. However, the way Commodore computers handle disk management is very clever. They have only a 16-bit address bus. And so they can only address 64 kilobytes of memory and I/O simultaneously. This is a huge limitation. Imagine if they tried to squeeze all of the disk management you could ever want into a sort of extended KERNAL rom. It would leave less and less memory for programs, and it would be inflexible for dealing with new kinds of storage devices. Instead, the KERNAL implements generic file–based I/O, and the ability to open channels and send commands to devices on the serial bus. Every serial bus device is its own stripped down 8-bit computer. A 1541, like every other CBM and CMD drive, has its own 6502 CPU, its own ram, its own rom, its own system bus and the ability to run its own Disk Operating System software. Some of these devices get their DOS software from an onboard rom, but others, such the CMD HD, have enough rom to get them to load in the bulk of their DOS from the storage medium itself the harddisk drive's special system partition.
There are some disadvantages to this arrangement, but there are also some great advantages especially considering the nature of the computer's limitations. The C64 offloads the work of disk management to another computing device, freeing itself up to have more memory for the user's own programs. It also allows the C64 to work with future devices, such as the uIEC/SD, IDE64, or 1541-Ultimate II+, which are able to work with storage media and file systems that were not yet a twinkle in their engineers' eye at the time the C64 was being designed.
The way the C64's OS, the KERNAL and BASIC roms, plus the DOS on serial devices, works is stylistically quite different, even foreign–seeming, to how modern computers work, but it is most definitely an operating system. C64 OS does not get rid of the KERNAL rom, which provides low–level access to the serial bus. However, it does patch out the BASIC rom, and replaces it with a suite of services that the KERNAL rom doesn't provide. This documentation outlines the features and functions of C64 OS's extended KERNAL, including its new UI and user interaction model.