Last modified: Sep 04, 2018
C64 OS has one goal.
Make a Commodore 64 feel fast and useful in today’s modern world.
It's a very high bar. The C64 was introduced in 1982 and has an 8-bit, 1MHz, 6510 CPU with just 64 kilobytes of directly addressable memory. It has a screen resolution of 320x200 pixels, and a fixed palette of 16 colors. But, it is an incredibly versatile machine. And it enjoys an active userbase and a great variety of modern hardware expansions.
The C64 has had many operating systems written for it, So why write another?
Some of these projects were designed to be experimental, or to demonstrate a point, rather than to solve a problem or to make using the C64 better. Others had good intentions but pushed the machine in ways it wasn't designed for, compromising on speed and usability in the pursuit of features available on more powerful computers. The aim of C64 OS is to work with the limitations of the Commodore 64 and enable it to become useful.
Every program, every game, every application, is written to solve its problem and to accomplish its goals. An operating system is no different. Often, the goals of one system are simply incompatible with the goals of another.
The reason, therefore, to write another operating system for the C64 is to create something that is designed to accomplish its goals. As stated boldly at the very start of this project and this site, C64 OS has only one goal: to make a C64 feel fast and useful in today's modern world.
What makes a computer feel fast and usable?
C64 OS is simple and streamlined and makes certain concessions in order to work within the hardware limitations. But an operating system exists to provide consistency and usability advantages for the user, and to make writing new applications easier for the developer.
The most important part of a Graphical User Interface, ironically, is not its graphics, but its point–and–click nature. After 35 years of mouse–based computing, the mouse is still going incredibly strong. But there is another unsung hero of the GUI that has been with us since the beginning. The menu bar.
The menu bar has been, and in my opinion remains, the best mechanism for providing familiarity, discoverability, and progressive disclosure in user interfaces on any platform. Jack Wellborn — The Menu Bar, Worms & Viruses, March 2018
I could not agree more. A tremendous amount of user interface can be tucked away, and neatly organized behind pulldown hierarchical menus. Full customizability and mnemonic keyboard shortcuts give users power and speed. Even on a low resolution screen, hundreds of menu options can be accessed on–the–fly, without robbing precious screen real estate, and without forcing the user to memorize commands.
But in order to be effective, and to make a computer feel fast, the menus have to be fast and fluid. C64 OS's primary UI is in textmode, with a custom character set. Nothing beats that for rendering speed. Even at 1Mhz, the C64 can rerender the entire screen many times a second.
C64 OS combines a sophisticated mouse and keyboard event model, with fast rendering menus, to create a UI that feels consistent between apps, renders super fast, but has the ease of use of a mouse, and the power of complex, customizable keyboard shortcuts.
What has changed the most, and needs the most love?
The base C64 still only has 64K of ram after all these years. Although, Ram Expansion Units are more available now than they have been since their heyday. An REU can come in the form of the 1541 Ultimate, 17xx clones, or the new GeoRAM clones. But, despite their availability, these are not the biggest change in hardware.
Screen resolution is still the same as it always was, and the SID is still the SID, although it's easier than ever to get SID chip replacements, and dual SID solutions are plentiful. There are also newer audio expansion devices, like SUX 6400, DigiMax and FM-YAM. But, these are not the biggest change to hardware.
The two biggest changes in hardware, in my opinion, are:
- Access to cheap mass storage and
- Effortless wireless TCP/IP networking.
Hands down, game changers. But the software to take advantage of these two changes, or even to deal with them, has been sorely lacking.
CMD HDs were like 1541 drives on steroids. Instead of disks you had partitions, and each partition could be nearly 100X bigger than a 1541 disk. Native partitions offered directory support, the drive had JiffyDOS built in, and a host of other nice features. But they also cost 500 to 600 dollars, and used bulky SCSI spinning disks that are no longer commercially available.
Most C64 software had already been written by the time the CMD HD came out. Later C64 software added support primarily by exposing the command channel to the drive. For example, by allowing the user to send a change partition command directly to the device. The software itself doesn't know anything about partitions or directories, but allows the user to interface with the drive so the software isn't trapped in a single folder. However, such software never really took advantage of multiple directories, much less multiple partitions, and in fact would often break in strange ways after the user changed partitions.1
C64 games today, are still written as multiple 1541 disk images, that require you to either change the physical media, or use the 1541 Ultimate's ability to swap mounted images, or the SD2IEC's disk image swap list, etc. They don't bother to write the game in such a way that if you dump all of the files into a common folder on a larger partition, that they could find the files they need without asking the user to switch media. Wheels was a step up to try to add support for multiple partitions and directories to GEOS. But it remained highly constrained. If you change partitions, and double click a GeoPaint document, if GeoPaint cannot be found either in that directory, or in the system directory on that partition, then it is completely lost with no means of finding a copy of GeoPaint elsewhere on the same harddrive.This problem of general lack of support, and lack of enthusiasm for adding support even in new software, I believe can be attributed to the high price, and subsequently limited market penetration of the CMD equipment.
Jump ahead another 2 decades. SD Card readers are like Ant-man. They're miniature CMD HDs on serious steroids, at a fraction the price. Instead of 4 gigabyte spinning disks with 16 megabyte partitions, for $600, an SD Card reader fits in the palm of your hand, uses tiny abundantly available, inexpensive SD cards which can be natively shared with PCs and Macs, and supports up to 128 gigabytes in a single partition2. For all of this, what is the cost? A mere 50$. There isn't a Commodore user on earth who can't afford an SD Card reader. Storage today, therefore, is like cheap super–powerful CMD HD's for everyone.
Networking in the early 2000s and before consisted almost entirely of dial–up modems. In many cases these could be modems much faster than anything Commodore ever made and connected via high speed RS-232 adaptor cartridges, like SwiftLink, Turbo232 or Duart. Eventually ethernet solutions became common, and are commercially available today, such as the 64NIC+. However, these solutions require the C64 to implement both Ethernet packet handling, as well as TCP/IP. This is possible, and I intend to integrate native TCP/IP into C64 OS, however, it is not ideal because it takes a lot of memory leaving ever less memory available for apps and there data.
The recent rise in popularity of the WiFi network carts have got TCP/IP built into the hardware. They are a bit slow, because they're connected to the C64's user port and essentially pretend to be user port modems. However, the easy of use, WiFi connectivity, built–in RS-232 routines in the KERNAL, and the vast array of commercially available options makes them a very compelling alternative.3
C64 OS is aimed at taking advantage of these hardware enhancements.
- Event–driven interaction model
- Advanced mouse and keyboard event system
- Hybrid memory manager
- String, Math and File Libraries
- Text screen compositor
- System–wide pull down menus
- Object–oriented widget toolkit
- Universal cut, copy and paste
Applications [In progress]
- App Launcher
- File Manager
Utilities [In progress]
- System Info
- Memory Info
- File Open Dialog
- File Save Dialog
- Color Picker
- About This App
- Help Viewer