Scor­pio News

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 article 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.

System Concepts

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 category.

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