Tjyylli

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?

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.

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

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