Are all CP/M-80 implementations binary compatible?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 :))

Answer 4

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.

Answer 5

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. :(

Answer 6

I will leave aside the issue of disk formats here, since that's not directly related to binary compatibility, and assume that the user has managed to get whatever program she's interested in running on to a diskette that her system can read. (Though not related to binary compatibility, this was, however, a major barrier to data interchange amongst CP/M systems.)

Though it wasn't unusual for a particular program to run on many different CP/M systems, CP/M systems were not always binary-compatible with each other for several reasons.

1. A small number of CP/M systems used a different "BOOT" address from $0000 and/or "TBASE" address from $0100. The former determines the location you use for calls into CP/M code, and the latter determines the location at which your program must live. The only practical way to handle changes in this is generally to re-assemble the program code. So WordStar, for example, had different versions for "standard" CP/M systems using $0000/$0100 and TRS-80 Model I and Heath H89 systems using $4100/$4200.

2. CP/M ran on systems with a minimum of 20 KB of memory, and this was not enough for a number of the large applications out there. That said, most systems had more memory anyway (usually a full 64K, with 50K or more available to the program) so this was not generally an issue. As well, the same problem was present on PC-compatible systems: one could not run most applications on a system with just the 64K or 128K of memory that was the standard base memory size on early PCs and compatibles. So whether this is really a limitation on binary compatibility is open to interpretation.

3. While all CP/M systems supported the standard set of 8080 instructions, not all supported the extensions provided by later compatible processors such as the Z80 or 8085. (And it was impossible to support both Z80 and 8085; you had to pick one or the other.) Many vendors thus chose to use just 8080 instructions, maximising compatibility, but some programs, for reasons of space or otherwise, used Z80 (or, rarely, 8085) instructions, and these of course would not be compatible with systems with other processors. ZCPR was a well known example of a program that used Z80 instructions, probably to save space in order to be able to add more features, though apparently later an 8080 version was also made available.

4. CP/M provided a standard for programs to read and write files and do basic console I/O (sending characters to the display and reading characters from the keyboard), and there were some basic assumptions about display capabilities baked in, such as CR, LF and backspace characters doing the appropriate thing. But any "full screen" program had to use terminal codes specific to the system's particular terminal in order to clear the screen, move the cursor around, and so on. Vendors would typically provide a setup program that allowed you to choose the terminal for which the application would send codes and even enter your own codes for terminals the vendor did not specifically support. (The same was true of printers, though that problem existed in the PC world as well.)

5. CP/M did not provide useful support for other common devices, such as serial ports and modems. This was generally solved by distributing additional device-specific code that would be added to the main program to work with a user's particular hardware. MODEM7 is an excellent example of this: it came with dozens of "overlay" files for a wide range of systems. You'd load up the main program in DDT and then read in the overlay file over top of it, and save the resulting modified binary. I suppose you'd call cases like this, "90% binary compatible," with a work-around for the last 10%.