Last Updated on April 3, 2023 by Dave Farquhar
One of the most popular add-ons for an Apple II added CP/M compatibility. So I guess it should be no surprise that Commodore tried the same thing. But the Commodore 64 CP/M operating system and the associate Commodore 64 Z80 cartridge was a flop. Why?
The Commodore 64 CP/M operating system package was a combination of hardware and software. CP/M required an Intel 8080 or Zilog Z-80 CPU. The 64 had a MOS 6510 CPU. The package included the Commodore 64 Z80 cartridge, which contained a Z-80 CPU and a few support chips. The end user then loaded CP/M from disk with a typical Commodore command: LOAD”CPM”,8,1.
After loading a few kilobytes of program code from disk, the Z-80 CPU took over and the C-64 turned into a serious CP/M machine. Well, some kind of CP/M machine, at least.
Why CP/M?
In 1982, CP/M was still one of the most popular computer operating systems in the world. It had a large, mature library of business-oriented software numbering into thousands of titles.
For this reason, CP/M add-ons became widely available for early 1980s home computers, including the Apple II, Commodore 64, and Coleco Adam. It allowed you to run serious business software on a home computer without a tremendous amount of additional hardware. CP/M abstracted the hardware out enough that the same text-mode program could run on most computers, as long as you got CP/M itself up and running.
Here’s a video from 1982 of the late Jim Butterfield, a noted Commodore programmer, speaker, author, and all-around expert explaining CP/M.
Problems with the Commodore 64 CP/M operating system
The first problem with running CP/M on a Commodore 64 was the slow speed of the Commodore disk drive. CP/M is incredibly disk intensive, always spinning drive A before it does anything. CP/M and the Commodore 1541 didn’t make for a good team. It brought out the worst in both of them. You can see it in the Butterfield video above by observing how long it takes to load and unload the DDT debugger, which was a five-kilobyte executable. It took more than 10 seconds.
Adding insult to injury, in spite of how critical a second disk drive is when you use CP/M, Commodore’s version didn’t support a second drive without a patch.
The third problem was the problem of disk formats. The 1541 couldn’t read disks from the popular CP/M machines of the day, like Kaypro and Osborne. The software would work, but you had to get it onto a 1541 disk first. Today we have ways to do that, but few of them existed in 1982.
If that’s not enough for you, the 64’s lack of an 80 column display also hurt. Most CP/M software assumed something larger than the 64’s 40-column screen. Several third parties made 80-column cartridges for the 64, but they plugged into the same place as the CP/M cartridge. You had to have a port expander to allow the two to coexist. Then someone would have to modify Commodore CP/M to use the cartridge. As far as I know, no one did.
So, compared to its equivalent on Apple computers, the Commodore 64 CP/M operating system gave a second-rate CP/M experience.
Compatibility issues with the Commodore 64 Z80 cartridge
Last but not least was the cartridge’s compatibility. The Commodore 64 Z80 cartridge only worked in very early 64s. Early variants of the VIC-II chip, the 64’s video chip, had a number of bugs that affected the machine’s operation. Commodore fixed them, but CP/M was a casualty. Some of their fixes broke CP/M, and Commodore never figured out how to fix it. If you wanted to run CP/M, you had to find one of those early buggy VIC-II chips nobody else wanted.
It’s unclear how hard Commodore tried to fix the problem. By the time Commodore broke CP/M, the 64 was selling as quickly as they could make them. So it was clear the 64 didn’t really need CP/M to be successful. Commodore’s engineers looked at the CP/M cartridge again when they built the 128, but they couldn’t get the 128’s new VIC-II to work with the CP/M cartridge either. They worked around the problem by putting a Z-80 CPU on the motherboard as a second CPU. It proved an unpopular decision but it solved several problems.
CP/M on Apple vs. Commodore
The most popular Apple II CP/M add-on was produced by an upstart company named Microsoft, the same company that supplied the Basic programming language the C-64 included in ROM. Microsoft licensed Basic to Commodore for $25,000. That worked out to less than 10 cents per machine Commodore sold.
Microsoft didn’t like programming the 6502, so the CP/M board, which it called the Softcard, was a means to an end for them. They could sell Apple users some hardware, then sell their CP/M software to them rather than developing 6502 software. And since the Apple II had faster disk drives and 80-column displays were commonplace, the Apple II provided something resembling the experience one would get with a Kaypro or Osborne machine.
Since the Commodore 64 Z80 cartridge bundle with the CP/M operating system wasn’t very useful, not many of them sold. They’re rare and valuable today, usually selling for upwards of $75 on Ebay. In my experience, about three come up for sale in a typical month.
Even though the Microsoft Softcard for the Apple II is much more common, it tends to be more valuable than the Commodore 64 Z80 cartridge. There are two possible reasons for that. It’s much more useful, for one. Second, it’s much more likely that someone remembers actually using one, rather than it just being an interesting curiosity.
On the 64, unfortunately, that’s all CP/M ever was. It was an interesting curiosity that never lived up to its early promise. Kind of like the Mimic Systems Spartan, which promised to turn your 64 into an Apple II+.
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.