The ZCPR3 System
by C. Bowden G30CB
Part 1 – ZCPR Concepts and Features
In Issue 1 of Scorpio News I described some of the ways in which
CP/M (Vers. 2) could be improved.
In the article I described the ZCPR/CCPZ improved CCP, and
briefly mentioned the ZCPR2 and ZCPR3 systems. I have now had a chance to try
both of these upgrades, and in this article I will describe the features of this
software. (Which I will call Z2 or Z3 from here onwards.) I will also describe
some aspects of the various installation procedures, since these are not always
explained in terms that are easy for less experienced programmers to easily
follow. In some cases, there are a several different ways to implement the Z
system, and these options are nor always obvious. The installation information
also assumes that the installer has the source code of his BIOS available. It
is possible to install Z3 without this code, and several ways around this
problem are suggested.
At the time that the
in Issue 1 was written, I did not have the most
recent CP/M User Group Library Catalogue, and the one that I had included the Z2
disks. I assumed that this was the most recent upgrade of the Z system, and
sent off my disks for the suite, (which occupies some 13 – 8in. disks and is
between 2 and 3 Mb of software !) I also sent off for a new library catalogue.
When it came I found chat Z3 was available too. (Occupying another 2-3 Mb of
disk space.) I probably drove poor Derek Fordred, the Librarian mad with so
many requests for copies. Anyway, I resolved the confusion in my mind about the
references to Z3 in the SB180 articles in BYTE, and ended up with a lot of disks
full of programs.
There were a few weeks in between getting Z2 and Z3, which was useful, because
the installation information with Z2 is rather more descriptive, and the
installation less complex. Coming to Z3 after Z2 made the process much easier.
I think that lets experienced programmers starting straight off with Z3 would
find the task rather difficult.
The original ZCPR/CCPZ brought the ‘Path’ concept to CP/M, displayed the USER
number in the Prompt, and displayed the name of files being erased, and added a
few extra useful features to CP/M which did greatly help make the system more
friendly. Further expansion appeared to be restricted by the memory space
allocations. The CCP and BDOS sizes were required to be kept to 2k and 3.5k for
compatibility. The BIOS was the only place where extra features could be added,
but these would be system specific, such as the screen edit, paging and dump
features available in the BIOS’s that we use on 80-BUS equipment.
The Z systems were written by Richard Conn, in the USA, and made available to
all via the CP/M User Group Network. I do not know if other similar systems
exist for CP/M, but the main feature of the Z system is that it uses extra
memory ABOVE CP/M, thus retaining the unique structure of CP/M, and retaining
compatibility with virtually all software.
The penalty to be paid for this is one of reduced T.P.A. size. Z2 requires 300H
bytes extra for implementation which is not too bad, but Z3 requires about 5-6k
for FULL implementation. It should be made clear however that it is entirely at
the discretion of the user or installer which features of Z2 or Z3 will by
implemented, and which omitted. Some features are virtually essential even on a
‘small’ system – i.e. one with say 2 floppy disks only, of about 300k capacity,
such a an Alphatronic PC, but others are much more suited to a ‘large’ system
– i.e. 10Mb Winchester, 512k Vdisk, 2 – 800k floppies. Then again, some
segments may be more or less desirable depending on the sort of application.
The Flow Control Package and Redirected I/O Package might fall into this
One way around this problem could be to have several operating systems
available, from a ‘No frills’ maximum T.P.A. CP/M where every bit of T.P.A. is