Preliminary Information about New Z-Com v2.0 (NZ-COM)
by Joe Wright
4 June 88
** NEW Z-COM RELEASED **
As Murphy always knew, if a Manual can be late, it will be. On �
the other hand we expect it to be worth the wait. Initial �
purchasers of NZ-COM will have the following information and the �
Manual will be mailed later. Thank you for your indulgence. �
SYSOPs. Please distribute this file as widely as possible. �
Thank you.
Most of you who are reading this may already have a fair grasp of �
the Z-System and how its many features work so well for us. I �
won't go into a lengthy explanation of it here. Z-System will be �
covered more fully in the Manual. In the meantime, almost any �
material you read about Z-System is generally applicable to New �
Z-Com v2.0.
1. Introduction:
NZ-COM, like its predecessor Z-Com, will allow the user to �
install Z-System on his CP/M 2.2 system automatically, without �
any programming or assembly. You will have it running on your �
computer in seconds. This is where the similarity ends.
NZ-COM will allow you to customize your operating system �
environment in ways you could have only dreamed about. You can �
change operating systems at any time, even in the middle of a �
multiple command line. You can do it manually from the command �
line or automatically from within alias or menu command scripts �
using flow controls depending on system conditions.
You can change the whole operating system or any part of it. You �
can switch from one command processor to another or from one DOS �
to another with a simple command.
Need more memory temporarily for a specific application? Simply �
load a new system without IOP or RCP and FCP if not needed, run �
the memory hungry application (PerfectCalc comes to mind) and �
when you're finished, load up your normal system again. All this �
is done in seconds with one multiple command.
Using NZ-COM is really simplicity itself. You don't need source �
code. You don't have to assemble or link anything. You don't �
even need SYSGEN or DDT to get NZ-COM running. You don't have to �
'hack' on anything (unless you really want to).
If you have a floppy system, copy the distribution files to a �
work disk at put the distribution disk away. If you have a hard �
disk system, I suggest you copy these files to the A0: partition �
of the hard disk. NZ-COM will work from any drive and user but �
A0: is preferred and will speed things up considerably.
Getting NZ-COM running the first time is a two-step process �
almost too easy to talk about. First use MKZCM.COM to define the �
system you want to build and then use NZCOM.COM to build it. �
Here's how:
A>MKZCM NZCOM<cr>
MKZCM will present a full screen describing a full-up Z-System �
for your computer. For the sake of argument, let's say you like �
it like that. Press 'S' for save and MKZCM will create two files �
for you, NZCOM.ZCM and NZCOM.ENV. Second step:
A>NZCOM<cr>
In about three shakes of the old lamb's tail, NZCOM will have �
loaded seven or so modules, written two files and given you the �
Z-System A0:BASE> prompt. You are now in the world of the �
living. You have a fully functional full-featured Z-System at �
your disposal. You have arrived!
One of the primary features of Z-System is the TERMinal �
CAPabilities (TERMCAP or TCAP) segment in the environment. As �
delivered, NZCOM installs a minimum Lear-Siegler ADM-3A tcap. �
This will suffice for most Osborne and Kaypro computers and for �
most Televideo and Wyse terminals and many others. If your �
terminal doesn't like ADM stuff or has more capability, now is a �
good time to create your own NZCOM.Z3T file. Use TCSELECT NZCOM �
and choose your computer or terminal from the list. You can load �
the resulting descriptor with NZCOM NZCOM.Z3T (or of course with �
LDR or JetLDR).
NZ-COM is delivered with a minimal NZCOM.NDR Named Directory �
module naming A0:BASE and A15:ROOT. This file is loaded �
automatically by NZCOM whenever there is space available for it. �
You may use MKDIR NZCOM.NDR to modify this file to taste or to �
make new ones.
2. Practice:
Now that we know we have Z-System, let's play around a little. �
Type MKZCM<cr> again and get the system environment map display. �
You will note that each of the segments have an address as well �
as a definite size. MKZCM calculates the addresses of the �
segments based on the CBIOS address (where your computer's BIOS �
really starts) and the sizes of the various segments. The order �
of the segments is fixed by MKZCM but their sizes are definable �
by you. You may lengthen, shorten or eliminate a particular �
segment by defining its size.
Let's define a really small (large TPA) system. Note the TPA �
size report near the bottom of the screen. We need CCP, DOS and �
BIO segments as they are for the present. Leave them alone. The �
IOP (12 records) is the first candidate for elimination. Type �
'4'. Now type '0' and return. The new display will show no IOP �
and a TPA 1.5k larger. Continue with selections 5, 6, and 7 for �
RCP, FCP and NDR and notice how the addresses and the TPA size �
change. Due to a technicality which requires our BIO segment on �
a page rather than record boundary, you will not gain TPA by �
eliminating the SHS Shell Stack segment. Leave it at 4 x 32.
Now type 'S'. You will be asked for a filename. Type 'SMALL' and �
return. MKZCM will create SMALL.ZCM and SMALL.ENV in the current �
directory. Now type NZCOM SMALL.ZCM and return. Voila, mesdames �
et messieurs, the Minimum Z-System. You will note (run MKZCM �
again) that the difference of the real CBIOS address and our NZ-�
COM Bios address is 400h or only 1k. That is the total overhead �
of Z-System. Whithin 1k you get multiple commands, the Z3 �
messages, external Path and FCB, the Wheel, the Z3 environment �
and termcap as well as a full 4-entry shell stack. Still a full-�
capability Z-System and only 1k larger than your old CP/M system. �
Magic. You return to the full-up system with NZCOM<cr>.
3. What's Going On Here?
NZ-COM (and Z3PLUS*) is a little more than just cute. It is a �
true advance of the art. Operating systems and segments thereof �
have, until now, been 'black' magic. The OS was just something �
you learned to live with. From the largest mainframes to the �
most modest micros, users had to simply take what the got and do �
the best they could with it. No more. The New Z-System puts a �
definite end to that. The User, not just HAL or BigSoft, �
determines his own operating system environment. The User is not �
stuck, either, with his last best choice. Any part of NZ-COM can �
be modified in many ways and at any time by the User from the �
command line or from alias or menu command script. The New �
World.
NZ-COM consists of two Major command files, MKZCM.COM and �
NZCOM.COM, a selection of Z-system ReLocatable (ZRL) files and a �
number of utility command files. We have already touched on �
MKZCM and NZCOM. The ZRL files contain the building blocks of �
the system. There are six of them contained in NZCOM.LBR:
NZCPR.ZRL This is Jay Sage's ZCPR34 Command Processor
NZDOS.ZRL This is Dennis Wright's ZRDOS at version 1.9c
NZBIO.ZRL Mini-BIOS for warm-boot of NZ-COM (2 records)
NZIOP.ZRL Dummy IOP structure
NZRCP.ZRL The Resident Command Processor
NZFCP.ZRL The Flow Control Processor�
ZRL files are actually REL files which can be produced by many of �
our favorite assemblers. They are renamed to ZRL to avoid the �
temptation to run a standard linker on them. These files use a �
multiple Named COMMON Block construct which a normal linker �
simply can't handle. Only NZCOM, Z3PLUS or JetLDR have any �
chance at these files.
NZ-COM uses a data structure known as an environment descriptor, �
Z3ENV to the initiated, for its operation. Z3ENV contains or �
implies the addresses and sizes of all Z-System segments as well �
as other data used by the command processor and Z3 utilities to �
determine or change system status. Z3ENV fully describes a �
particular system for NZ-COM.
The output files from MKZCM (name.ZCM or name.ENV) define a �
complete and explicit system in terms of the environment �
descriptor. NZCOM can read either of these files and determine �
how (or whether) to make any changes to the current system. You �
will note that .ZCM files are actually ASCII text in the form of �
a standard symbol table. You might edit this file to fine-tune a �
system more to your liking.
The actual programs contained in the .ZRL modules use Z3ENV for �
all inter-module references. In this way a newly loaded RCP can �
find the address of the command processor and other segments of �
interest.
NZCON.Z3T and NZCOM.NDR are binary segments which are not address �
sensitive. They can be loaded anywhere. If you already have Z3T �
and NDR files for your current Z3 system, you may simply rename �
them for use under NZ-COM.
4. What's REALLY Going on Here?
Once you play around a little and get used to what goes on, you �
will notice NZCOM searches an LBR for its files unless told not �
to. You may put any of these files into NZCOM.LBR or any other �
LBR and get them from there. Although it costs one directory �
search to open an LBR, subsequent accesses of the LBR do not go �
the the directory and are, therefore, quick. If you get �
conscientious, you can place the ZCM (or ENV) files in the �
library and eliminate that search. If you get really �
conscientious and ensure that the LBR occupies contiguous (or �
contemuous) allocation blocks on your disk, it flies.
For you 'speed at any cost' types, NZCOM will build your favorite �
system an create a single ZCI image file of it (name.ZCI). This �
system can be loaded in the twinkling of an eye, without �
reference to even the LBR. No free lunch. Each of these ZCI �
files are 10 or 12 k long, costing disk space.
NZCOM is also a hot package loader. It can load any of the �
system modules individually or in groups. As mentioned earlier, �
NZCOM looks for its packages in an LBR file unless you tell it �
otherwise. You tell it 'otherwise' with an explicit DU: or DIR: �
reference. Consider the possibilities.
NZCOM NZRCP.ZRL
NZCOM will open NZCOM.LBR, read and load NZRCP.ZRL from it. If �
you want to load a file from disk, without reference to the LBR, �
the command might be:
NZCOM A6:NZRCP.ZRL or NZCOM WORK:NZRCP.ZRL
NZCOM supports DU: references under CP/M and either DU: or DIR: �
references under NZ-COM.
Let's get really fancy and consider that we have a seperate LBR �
for descriptors, NZCOM.LBR for the modules and some loose files �
on the disk. We can build a system this way.
This will get TEST.ZCM from B0:DESC.LBR, get NEWRCP.ZRL as a disk �
file from A0: and then open A15:NZCOM.LBR for the rest of the �
modules required for the new system.
5. Conclusion
This short note is not complete, and is perhaps too technical. �
We will wait for the Manual (75 pages by now!) for a more �
complete description. The real purpose of NZ-COM is to present �
to the normal user of Z80 computer systems, not just to the �
'techie' developer, the latest and best operating system �
environment possible. I believe that it can do just that.
I am reminded that some of you don't actually own NZ-COM yet, and �
can't really follow these examples on your own computers. �
Fortunately for both of us, this situation can be remedied almost �
at once for the price of a good dinner. At $69.95, NZ-COM will �
not upset your stomach, is high in nutrients and has no �
cholesterol. Unlike a good dinner, NZ-COM will keep you �
satisfied for more than eight hours. Guaranteed. Low-fat �
software..(Somebody, Stop him!).
If none of this has whetted your appetite, then I simply don't �
know what to tell you. If, on the other hand, I have created a �
certain longing or even hunger in the pit of your stomach, please �
send me the price of a good dinner and we will both be satisfied. �
(Ok, ok. I quit.)
* Z3PLUS by Bridger Mitchell of Plu*Perfect Systems is similar �
in many respects to NZ-COM and presents the New Z-System to CP/M �
3.0 users of Commodore 128, Osborne Executive, Morrow MD-11 and �
others. Also $69.95 from Alpha Systems.
