Commodore 64 – d8aBass

“The best-selling desktop computer of all time is the Commodore 64.”
Guinness Book of World Records

Does anything more need to be said about the Commodore 64 than that? I think not. Article done.

The Reasons Why It Is the Best

Before I just close, maybe I should put down a few words as to what things may have contributed to this ultimate achievement amongst computers, especially one that hasn’t been matched in the decades since in spite of the overwhelming public adoption of computers into everyday life. No, the Commodore 64 still holds the crown, and the fact it holds the crown is part of the reason why it owns the title.

Wide, Rock-Solid Compatibility

You know how your computer tells you that you need to install some updates, or they convince you (or force you) into upgrading to the next major version of an operating system? You know how this often leads to certain things not working until software fixes can be released?

Or, you know how you have one piece of critical software that doesn’t run on the new OS, but you need to be on the new OS to be compatible with 10 other pieces of software?

Or, have you ever been told that your device is too old to be updated and is therefore now obsolete in spite of still functioning perfectly as well as it did on the day it was purchased?

Yeah—Commodore 64 owners have no idea what you’re talking about.

A C=64 is a C=64 is a C=64. The “operating system” (as much as there was one on the C=64) was the KERNAL which was burned onto ROM rather being loaded into RAM at runtime (which is how modern computers function). For Commodore to change the “os” would require an actual hardware revision with new ROM chips. In reality, at this time in the computer industry, it may have been viewed more from the direction of hardware changes driving for needed changes to the KERNAL to compensate for the hardware changes. The whole concept of “adding features to the OS” probably didn’t become a thing until the OS was a separate entity created by and monetized upon by a separate company (cough-Microsoft-cough).

As a result, there were very few compatibility issues to worry about at all. If you got a cartridge, you plugged it in and it worked. If you got a new disk, you slipped it into the drive and hit LOAD"*",8,1 in one single motion and it worked. There were no IRQ conflicts or DMA channels to configure—the most one had to configure were the drive IDs for the disk drives on the IEC bus which could each be a value from 8-11. There were no warnings of missing drivers. There no minimum RAM requirements. The software just said “Commodore 64” on the box, and that’s all it needed to say, from the start of the computer’s production all the way to its end.

Ain’t nobody got guaranteed compatibility like that anymore, and we’ll likely never see anything like it again.

Equal User Experience

If you have a Commodore 64, then your experience of using it is almost exactly like the experience of any other owner. Every C=64 boots up into the same exact state—the famous blue screen (not “..of Death”!) which introduces BASIC 2.0 and the number of bytes free. Yes, as time progressed and special tools like The Final Cartridge, Super Snapshot, or even Epyx Fastload were introduced, even the earliest interactions after power-up could be different. But compared to how vastly different post-bootup user-experiences can be today, the Commodore 64 basically put everyone at the same starting point every time it was turned on.

This is basically a follow-on benefit derived from the fact that the “os” of the C=64 never changed and that the computer booted from its internal KERNAL ROMs rather than software. Everyone had to type LOAD"*",8,1 at least once-million times if they had a C=64. And you could write specific steps for a person to follow, and they would get the right results when following them because every computer started from the same state universally known and shared by all other users.

That makes for instant community.

Games, Games, Games, and Games

Most will argue that the primary reason for the Commodore 64’s dominance in the 80’s home computer market—and a source of it’s world-record title—is its use and design as a gaming device. Why hook up a video game system, like an Atari 2600, to your TV when you could hook up a C=64 to that same TV and play games that were much better? Oh, and maybe also get some work done. But better games!

This logic worked, and the Commodore 64 was able to cash-in on this because the VIC-II chip gave it decent graphic capabilities (color!) and the SID gave it audio capabilities considerably ahead of any other contemporary home computer or game console at the time (its likely only the standup arcade units had better sound). We know how better sound and graphics have been the primary driving targets for video games for decades, for both the hardware and software sectors. The Commodore 64 hardware allowed it to hold that winning position for a long time, and the hardware wasn’t too hard to program. In fact, there were some programming tricks to exploit that made it pretty easy to make certain types of games.

And, boy, did they make games for the Commodore 64. Surely nobody has a complete list of all the software that was ever officially published for the computer. But it shows how accessible programming was on the C=64 that so much software could be made. And all that software still runs on a C=64 today. Because, why wouldn’t it?

Late to the Party

In spite of how much I love the Commodore 64 and know of its history, most of it is from research rather than my actual experience. At the time, in the 80’s, when the C=64 was at the height of its popularity and power, I didn’t have one. I probably hardly knew it even existed since no family members or friends of any kind had one. In fact, I think the only computer I had seen—and only paid mild attention to—was the computer at Sam Young’s house in Ketchum, Idaho, which I think was a Radio Shack CoCo model of some kind.

The first time I got close enough to touch a Commodore 64 and even program something into it was at Samuels Elementary School in Denver, Colorado, which was around 4th-5th grade (10-11 years old). The computer lab there was outfitted with them all connected to a set of shared floppy disk drives. I don’t remember what we ever did on them in any classes, but I do remember staying after school one day and typing in a program from a Run magazine which was supposed to be an animation of a flying saucer taking off. The animation was just done with PETSCII characters, but the best part was it had a UFO sound effect that went with it.

It wasn’t until I met my friend, Brent, before our 6th grade year that I finally got a chance at another Commodore 64. This was about 1986 or 1987, and his family had a C=64 connected to a dedicated TV (so there was never any worry about us needing to leave the computer so his parents could watch TV). While it was a family computer, it was really only ever being fought over by Brent and his older brother, Jeff. Jeff may have done some school work on it, but my main memories are of him playing various SSI role-playing games on it, like Curse of the Azure Bonds. In the end, we didn’t have to fight him often. It seems that, whenever I came over, Brent and I had no trouble getting access to the computer (and keeping it the whole time).

Just BASIC

Aside from the games Brent and I would play on the Commodore 64, we would do lots of programming. In reality, the games we would play were more like study activities where we’d learn concepts for our own games. We definitely had aspirations to make our own games and even did start such projects, designing labels for the boxes and disks. But we’d never ultimately succeed since we were limited to BASIC.

We knew of “machine code” or “machine language” back then, but we didn’t know how to access it. And that is an unfortunate shortcoming of the Commodore 64: while it did come ready-equipped with everything needed to create software using BASIC, it didn’t have any support or access for those wanting to program in machine code. I’m not saying Commodore didn’t make the right choice on that one—I think they were definitely correct in choosing BASIC as the programming language if costs prohibited them from natively supporting more than one as BASIC is more accessible to a larger market. But it was nevertheless unfortunate for Brent and me because, by not having any of the add-on tools and support docs to work with assembly language, we never got to learn it at an age when our brains were better at learning.

I didn’t end up writing my first lines of 6510 assembler code until I was 44 years old. Over 30 years later.