The Computer Journal, Issue 43

Z-System Corner

© Jay Sage

Reproduced with permission of author and publisher.

This time my column is going to be quite short. In response to my requests, a number of authors have submitted some very interesting articles, but there has not been enough space to print them. I want to make sure that those articles are not delayed further. One of them is on the superb LSH history shell by Rob Friefeld, who has contributed quite a number of excellent Z-System programs (SALIAS, VCOMP, and BCOMP, to name a few). You should not miss that article.

After working first with the original Z-System history shell (HSH by Michael Rubenstein) and then with EASE by Paul Pomerleau, it occurred to me that it would be even nicer to have a full-screen history shell. What I envisioned was bringing the full resources of a wordprocessor to bear on the command transcript, so that commands could be easily viewed, modified, reordered, and regrouped. If the history file were a standard ASCII file, then one could massage the file with a standard editor or even prepare 'history' scripts in advance for special purposes.

After seeing the splendid full-screen work Rob Friefeld had done in his SALIAS (Screen ALIAS editor), I asked him if he would take on the task of writing such a history shell. He did, and he has done a splendid job. I would, therefore, like to publicly take credit for that all-important management skill of asking the right person to do a job!

Software Update Service

While Echelon was still in business marketing the Z-System, they offered a very nice product called SUS or Software Update Service. People who have modems and a nearby Z-Node or RCP/M system generally do not have much trouble picking up the latest releases of public-domain Z-System and general CP/M software. However, for those who do not have modems or for whom the nearest Z-Node is an expensive long-distance call, obtaining a full set of Z-System tools or keeping up with new releases is much more difficult. The Echelon SUS was designed to solve that problem by making the material available on diskette by mail. It was a disk subscription service, and roughly every month subscribers would get a diskette full of public-domain software.

