Long Term Prevalence of 8080 Code Over Z80 Code in Software Packages

Question

TL;DR:

The Z80 was introduced not long after the 8080 and replaced it quickly and almost entirely for personal computing. Still, a large chunk of new software written stayed with 8080 code, making no or only very limited use of Z80 instructions.

Are there any reliable numbers of the amount of Z80-only software for OS that supported both CPUs? For the fine print see below.

---

Story Behind

While the 8080 started its CPU lineage in 1975, it was dethroned two years later by the less expensive and (hardware wise) more versatile Z80. Right in time for the home computer era starting ca. 1977. Except for some very early systems (Altair/SOL), late (DAI) or undead (Interact) designs and regional circumstances (COMECON countries *1) the Z80 ruled the market for 8080-compatible CPUs (*2).

Still, even throughout all of the 1980s many software packages did not use Z80 instructions - or in case of compilers, did not generate Z80 code (*3). There were programs explicitly Z80-based, like ZCPR replacing CP/M's shell CCP with a Z80 optimized version, but it felt like a minority (*4).

This is even more astonishing as not only new computers were designed around the Z80, but also a good part of all S100 systems were upgraded (*5) with the new, more powerful (and less power consuming) Z80. After all, early Z80 cards doubled the speed to 4 MHz (*5). Later cards not only cranked that up to 6 or 8 MHz but offered addressing past 64 KiB, interfaces and even full 64 KiB on board.

Fine Print

What I'm looking for is (somewhat) reliable numbers to get a picture how true my impression is - or isn't. Of course a relevant result can only be found for operating systems that supported 8080 as well - at least at some point. Main candidate might be CP/M and its derivatives. It does not make any sense to look at OS that were only used with/made for Z80-only-systems, like Tandy TRS-80, CPC or MSX (*7).

A good answer might include some quantification, like how much of a certain software archive is 8080 code vs. Z80 (or later) code. Might be interesting to see what metrics can be used.

Since more software was produced later (i.e. Software production increases a lot during the 1980s), a result might be biased toward Z80, but that's fine as it simply shows at the end of the Z80 era.

---

*1 - And even here the Z80 was a strong opponent, as Eastern Germany did, unlike most COMECON countries not clone the 8080, but went right away (and 4 years late) for the Z80

*2 - Intel's 8085 did find some usage in portable devices like the Kyotronic series due its low power CMOS version.

*3 - Including Turbo-Pascal. While it and its products needed a Z80 to run, the compiler itself produced clean 8080 code. Only its runtime/libraries contained Z80 code - most likely as they were written in Assembly.

*4 - IIRC, later ZCPR also came in a 8080 code only version. But my memory might be false.

*5 - All the Altairs and IMSAIs I have came with Z80 cards instead of the original 8080 board. Quite often the Godbout/CompuPro Z-CPU or the Ithaca Z-80.

*6 - Especially Godbout's Z-CPU was famous for being stable at 6 MHz and above.

*7 - Thinking of it, it might be even more interesting if similar patterns would show up at such systems, as they provide no incentive to avoid Z80 code. Lets make it an addition for bonus points :))

Answer 1

Summary:

Are there any reliable numbers of the amount of Z80-only software for OS that supported both CPUs?

No, not previously, and not from third parties. I've had to rely on my own research here. For the 3487 unique CP/M-80 COM files in the Oakland archive, 55% likely contain only 8080 code, while 45% would appear to include some Z80-only opcodes

Since more software was produced later (i.e. Software production increases a lot during the 1980s), a result might be biased toward Z80, …

From the software archives I've been able to look at (including the Oakland CPM Archive CD-ROM plus some archives of miscellaneous commercial CP/M-80 software), I don't get a clear picture of more people contributing code that would only run on Z80s as time went by. Here's a graph of the guessed 8080 vs Z80 code in the SIG/M library by slightly uneven time:

The terminology used in the graph will be explained later.

Background

CP/M-80 COM files are simple containers of bytes with no headers and no segmentation into code and data. Thus it's hard to say what's actual code, and what might be data. To further confound the issue, the Z80 can run 8080 code perfectly.

One way to guess if a CP/M executable contains Z80 code is to count the number of two-byte sequences in the file that correspond to Z80-only opcodes. These opcodes (detailed here: Z80 Instruction Set) start with one of four byte values: 0xCB, 0xDD, 0xED or 0xFD. The second byte of the Z80-only instruction can take a variety of defined values: they are fairly easy to count.

