The Commodore 64 didn’t have an operating system in the traditional sense that we now think of one. It most certainly did have a method of interacting with the user and handling I/O, including disk files. But the way it all worked seems strange today. Here’s what made the native Commodore 64 operating system different, and the alternatives that surfaced during the 64’s long life.
Division of work
When it came to handling disk drives, the Commodore 64 and other Commodore 8-bit computers took a different approach. Commodore disk drives had their own CPU, RAM, and ROM. They were a computer unto themselves. By today’s standards, we would call them embedded systems. But half of the operating system lived in the disk drive, and the disk drive actually carried out the work.
Sometimes you can see this behavior. You can issue a disk command, and then the computer comes right back and is ready for another command while the disk drive grinds away at whatever task you told it to do. A Commodore computer doesn’t have to tell the disk drive how to format a disk. The drive knows how, so the Commodore operating system takes what you can call a hands-off approach.
This approach made lots of sense in the late 1970s and early 1980s. You didn’t pay for disk drive capability unless you actually bought a disk drive. But by the late 1980s, when it was a given that people wanted disk drive capability, it increased the cost of disk drives. The decision made a lot of sense when they made it. Unfortunately when the situation changed, it was too late to change Commodore’s design.
What the native Commodore 64 operating system looked like
On the computer itself, the Commodore 64 operating system just presented a rudimentary screen editor, a flashing cursor, and a prompt that simply said READY.
The Commodore 64 had an interpreted language called Basic built in to ROM that it licensed from Microsoft for a highway robbery price of $25,000. The Basic interpreter doubled as the operating system, for all intents and purposes. It was completely text based, and the commands weren’t especially intuitive. For example, to get a disk directory listing, you couldn’t just type dir or ls like you do in Windows or Linux/Unix. You typed load”$”,8 and then when the disk stopped churning, you typed list.
Since the commands weren’t intuitive, I have a list of useful Commodore 64 commands you might want to peruse.
The advantage to this approach was that since it was all in ROM, the computer was ready to use right when you turned it on. The disadvantage was that updating the system for changing times, or to fix bugs, proved more difficult. You had to get people used to loading an operating system rather than just using what was there.
Alternatives to the Commodore 64 operating system
Commodore intended for the 64 to be able to run CP/M. This provided an industry standard alternative operating system with a large library of existing software, but it had some technical issues so it never became popular. Some Commodore aficionados don’t even realize the CP/M option existed.
In 1986, as graphical user interfaces took the computing world by storm, an upstart company called Berkeley Softworks introduced a graphical user interface for the 64 called GEOS. It provided windows, icons, pull down menus and used a mouse. It had to live within the limits of an 8-bit computer running at 1 MHz that could only address 64K of memory at a time, but it worked surprisingly well within those limits. If 1985 told us anything, it was that the GUI was the future. GEOS let the Commodore 64 participate in that future and helped extend its useful life beyond what anyone expected. Commodore expected the 64 to run out of gas sometime in the 1984-1986 timeframe. While the 64 did indeed enter a period of decline during that time, it wasn’t until 1990 or 1991 that sales dropped below a million units per year. The 64 had an amazing run, and GEOS was a big reason for it.
GEOS proved so successful on the Commodore 64 that Berkeley ported it to the Apple II, then created a similar GUI for PCs. The PC product couldn’t compete against the Microsoft juggernaut once 386-based PCs became inexpensive. But GEOS made life interesting for a while, letting people experience the future on the hardware they already had.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.