I never was into CP/M, but I knew it was very popular and the amount of software out there was significant. That being said, when you looked beyond the Kaypros, the IMSAIs, the SOLs and the like which were presumably built mostly similar (well, if you consider that they're all based on the 8080 or Z80), there were a few oddballs out there. In particular, you could add CP/M capabilities to 6502 based platforms such as the Apple II, C64, Amstrad, etc.

Was all software made for CP/M (8080) compatible across all these machines including the Apple/C64/etc variations? In other words, if you were to purchase WordStar on disk, could you boot it on a Kaypro just as easily as a C64 with the CP/M cartridge? I would presume all of the translation to KERNAL would be handled by the cartridge's BIOS.

Did this work seamlessly or was it a bit more complicated than that?

  • Are you asking about CP/M implementation or Application programs?
    – Raffzahn
    Commented Apr 24, 2019 at 12:48
  • 2
    I'd not mention the Amstrad as a 6502 based platform, because IIRC, it is a Z80 based one. I will open up mine this afternoon to check… ;)
    – DroidW
    Commented Apr 24, 2019 at 12:57
  • 1
    Also, why is there 'Z80 CP/M' mentioned in the title? There was never a Z80 specific implementation of CP/M. Wouldn't that better read 'CP-/M-80', like the 'classic' 8 Bit CP/M was renamed, after 68k and 86 variants where introduced?
    – Raffzahn
    Commented Apr 24, 2019 at 16:00
  • 2
    It's worth noting the method you used to "add CP/M capabilities to" the C64 was by plugging in an external expansion device that included a separate Z80 processor. Similarly the C128 was able to run CP/M software by means of an extra Z80 processor built into the machine specifically for that purpose. When in CP/M mode, the Z80 was doing all the heavy lifting, so the effective hardware configuration of these machines weren't as different in comparison to other Z80 machines as you might initially expect.
    – jmbpiano
    Commented Apr 24, 2019 at 22:08
  • 1
    @DroidW I checked mine. The 6502 is really very well hidden, I couldn't find it,.
    – tofro
    Commented Apr 25, 2019 at 12:27

5 Answers 5


The primary benefit of CP/M was that the applications software was written for the CP/M-80 platform, which made those applications binary compatible across the many computer systems that were compatible with the platform (notwithstanding the fact that some application vendors would create Z80-specific binaries, which naturally were NOT compatible with 8080 CP/M systems).

The disadvantage that overrode a lot of the above benefit was that the floppy disk formats varied greatly amongst the different competing systems. So, even though the binaries were compatible, you still needed to obtain media specific to your system. At the time, floppy hardware varied significantly, so dealing with different media wasn't something they could solve with another layer of software.

In my mind, this fragmentation in CP/M was a major reason that it was so easily knocked off its throne by MS-DOS. IBM and Microsoft together were able to standardize the hardware platform, including the floppy controllers and drives. Thus, MS-DOS applications, which were already largely source code compatible to CP/M applications, could be shipped on common media with common binaries and disk format. Thus, programs and data became truly interchangeable amongst systems from different vendors. Competition flourished, users and software vendors were spared the nightmare of incompatible media, and the rest is history.

  • 1
    Quite some software, like the most famous Turbo Pascal compiler, was Z80 only - It wouldn't run on an 8080.
    – tofro
    Commented Apr 24, 2019 at 16:12
  • @tofro Good point. Did DR ever differentiate 8080 CP/M from Z80 CP/M in its marketing?
    – Brian H
    Commented Apr 24, 2019 at 16:14
  • 1
    I don't think so. All the BDOS sources I've seen so far were written in 8080 assembly only. I don't think there ever was a DR "Z80 edition"
    – tofro
    Commented Apr 24, 2019 at 16:18
  • 2
    A lot of early MS-DOS computers were not PC compatible, so there was a bout of incompatible software (recall how hardware vendors would ensure the PC compatibility by running Flight Simulator). Those early machines were weeded out quite quickly however to where PC Compatibility was the norm, not necessarily MS-DOS compatibility. The MS-DOS market was never as fragmented as CP/M was. Commented Apr 24, 2019 at 16:34
  • @WillHartung Yes, good point. IIRC Microsoft (Bill Gates) was anxious to promote MS-DOS as a CP/M competitor any way he could. Only later realizing that the IBM PC would spawn an industry of compatible hardware for MS-DOS to leverage.
    – Brian H
    Commented Apr 24, 2019 at 16:45

Basically the situation is much like with DOS later. DOS itself is pure 8086 code, while applications may require later/different CPUs (*1) - always check the fine print on the box (*2)

Are all Z80 CP/M implementations binary compatible?

Yes, CP/M (BDOS/CCP/utilities) is pure 8080 code. BIOS in contrast is supposed to be machine specific anyway, so it's not uncommon to find Z80 or other non 8080 code there.

Was all software made for CP/M (8080) compatible across all these machines including the Apple/C64/etc variations?

Now, asking about applications, the world may look different. In general companies only used 8080 code again, so yes, a Wordstar binary for the Apple II was exactly the same as for a Kaypro or any other machine.

Of course there where also applications specific made to take advantage of more capable CPUs. It made sense to check before buying.

In other words, if you were to purchase WordStar on disk, could you boot it on a Kaypro just as easily as a C64 with the CP/M cartridge?

Yes, except exchanging disks between these three would be quite a hurdle to climb :))