I am happy to announce that SUS is coming back, thanks to the urging and energy of Chris McEwen, sysop of the Socrates Z-Node (#32), in Plainfield, NJ. Chris and Bill Tishey, together with Sage Microsystems East, will be offering an even more extensive service than Echelon's. Bill Tishey, as most of you know, has for some time been maintaining a complete catalog of Z-System programs (ZFILESnn.LST) and a compendium of HLP files covering all of them. At frequent intervals, Bill releases an update LBR with all the new help files. Now, in addition to that service, Bill will be putting together diskettes with the software as well as the documentation.

This means that you will be able to purchase diskettes with the complete set of Z-System programs and/or subscribe to a monthly update service. Bill and Chris will be handling most of the diskette production; SME will handle the orders and bookkeeping and will produce diskettes in the few formats that Chris and Bill cannot handle (8" IBM SSSD, NorthStar hard-sector, and Amstrad 3").

We have not yet worked out all the pricing details for all the options, but by the time you are reading this column, we will have flyers available with all the information. Just drop me a letter or postcard, or leave a message for me in any of the ways indicated in the sidebar to this column, and I will get a flyer to you. To give you some idea of what we are talking about, a 6-month SUS subscription to a US address will probably be $48 ($8 per disk) and a year's subscription $72 ($6 per diskette). As you can see, we are trying to keep the price very low. We really want all of you to be able to get and use all these wonderful programs.

Fully Customizing NZCOM

My technical topic for this time will be about designing fully customized NZCOM Z-Systems. I have always been satisfied with the systems that can be produced so easily using the MKZCM (MaKe nZCoM) menu-driven utility, and so I never really delved into this area very much. About a week or so ago, however, Dave Goodman brought the problem to me. He has a NorthStar Horizon with an add-on hard disk, and the operating system has a ROM stuck somewhere in the middle of the address space. That left some disjoint blocks of free memory, and Dave really wanted to make use of all the space. I told him my standard answer to that problem.

In section 5 (especially subsection 5.2.3) of the NZCOM manual, I point out that the NZCOM system is defined by a descriptor file and that this file (with type ZCM) is a pure ASCII file that can be edited with one's favorite text editor. The manual recommends that every one make certain changes so that the descriptor will properly reflect the user's hardware environment, such as the disk drives available and the characteristics of the system's printer and terminal.

I did not actually come out and say it explicitly, but there is an implication that other values in the ZCM file can also be changed. The truth is, I believe, that I avoided this subject in part because I was not entirely sure which values could and which values could not be changed. My suggestion to Dave Goodman was that he experiment with designing a custom memory map for his system, edit the values into the ZCM file, and see what happened when he tried to load it.

Dave's report back to me, now confirmed by my own experiments on my Televideo 803H, indicated that ALL values can be changed. The only requirement is that the values provide a memory map with no modules overlapping. When you use MKZCM to design the system, it takes over the responsibility for generating a valid memory map; if you do the design yourself, you better be careful.

A Helpful Utility

This suggests a very nice utility program that some thoughtful soul could contribute to the community. This utility (let's call it ZMAP) might do a number of helpful things. First, it could display, perhaps in some graphical or semi-graphical way, the memory map of a Z-System, the one actually running or one specified in the form of a ZCM or ENV file (and maybe even the Z3PLUS descriptor file of type Z3P). Present utilities, such as SHOW (ZSHOW) and Z3LOC, list the module addresses in a fixed order, not in order of increasing memory address. Thus they are not very helpful in determining if there are gaps or overlaps in the map. Ideally, ZMAP would flag any such defects or potential defects in the map so that they could be corrected before they cause harm.

The final item on my wishlist - and this might better be implemented in a second, independent program (ZDESIGN perhaps) - would be a general Z-System designer, along the lines of MKZCM but without its restrictions. One would be able to specify the order of all the modules in memory and their sizes. Given the highest memory address available, the program would then figure out and display the memory map. One should be able easily to alter the order of the modules, and one should be able to override specific addresses to create gaps if necessary (but not to force overlaps). Once the desired system has been designed, the program should write out a ZCM or ENV file for it. Such a program is a good candidate for implementation with a high level language such as BDS Z or Turbo Pascal. And it sure would have helped me with the experiments that I am about to describe (several mistakes resulted in crashes).

My Experiments

Fig. 1 shows a printout of the standard NZCOM.ZCM file on my Televideo 803H. It has already been customized in several ways using MKZCM. First, it allocates a 4-record VBIOS. I use a version that fixes the 803's faux pas of clobbering the index registers during BIOS calls and implements a check of the Z-System drive vector for BIOS disk-select calls as described in a previous column. It also has room for a 20-record RCP, which allows me to use a full-featured RCP with Carson Wilson and Rob Friefeld's resident history shell, CLED (see RCPZRL11.LBR on Z-Nodes).

E606 CBIOS      0080 ENVTYP     E3F4 EXPATH     0005 EXPATHS    D300 RCP
0014 RCPS       0000 IOP        0000 IOPS       DD00 FCP        0005 FCPS
DF80 Z3NDIR     0023 Z3NDIRS    E400 Z3CL       00CB Z3CLS      E280 Z3ENV
0002 Z3ENVS     E200 SHSTK      0004 SHSTKS     0020 SHSIZE     E380 Z3MSG
E3D0 EXTFCB     E4D0 EXTSTK     0000 QUIET      E3FF Z3WHL      0004 SPEED
0010 MAXDRV     001F MAXUSR     0001 DUOK       0000 CRT        0000 PRT
0050 COLS       0018 ROWS       0016 LINS       FFFF DRVEC      0000 SPAR1
0050 PCOL       0042 PROW       003A PLIN       0001 FORM       0000 SPAR2
0000 SPAR3      0000 SPAR4      0000 SPAR5      BB00 CCP        0010 CCPS
C300 DOS        001C DOSS       D100 BIO        0000 PUBDRV     0000 PUBUSR

Figure 1.
The ZCM descriptor file for the normal NZCOM system I use on my Televideo 803H computer.

I decided to be cautious, especially after one of my new system designs caused the system to hang, and I made a series of systems, each different from the previous one in a relatively small way. I am not going to show you all the steps along the way but will go right to the most radically different version. See Fig. 2. If you look carefully, I think you will find that only the command line buffer (Z3CL) is still in the same place as it was in the original system (but it is bigger now).

E606 CBIOS      0080 ENVTYP     E3F4 EXPATH     0005 EXPATHS    D700 RCP
0014 RCPS       0000 IOP        0000 IOPS       D480 FCP        0005 FCPS
D200 Z3NDIR     0023 Z3NDIRS    E400 Z3CL       00FB Z3CLS      E180 Z3ENV
0002 Z3ENVS     E100 SHSTK      0004 SHSTKS     0020 SHSIZE     E280 Z3MSG
E2D0 EXTFCB     E300 EXTSTK     0000 QUIET      E2FF Z3WHL      0004 SPEED
0010 MAXDRV     001F MAXUSR     0001 DUOK       0000 CRT        0000 PRT
0050 COLS       0018 ROWS       0016 LINS       000F DRVEC      0000 SPAR1
0050 PCOL       0042 PROW       003A PLIN       0001 FORM       0000 SPAR2
0000 SPAR3      0000 SPAR4      0000 SPAR5      BA00 CCP        0010 CCPS
C200 DOS        001C DOSS       D000 BIO        0000 PUBDRV     0000 PUBUSR

Figure 2.
A radically reconfigured NZCOM system produced by manually editing the ZCM file.

Perhaps you are wondering why I didn't make the most dramatic demonstration possible by changing absolutely every address (and perhaps size, too). Well, there was an extra constraint that I was exploring with this system. I am running ZDDOS, and I have specified that the clock driver be loaded into the so-called user buffer. I have even applied the NZCOM patch (NZCOMPAT.HEX) that comes with the ZSDOS/ZDDOS package so that when new system configurations are loaded, the clock driver will be reconnected to the DOS automatically without the need for running LDTIM again.

If you know a lot about Z-System, you will know that there is no such thing as a user buffer! The user buffer is a special creature of NZCOM; it is not defined in the Z-System environment descripter (or - look closely - in the ZCM file). How, then, does one determine where this special gap in the memory map of an NZCOM system is located? That is exactly what I wondered myself. I could have called ZSDOS authors Cam Cotrill or Hal Bower and asked them how they inferits location, but I decided to experiment instead. What I found after various trials and errors was that the NZCOM patch seemed to be happy and able to find the LDTIM clock module so long as the command line buffer stayed in the same place. Apparently, the assumption is made that the user buffer is the memory from 100H above the start of the command line buffer up to the real CBIOS (E400 to E5FF in my case).

I did not perform exhaustive tests of this hypothesis. Let us just say that it is not terribly prudent to try to make use of a 'user buffer' with a fully customized system. It would be wiser to design the system with a gap below the CBIOS for the clock driver and to create a version of LDTIM with an explicit load address. The NZCOMPAT patch should be omitted from NZCOM if such custom systems are going to be used.

A Few Bugs

There were a few bugs in NZCOM that surfaced during this testing that suggest that NZCOM.COM was not quite designed to work rigorously and to handle the most general system loading situations. Sometimes I found that NDR modules became empty, and the command search path was rarely preserved with these systems. Code-containing modules, such as the FCP, RCP, DOS, and so on, cannot be moved from one address to another. If their starting address changes, the code must be reloaded fresh from the ZRL file. On the other hand, modules that contain data, such as the NDR, shell stack, path, message buffer, and so on, can and should be moved to any new address, so long as there is room for the old contents in the new home.

NZCOM sometimes failed to do this. Maybe now that I have uncovered these small problems, I can pass the information on to Joe Wright, and he can fix up the code to handle these situations.

[This article was originally published in issue 43 of The Computer Journal, P.O. Box 12, South Plainfield, NJ 07080-0012 and is reproduced with the permission of the author and the publisher. Further reproduction for non-commercial purposes is authorized. This copyright notice must be retained. (c) Copyright 1990, 1991 Socrates Press and respective authors]