It is assumed that code written for the Z80 will have more of these specific two byte sequences than code written for the 8080. The Z80 instructions are be completely valid data to an 8080, so they will still be seen occasionally in pure 8080 COM files.

From counting the number of Z80-only byte sequences in files (using is_z80.sh, a Linux tool I wrote), I came up with a heuristic: the Z80ness of a binary is the number of Z80-only byte sequences per 10,000 bytes. The odd scale is to ensure that the value is a useful integer range from 0–~900.

Reviewing known 8080 binaries (all of DR's system disks, for example) and comparing them against binaries for Z80 home computers, it became clear that 8080 code typically had fewer than 40× Z80 byte sequences per 10,000 bytes. Any “Z80ness” over about 40 appeared to be written specifically for the Z80 and wouldn't run on an 8080/8085 at all.

To track the change of code target with time, I looked at the SIG/M Amateur Computer Group of New Jersey disks. This group released over 300 volumes of “PD” software from 1981–1987. If the Z80 opcodes gained mindshare with time, surely this would have been reflected in a clear trend in the SIG/M disks? The graph shows otherwise: there's no real trend at all. People were programming Z80s as if they were 8080s, pretty much all the way through SIG/M's life span.

There are, of course, exceptions:

1. WordStar, the classic word processor for CP/M, stayed solidly 8080 compatible throughout its life. But a v4.x release for the MicroBee computer appears to be almost pure Z80 code. John Dallman notes, however, that WordStar 4 was based on a clone, NewWord.

2. Code written for the Apple II Z80 CP/M cards appears to be solidly 8080, unless it's a hardware specific driver, then it has Z80 opcodes.

3. A few games for the Z80-based Sinclair ZX Spectrum use suspiciously few Z80 opcodes. One example appears to be Hudson Soft's Stop the Express, originally written as 暴走特急SOS, "Runaway Express SOS", for the Sharp X1.

Answer 2

I think you can look at this in two ways:

1. What amount of code was actually written in Z80 assembly using Z80 mnemonics, and what amount of code used 8080 mnemonics (otherwise, using the same 8080 opcodes). Without the source code, there is actually no way to find any data today on that. Choice of language was definitely one of taste - my personal choice has always been Zilog's way of writing - I simply found it easier to read and intuitively understand, but YMMV.

2. Code actually using new Z80 instructions - This pretty much looks into "how useful were Z80 extensions over the 8080 instruction set to the average programmer". And here, it definitely depends on how far your code "owns the machine". The Z80/8080 lacks a really clear distinction between application and OS space - If your OS tends to use, for example, the Z80 alternate register set or the index registers, there's not much point in using it in application code, because saving your context might simply be too expensive. So, we need to look into specific machines to determine "what could be made usable".

   On the ZX Spectrum, for example, probably 90% of the more sophisticated games had to use IM2 (which would show up in code dumps only as one single Z80 one-byte opcode), because that was the only way to get to a reliable timing base other than pure cycle counting. For games using sophisticated graphics and interrupt-driven music, IM2 basically was a must, and I would guess IM2 was the most-used Z80-specific feature on the ZX Spectrum.

   I have no clear view on the alternate register set, there must have been a lot of games for the ZX Spectrum that used it, especially when you used stack access to the video memory where the number of usable registers is key for fast graphics. Other than "I need a bunch of scratch registers now", the usefulness of the alternate register set can be considered limited.

   Index registers (IX and IY) are sometimes very useful, but can be expensive from a code density and cycle count view - indexed access typically uses 1-2 bytes more code space and roughly more than twice the CPU cycles compared to access over an address register, so were sometimes considered a luxury feature.

   Loop instructions: Loop instructions (like LDIR, for example) are - after IM2 - probably the most commonly used extensions of the Z80 over the 8080. Especially for memcpy-like applications, they are both a lot faster and more dense than the same thing in "explicit 8080". But they are not the fastest method: If you do stack-based memcpy (because that's faster) you're using 8080 instructions yet again.

Looking away from specialised platforms like the Z80 that have a somewhat more "traditional" segregation between application and OS - like CP/M, you had yet another choice to make, which was your user base. CP/M is clean 8080 code, so you were free to use any extended Z80 feature without the OS interfering. How much customers do I lose when offering Z80-only applications? Notably the only really omnipresent piece of software (that comes to my mind) that took the Z80 decision was Turbo Pascal. (And I really don't think it hurt that product much).

I also have a feeling that software originating in Europe and Asia has a bit more of a tendency towards the Z80 (probably because these regions jumped on the CP/M wagon relatively late when the Z80 was already omnipresent) than US software.