Thanking Dreas Nielsen for his letter reminds me that Art Carlson and Iì
would like very much to start up a Z-Letters feature in TCJ, a kind ofì
letters-to-the-editor section specializing in Z-System questions, comments,ì
discussion, and ideas. I am willing to handle answering or otherwiseì
responding to those letters, but I will depend on you readers to send themì
in. And rest assured that we are not looking only for letters like Dreas'sì
containing brilliant suggestions. A good set of simpleminded questionsìèwould be quite well appreciated, thank you. They would help us a great dealì
in learning what aspects of Z-System are confusing to users so that we canì
try to clarify them.
New ZSIG Releases
-----------------
We have quite a few excellent new programs to release on ZSIG diskettesì
this month. I have not yet finalized exactly what will be included onì
release diskettes #2 and #3, but I don't want to pass up this opportunity toì
publicize them.
First of all, I am very happy to report that all the programs Iì
proposed two issues back have now been written, and I will describe themì
first.
K;S4;I4
FCP10.LBR
This is the new flow control package (FCP) that I wrote with valuableì
assistance from Howard Goldstein (New Haven, CT). This program wasì
described in some detail in the last column, so I will not say too muchì
about it here. The two most important innovations are 1) the additionì
of AND and OR commands and 2) the FCP's ability to load and run IF.COMì
in high memory where it will not interfere with data in the beginning ofì
the transient program area at 100H.
COMIF10.LBR
This is the companion transient IF processor that is intended to replaceì
IF.COM. Also described last time, it offers an enormous number of newì
test conditions and syntax forms. This one was also written by meì
together with Howard Goldstein.
SETPATH1.LBR
This is an extended version of the original PATH command. It allows oneì
optionally to add and remove path elements from the beginning or the endì
of the existing path. The path display is also improved. Robertì
Demrow, a fellow member of the Boston Computer Society CP/M Group wroteì
this one.
EDITND.LBR
Al Hawley (Z-Node #3 in Los Angeles) really went all out with tools toì
work with the named directory register (NDR). EDITND lets one edit theì
names directly in the NDR. Names and/or passwords can be added,ì
deleted, and changed.
SAVNDR.LBR
After you've edited the NDR, this program lets you save the results toì
an NDR file. Again by Al Hawley.è
LOADND12.LBR
The last in the Hawley set, this program can automatically update theì
names in the NDR using either the special file name system in LDSK or byì
loading an NDR file whose names are applied to the current floppy diskì
only.
The next ZSIG release will also include the following programs.
ZPATCH11.LBR
This is another masterpiece from Steve Cohen (Chicago, author of 'W',ì
the wildcard shell, on the first ZSIG diskette). It is by far the bestì
file patcher I have ever seen -- a real joy to use. Steve sure isì
clever when it comes to shells! Who would have thought to make a fileì
patcher into a shell? But this way one can run a command from insideì
ZPATCH and then return to one's exact place to continue working. Theì
'X' command in ZPATCH automatically runs the file one is currentlyì
patching (provided it is a COM file) so that one can see the effect ofì
the changes. Marvelous!
MEX2Z.LBR
This is yet another brainstorm of NAOG chief Bruce Morgen (who has quiteì
a stormy brain). MEX2Z and my adaptation of it for MEX-Plus, MEX+2Z,ì
give the MEX communication programs the ability to 'shell', that is, toì
run a Z-System command apparently from within MEX. For example, if youì
enter the MEX command line "CPM;CRUNCH FN.FT", you will exit from MEX,ì
the file will be crunched, and then you go right back into MEX. This isì
especially handy when you are trying to debug a MEX script. Bruceì
picked up on the very clever trick introduced by Ted Emigh in FINDERR,ì
namely, running a program that examines information left behind inì
memory by the program that ran before it. In this case it is the MEXì
command line buffer that is picked up. Even if you don't use MEX, it isì
worth looking at these programs just for their educational value.
FF10.LBR
I finally decided to do something about the shortcomings of FINDF, theì
utility for determining where files are located in your system. FF hasì
a 16-bit configuration word that can be patched (roll out ZPATCH!) toì
define which drives should be searched by default (this is particularlyì
useful when your constellation of drives has a hole in it, such as A, B,ì
C, and F). You can override the default drive list by specifying a setì
of drives to scan on the command line. A whole list of fileì
specifications can be given, and each one is automatically wildcarded,ì
saving the user a lot of typing. If you want to find all programsì
starting with "SD", just enter "FF SD". The "SD" turns into "SD*.*"ì
automatically. Similarly, "FF .LBR" will find all library files. "FFì
SD,.LBR" will find both.
PPIP15.LBR
è This is the next step in the evolution of PPIP (PPIP14 is on ZSIGì
diskette #1). The main addition is support for DateStamper time andì
date stamping. Having fallen in love with DateStamper, I just had toì
have some file copying tools that would preserve the time and dateì
information, so I added that capability to PPIP and to ZFILER.
ERRSET11.LBR
This little tool lets you either display the current or directly enter aì
new error handler command line. Strictly speaking, error handling inì
ZCPR3 is not performed by loading an error handling program but byì
executing an error handling command line. This command line is storedì
in a 16-byte string in the message buffer. When an error handler isì
installed by invoking its name manually from the command line, it writesì
only its name alone into that buffer. ERRSET lets you enter a completeì
error command line, such as A15:VERROR. By including an explicit DU: orì
DIR: form, the error handler will be found and loaded faster. On theì
other hand, ERRSET will let you enter the name of a nonexistent errorì
handler, so watch out. Power has its price. Written by yours truly.
R76;I8
Customizing Z-COM
-----------------
We now turn to the piece-de-resistance for this article -- a discussionì
of techniques for customizing Echelon's automatically installing Z-Systemì
package known as Z-COM. This will be the first of a two-part series. Thisì
time I will cover the more elementary aspects of the subject, thoseì
modifications that can be made by changing only data structures in the Z-COMì
files. Next time I will delve into customization techniques that involveì
serious hacking (such as modifying the Z-COM code itself).
I will begin with an overview of what Z-COM is, the philosophy behindì
it, the procedure for installing it on a particular computer, and how oneì
uses it to create a Z-System automatically. Then I will give an elementaryì
discussion of how it works and the structure of the COM file that magicallyì
transforms one's ordinary CP/M machine into a 'Z' machine. Next I will showì
you how to make some simple patches that eliminate the initializationì
operations that are performed by the startup file and make Z-COM come upì
ready to go instantly. This includes setting the wheel byte, defining theì
symbolic command search path, putting in the terminal capability descriptorì
(TCAP) for the user's terminal, installing the user's named directories,ì
installing an external error handler, and even setting up an initial shell.
With those techniques mastered, we can then go on to make changes toì
the system modules. The simplest of these is replacing the standard ZRDOSì
that comes with Z-COM with the latest-and-greatest Public-ZRDOS-Plus versionì
1.7. Slightly more complex is the replacement of the environmentì
descriptor (ENV) and the two command modules: the RCP (resident commandì
package) and the FCP (flow control package). For these changes we have toì
edit some configuration files, assemble new code modules, and install theì
new modules into the Z-COM file. By this point you will be ready toìègenerate and install a new version of the ZCPR3 command processor, anì
operation that requires one important extra step (a simple one, but one thatì
must not be overlooked).
Why Z-COM
Consider this situation. The Z-System is a wonderful replacement forì
CP/M, one that greatly enhances the utility and ease of operation of anì
8-bit Z80-compatible computer. I can't understand why anyone would notì
enjoy and benefit from its features and capabilities. However, installingì
it in the conventional fashion required changing the BIOS (Basic Inputì
Output System), the hardware-dependent part of the operating system. ì
Unfortunately, many (actually most) manufacturers consider their BIOS to beì
proprietary (or embarrassingly poorly written), and they refuse to releaseì
the source code. And even if they do make it available, perhaps for anì
extra fee, what if you do not know how to make the required changes toì
support the ZCPR3 command processor? Well, enter Z-COM.
Z-COM was the brilliant conception of Joe Wright, the nation'sì
preeminent BIOS writer (author of the BIOSes for the Ampro Little Board,ì
Micromint SB180, and the soon-to-be-available ON! computer from Oneac). ì
With Z-COM one does not need the BIOS source code because there are noì
changes to make in it. One doesn't even need MOVCPM. Z-COM runs on almostì
any standard CP/M 2.2 system, converting it in situ to a Z-System. Thereì
are a few CP/M 2.2 computers on which Z-COM will not work (usually becauseì
at least some part of their memory space operates in a funny way), but theì
great majority will. For those of you with CP/M version 3 (aka CP/M-Plus --ì
a real misnomer in my opinion), I'm afraid you are out of luck. CP/M 3 isì
fundamentally different from CP/M 2.2, and no one has yet been able toì
concoct magic powerful enough to transform it into a Z-System.
I hope my discussion here will inspire some of you to purchase Z-COM. ì
If it does, then see the ads in TCJ by Sage Microsystems East and Echelonì
for more information. I personally think that a modified Z-COM is the bestì
way to implement Z-System, because, as we will see by the end of this seriesì
of articles, it gives one far greater flexibility than with a manuallyì
installed system.
Installing Z-COM
Here is a brief description of how one gets Z-COM running on one'sì
system. The standard procedure goes like this. Take a freshly formattedì
disk, 'sysgen' the CP/M 2.2 operating system to it, copy onto it all theì
files on the Z-COM release disk, put this disk into drive A, and reboot theì
system either with the reset button or by entering control-c. Now enter theì
command "SUB ZCCOM". This starts a batch operation, and you can now sitì
back, relax, and watch your computer do all the work. Toward the end of theì
process, which takes a couple of minutes, a program called TCSELECT will runì
and ask you to choose your terminal from a large menu. The result will be aì
file called MYTERM.Z3T containing information about your terminal thatì
permits Z-System programs to perform screen operations without installation.è
What's Going On During Installation
In the first part of the installation process, the Z-COM systemì
creation program ZCLD.COM determines the memory address at which your BIOSì
operates and generates a corresponding Z-System. To do this, it reads in aì
number of special relocatable files (most with file type SPR, which standsì
for system page relocatable) and produces four new files: ZC.COM, ZCX.COM,ì
ZC.ENV, and ZC.CP. The first file, whose operation we will describe inì
detail below, is the one that transforms the vanilla CP/M system to theì
amaretto-double-chocolate almond Z-System with jimmies (if you don't knowì
what jimmies are, ask someone from Boston).
The second file, ZCX.COM, is a program that transforms you back. Why,ì
you ask, would one ever go back to vanilla after experiencing the ecstasy ofì
amaretto-double-chocolate-almond? Well, Z-System does have one significantì
drawback. You don't get all those great features for free. They cost aì
considerable chunk of TPA (transient program area) -- 5.5K in the case of Z-COM (though we will see next time how to reduce this if you are willing toì
forego some of the features). The smaller TPA has almost never caused anyì
problem with the programs I use, but some people do have problems, and it isì
nice to know that a simple "ZCX" command will bring back the old CP/M withì
its full-sized TPA. Next time I will explain how we can even change to aì
different Z-COM system with a larger TPA.
The third file, ZC.ENV, is the environment descriptor file for theì
system that ZCLD created. It is automatically included in ZC.COM, so itì
does not have to be loaded using LDR, but it is used by Z3INS to install theì
environment information into the utilities.
The last file, ZC.CP, does not even appear in a directory listing; itì
is hidden up in user area 15, out of harm's way. The user is not normallyì
concerned with this file, though if you want to create another Z-COM systemì
disk, you have to remember to copy it, as well as the others mentionedì
above, to the new diskette. We will discuss its purpose later.
How ZC.COM Works
As we said above, ZC.COM is the program that transforms your mundaneì
CP/M system into an exciting and powerful Z-System. How does it do it? ì
Several simple principles are involved.
ZC.COM is basically a loader program. The file itself consists of twoì
parts. The first page of code (100H to 1FFH) is the loader code. Theì
second part (200H to 2DFFH) is the memory image of a Z-System that is copiedì
into place by the loader. The process is like the 'big bang' theory ofì
creation -- the whole Z-System just appears complete in one operation!
The memory map of the ZCOM-System generated for my BigBoard I computer,ì
on which I performed these experiments, is shown in Fig. 2. Its real CP/Mì
BIOS is at E800H. The Z-System addresses were determined by running theì
utility SHOW.COM after Z-COM was loaded. The corresponding addresses in theìèZC.COM file were obtained by inspecting it with a debugger. Once a fewì
addresses (like the RCP and FCP, which have obvious headers), wereì
determined, the rest was obvious. The ZC.COM system image is at a constantì
offset from the real system. In this example, that offset is BA00H. If Z-COM is installed on a different system, the real system addresses and theì
offset value will be different, but the addresses of the system segments inì
the ZC.COM image will be the same. In general, the offset between theì
corresponding addresses will be 2E00H less that the address of the nativeì
How does this system function? If you are familiar with Z systems, youì
probably recognize all of the system components above except for the oneì
called 'virtual BIOS'. That is where the key to Z-COM lies. Remember, weì
needed a BIOS that would run below the Z buffers, but we had no way toì
relocate the actual BIOS. So instead we create a virtual BIOS -- a block ofì
code structured just like a real BIOS. It has a table of jump instructions,ì
one after the other, that perform the required BIOS functions: CBOOT, WBOOT,ì
CONST, CONIN, CONOUT, LIST, and so on. How does this virtual BIOS actuallyì
carry out those functions without knowing anything about the systemì
hardware? Easy! It simply jumps to the corresponding entry points in theì
real BIOS!
Well, it actually is not quite that easy. There are a few specialì
details that have to be taken care of. Most of the functions are performedì
as described above, but there are some important exceptions. The mostì
important one is the WBOOT, or warm boot, function. Normally when a warmì
boot is performed, the CPR (and often the BDOS as well) is reloaded from theì
system tracks of the A diskette. If that were allowed to happen here,ì
goodbye Z-System! ZC.COM would only work until the first warm bootìèoccurred, and then we would have to run it again. Not very satisfactory!
To prevent that from happening and to keep Z-COM running, the virtualì
BIOS 'traps' warm boot calls. That is a fancy way of saying that instead ofì
simply passing the call to the real BIOS it does the work itself. What doesì
it do? Well, it has to reload the ZCPR3 command processor to the properì
address, BC00H in this example. Since the ZCPR command processor does notì
reside on the system tracks, we have to get it from somewhere else. Joeì
Wright could have gotten it from records 2 through 17 in ZC.COM, but heì
chose instead to maintain a separate file with just the image of the commandì
processor. Remember the file ZC.CP that we mentioned earlier, the oneì
stashed away in A15:? That's it.
Although I don't know of any reason why CBOOT, the cold boot routine,ì
would ever be called once the computer was initially booted up, the CBOOTì
routine is also trapped by the virtual BIOS and vectored (another fancyì
word) to the same code as the virtual warm boot.
In Echelon's simpler auto-install package Z3-DOT-COM, which does notì
have support for Input/Output Packages (IOPs), the story would now beì
complete. The IOP, however, has to get first shot at some of the BIOS I/Oì
routines, namely console status, console input, console output, list output,ì
list status, punch output, and reader input. In a manual installation of Z-System with IOP support, the BIOS code would have to be modified. With Z-COM this is quite straightforward. The virtual BIOS calls to theseì
functions simply go (are vectored) to the appropriate entry points in theì
IOP module. The initial IOP code included in ZC.COM is just a dummy IOPì
that simply turns around and forwards the calls from the IOP to the realì
BIOS entry points.
Easy Z-COM Patches
Now that we understand what Z-COM is and how it works, we can start toì
make some changes. If you look at the STRT startup alias with Z-COM, youì
will see that it turns on the wheel byte, loads the TCAP and named directoryì
register, and sets up the symbolic search path. For our first set ofì
patches, we will eliminate the need for a startup alias. We will make theì
system come up fully tailored to our preferences, and we will save the timeì
wasted by the STRT alias.
The first step is to get Z-COM running and to use the utility programsì
to set it up as we like it. We will generally turn the wheel byte on (theì
STRT alias presumably already ran WHEEL to do that for us). We can set upì
our named directories using MKDIR and LDR or the new ZSIG named directoryì
editor EDITND. We can choose our path using the PATH command or the newì
ZSIG SETPATH utility. An external error handler can be defined in theì
message buffer by invoking the desired error handler manually at the commandì
line or by running the ERRSET utility (this can include a DU or DIRì
specifier to speed up the search for the error handler). Finally, if weì
want to, we can even invoke a shell, such as the history shell HSH.
Now all we have to do is clone this system using our favorite debugger. ì
If you can afford Echelon's DSD, I cannot recommend it highly enough. Itì
will quickly spoil you. On the other hand, I will describe here theì
procedure using Prof. Falconer's lovely DDTZ, a public-domain Zilog-mnemonicìèversion of DDT. Here is the sequence of commands to use. Don't forget thatì
the addresses that refer to the real system are the ones for my BigBoard. ì
You should make a table like that in Fig. 2 with the addresses for yourì
system and make the appropriate substitutions in the commands below.