*1 - Yes, I know there where drivers and extensions requiring certain CPUs to run. But these where not part of the core and even though the core was using them, the interface was 8086 compatible, so everything 'newer' was encapsulated within the driver.

*2 - Who doesn't remember the huge list of CPU, Graphics card, Sound card, CD-Drive and whatsoever list on the side of 90's game boxes :))

  • At least on the Commodore platform the disk compatibility problem was partially solved with the later 1570, 1571, and 1581 drives that could read DOS and CP/M MFM-encoded disks.
    – mnem
    Commented Apr 24, 2019 at 16:21
  • @mnem Not really, there where zillions of formats out there :)
    – Raffzahn
    Commented Apr 24, 2019 at 17:35
  • It's not perfect, for sure, although the Commodore version of CP/M 3 at least supports a variety of the most common CP/M disk formats on appropriate drives, including Epson QX10, IBM-8 SS and DS (CP/M 86), KayPro II and IV, and Osborne DD. Thanks to the Auto-density support in CP/M 3 it'll even autodetect between all those types.
    – mnem
    Commented Apr 24, 2019 at 17:53

If you could get your computer to load the disk (which sounds easier than actually done, considering the huge amount of different and entirely incompatible disk formats that exist for CP/M computers) and your computer had a Z80 CPU (some software was Z80-only, like Turbo Pascal, for example) and enough memory, you could very probably run next to all available CP/M software.

Whether you saw something (the intended something!) on your screen/terminal, depended on the terminal or terminal emulation you ran on your equipment: Your best bet was probably a DEC (VT52 or VT100) or ADM3a emulation. Most software that was not purely line-oriented thus came with patch lists or even a configuration program to adapt the software to specific terminals.

There still was CP/M software that was tailored to specific computers, very common were adaptions to popular makes that had a bitmapped text display. You could argue, however, that these pieces of software were not real CP/M 80 software, as they normally didn't use OS routines to handle the display.


Not always.

For example MBASIC (and GBASIC) supplied with the Microsoft Softcard for the Apple ][ are custom for the that environment and have support for paddles, lores and hires graphics.

This is however unusual for a CP/M application, most have a terminal configuration program to allow customisation for that environment. I wouldn't be surprised to find that versions sold with a computer (I'm thinking Osborne) were tied to that particular hardware. I'm pretty sure that Turbo Pascal on an Apple ][ format disk was already preconfigured for the softcard terminal.


Another issue that hasn't been mentioned was screen control, the CP/M equivalent of curses, if you will.

Different systems had different ways of moving the cursor around the screen, either by escape sequences sent out through BDOS console output, or directly banging the display controller and screen memory.

By and large, the solution to this was the same for any program that wanted direct cursor control: have some sort of patch that you applied to the program for your particular system. However the problem was worse than the disk drive issue, since it was an O(N M) problem: N programs being patched for M different systems required N*M patches. For the most part, each patch mechanic was typically specific to a single vendor, and therefor only applicable to a few programs, possibly one in the worst case.

I'm as guilty as the next team, in that the two programs I wrote that needed direct screen access (and in one case modem access), used a custom patch system that I dreamed up. That was used, of course, by nobody else. :(

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .