MICROCode Consulting Home
Part of the fun of writing expansion software is that people do not always agree on what is correct and proper. Included here is a collection of debates that happened during the Z-80 development era:

Z-80 register set

One of the bigger controversies was how to handle the new Z-80 register set: it offered two additional 16-bit index registers that simply did not exist in the 8080 (IX and IY) as well as a mirror set of 8080 registers, also called the "backside registers" (AF' through HL').  Some argued that CP/M was designed only for the 8080 and, as such, these extra registers were off limits to use by the operating system or BIOS.  Others argued that as the operating system said nothing about these registers (and how could it, the Z-80 had not been released yet), that they were fair game for any usage.

Well, such was the disagreement between Bridger Mitchell (of Advent) and myself (of MICROCode Consulting).  Bridger felt strongly that the operating system should not change IX and IY or any "backside registers" and, in fact, wrote some of his software (perhaps only one program) with the assumption that these registers were intact after a BDOS or BIOS call.  We felt this was not only an unnecessary restriction, but also dangerous as it ignored the fundamental basics of defensive programming.: go ahead and use any registers you want in your program, but before you call the BIOS or BDOS, save your registers (usually on the stack) and restore them upon return.  Safety is thus assured and, regardless of how you think programs should behave, no problems will occur due to Z-80 register usage.  In the end, we agreed to disagree.

So, what do you thiink?  Who is right and who is wrong?  Or is there no right or wrong here?

Well, there is postscript to the story.  We tested all of our packages widely with every software product we could obtain, especially anything written for the Z-80.  Finding no issues, QP/M and several ROMs were widely released to the public for sale in the 80s.  No customer bugs were every submitted for this issue -- except one, which happened to come from Advent.  They should have used defensive programming!


ZCPR 3 and the Memory Squeeze

One of the biggest stumbling blocks with CP/M was memory.  The problem is that 8-bit CP/M works in the 16-bit address world of the 8080 (Z-80) which means, at best, 64k bytes is available.  Even with a very clever BIOS that supports memory banking, 63K is about the limit truly available.  And, with a normal BDOS, that comes down to 59.25K available for a problem or, if you need the CCP, 57.25K.  The most popular systems at the time, namely Kaypro, Xerox, and Bigboard, had between 60K and 62K actual space available.  That means only 56K is available for a given program and it's memory needs. 

MP/M and CP/M 3 were two different operating systems that depended upon banked memory to solve their needs.  Essentially, the upper 4 to16K of memory would remain fixed while the lower 48 to 60K could be swapped out for a different 48 to 60K.  Out much earlier than CP/M 3, MP/M used this concept to support multiple users and programs; in fact, each program was only allowed to run in its allocated space.  CP/M 3 made this banking available to all programs, but was unfortunately released at the sunset of 8-bit operating systems, soon overshadowed by the IBM PC.  The fact is nearly every program written for CP/M could not depend upon banked memory of any kind and most of the good ones were written before banked memory.  Unfortunately, the big software companies and most of the software authors had moved on to MS-DOS.

Enter ZCPR 3.  ZCPR 3 was a big step forward from its initial humble beginnings as a replacement for the CCP.  It added a UNIX flavoring to CP/M by allowing search paths, offering the concept of a directory structure (albeit based upon user areas), and had a bevy of CCP extensions. With its expanded DOS, it could also support many new features only dreamed about by 8-bit users. Of course, all of this came at a cost that most users could ill afford: memory.  These extra features took another 4K of memory.  Run a full-blown version and you are talking up to 8K of memory consumed by the OS alone.  Yikes!

Now, to be honest, you cannot fault people for wanting to have the features offered by ZCPR3.  It is just that they still need to get their work done and one of the big controversies was just how much memory as really needed to get your work done.  At MICROCode Consulting, we took that attitude that you can never have enough free memory.  Hence, despite all of the extra goodies we stuffed into both the CCP and DOS when we wrote QP/M, it fit in the same memory footprint as the original CP/M 2.2.  ZCPR3 took a different approach.

So, what do you thiink?  Who is right and who is wrong this time?

You can guess our view, but if you can run with the memory restrictions of ZCPR 3, knock yourself out -- although you will not get the elegant time-stamp stamping and powerful batch processor QSUB offered by QP/M.  In the end it did not matter: ZCPR 3, like CP/M 3, came out far too late to have any impact on the market.  The IBM-PC had arrived and the Z-80 quickly turned into a hobby instead of a mainstream workhorse.