home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CP/M
/
CPM_CDROM.iso
/
cpm
/
zcpr33
/
tcj
/
tcj32.mag
< prev
next >
Wrap
Text File
|
1994-07-13
|
49KB
|
922 lines
by
Jay Sage
June 6, 1988
As usual, I find myself with the deadline for this TCJ column fast
approaching, wondering how two months have passed so quickly. And, as
usual, I have far more material that I would like to talk about than I
will have time to put down on paper (or, should I say, disk). This
column is probably going to be shorter than average, just as the pre-
vious one was much longer, and some of the promised discussions will be
deferred still further. Given the reasons, you will be understanding I
hope: Joe Wright and I are in the process of putting the final touches
on the new releases of ZCOM and ZCPR34! By the time you read this, they
will definitely be available. Even if you usually find my columns a bit
too technical for your tastes, I hope you will read on as I describe
these two exciting developments.
I will not describe it here this time, but Bridger Mitchell has
very nearly completed code similar to NZCOM that will run on CP/M-Plus
systems. At last people with newer CP/M machines for which CP/M 2.2 is
not available will also be able to run Z System. And they will be able
to do it while retaining almost all of the good features of CP/M-Plus!
The New ZCOM
Two issues ago (TCJ #30) I described the status of the nascent
NZCOM. Things have developed considerably since then, and I can now
provide some specific details.
First some philosophical comments. This may sound rather strong,
but Joe and I both firmly believe that NZCOM is one of the most exciting
and remarkable developments in the history of microcomputer operating
systems. With all the computers we have had experience with, the opera-
ting system has been a static entity. You 'boot' up the computer, and
there you have the operating system, fixed and immutable. Few computers
offer more than one operating system. With those that do, the only way
you can get a different operating system is to 'reboot', which generally
involves inserting a new boot diskette and pressing the reset button.
And never do you get to define the characteristics of that operating
system. You just take what the manufacturer deigns to let you use.
With NZCOM the operating system becomes a flexible tool just like
an application program. You can change operating systems at any time,
even right in the middle of a multiple command line sequence. You can
do it manually, or alias scripts can do it automatically, in response to
conditions in the system! And you can determine which Z System features
are supported.
You can change the whole operating system or just a part of it.
Would you like a new command processor? No problem. With a simple com-
mand, NZCOM will load it. No assembly or configuration required. One
file fits all! That new CCP will continue to run until you load another
one. Want to experiment with a new disk operating system (we are play-
ing with several exciting new ones)? Again, no problem. NZCOM can load
them in a jiffy. This makes for a whole new world of flexibility and
adaptability, experimentation and education.
Need more memory to run a big application program? Fine. Just
load a small operating system while that application is running. When
it is finished, go back to the big system with bells and whistles like
named directories, lots of resident commands, or special input/output
facilities (such as keyboard redefiners or redirection of screen or
printer output to disk).
Until you try this system, it is hard to imagine how easy it is to
do these things. Gone are the days of taking source code (no source
code is needed), editing configuration files (you don't need an editor),
assembling (you don't need an assembler), and patching (you don't have
to know how to use the arcane SYSGEN and DDT). Simple REL files for a
particular module can be used by anyone on any system. Of course, if
you want to create custom modules of your own special design, you can
still do it, but this is no longer required, as it used to be. Hackers
can hack, but users can simply use!
Joe and I are really hoping that NZCOM will open the world of Z
System to the general community, to those who have no interest in learn-
ing to assemble their own operating system or do not have the tools or
skills. If you have been at all intrigued by the Z System (how could
you not have been?), now is your chance to experiment.
Getting NZCOM running is basically a two-step process, with each
step remarkably easy to perform. First you define the system or systems
you want. This is done with the program MKNZC (MaKe NZ-Com). Then you
load the Z System you want using the program NZCOM. The details are ex-
plained below. Some comments of interest to the technically inclined
are enclosed in brackets. Feel free to skip over them.
Defining NZCOM Systems
Here is how a person with a stock CP/M computer would go about
getting NZCOM going. [First technical aside: Ironically, those of us
who, with great skill and hard work created manually installed Z Systems
have a much harder job ahead of us. To use NZCOM effectively, we must
first strip out all the ZCPR3 code in our fancy BIOSs and get back to a
lean, Z-less system. I just spent the good part of an evening doing that
for my BigBoard I computer (though, to be fair to my programming exper-
tise, I should add that the hardest part was finding where I had stashed
the BIOS source code).] For the discussion that follows, we will assume
that the files in the NZCOM package have been copied onto a working disk
in drive A.
As we said earlier, the first step is to use MKNZC, an easy menu-
driven program, to specify the characteristics of our Z Systems. Its
output is a descriptor file that is used later to load the system. What
if you don't know enough yet about the Z System to make those choices?
Again, no problem. There is a standard (or, in computer language, 'de-
fault') system defined for you already, and we will start by making it.
We do that by entering the command line
A>MKNZC NZCOM
This will bring up a menu screen like the one shown in Fig. 1. The
only difference on your system will be in the actual addresses for the
modules, since they vary from computer to computer. Press the 'S' key
to save the configuration. MKNZC displays a message to the effect that
it is writing out the file NZCOM.NZC.
[Technical aside: Files of type NZC are NZCOM descriptor files.
They are simple text files, as shown in Fig. 2. For those of you who
write your own assembly language programs, you may notice a strong simi-
larity to the symbol or SYM file produced by an assembler or linker
(yep, identical). The symbols in this file define all the necessary pa-
rameters of the system to be created.]
From the values in Fig. 1, you can see that the default Z System
offers every feature available. When this system is running later, the
TPA (transient program area, the memory available for the application
programs that do your real work) will be 49.0k bytes. This value, of
course, is for my computer; as they say, "yours may vary." A 'k' or
kilobyte is actually 1024 bytes, so this is really 50,176 bytes or
characters. The original CP/M system, by the way, had a TPA of 54.25k
bytes, so we are paying a cost of 5.25k bytes for this spare-no-expense
Z System. As luxurious and opulent as this system is, it still leaves
plenty of TPA for most application programs.
Sometimes, however, we have an application program that is really
hungry for memory. Database managers, spread sheets, and C compilers
often fall into this category. So does the new WordStar Release 4. We
will now use MKNZC to define a minimum Z System for when we run those
applications. To give this version the name MINIMUM, enter the command
A>MKNZC MINIMUM
When the menu comes up, press key '4'. You will be asked to define the
number of records (128-byte blocks) to allocate to the input/output
package or IOP. Enter '0' and press return. Similarly reduce to zero
the allocations for the resident command package (RCP), flow command
package (FCP), and named directories register (NDR). You will be left
with the screen shown in Fig. 3. Press the 'S' key to save the
definition of this minimal Z System in the descriptor file MINIMUM.NZC
[shown in Fig. 4 for the technically inclined].
Notice that the TPA has grown to 53.25k, only 1k less than the
original CP/M system. Even with this meagre Z System, costing only 1k
of TPA, you get the following features (and more):
multiple commands on a line
the alias facility that provides automatic command se-
uence generation
automatic, user-defined search path for COM files
extended command processing (ARUNZ, described in TCJ
#31, for example)
error handling that tells you what's wrong with a bad
command and allows you to correct it
shells (menu systems, command history shell for saving
and recalling old commands, file-maintenance
shells, etc.)
terminal-independent full-screen operation via Unix-like
TCAP (terminal capabilities descriptor)
These are only two of a wide variety of possible Z Systems. As you
gain experience with NZCOM, you can fine tune the definitions to meet
all of your needs. For my BigBoard I computer, I have defined four sys-
tems. Two of them, called FULL and TINY, have the features shown in the
two examples here. A third one is called SMALL. Not quite as diminutive
as TINY, it sacrifices an additional 0.5k of TPA to retain the flow com-
mand package (FCP), which is so valuable in providing high levels of
command automation. Even my voracious application programs can usually
get by under this system.
Finally, I have a system called NORMAL, which, as the name implies,
is the one I use most of the time. It is the same as FULL but without
an IOP. The most common use for an IOP is to run keyboard redefiners
like NuKey. Most people like this feature, but splendid as NuKey is,
for some reason my style does not find much use for keyboard macros
(I've become a rather skillful typist and can generally type faster than
I can think of moving my finger to a special key), so I generally omit
the IOP and gain 1.5k of TPA.
Loading the NZCOM Systems
Having defined the systems above, we can now fire them up even more
easily. For the default NZCOM system, just enter the following simple
command:
A>nzcom
With no argument after the command name, NZCOM will load the system
defined with the name NZCOM. As it does this, you will see a signon
message on the screen, followed by a series of dots, each one indicating
that another module has been loaded. [Technical aside: If you want to
see more precisely what is going on, just add the option "/v" to the
command to select verbose mode. You will then get a screen display
something like that shown in Fig. 5. I'll have more to say about what
all this means a little later.]
After NZCOM starts running, it executes the START.COM program. This
is usually an alias command, a program that simply passes another more
complex command line on to the command processor. I will not explain the
details of START here, but after it finishes, Z System will be up and
running, waiting for your commands.
How NZCOM Works
---------------
This section is for the technically inclined, so if that's not you,
pretend there are square brackets around this whole section and skip
ahead to the next section. Here we are going to explain what some of
those verbose-mode messages mean and what NZCOM is doing to create the
system on the fly.
First NZCOM loads the descriptor file into memory. Among other
things, this file has the information about which system modules to load
and to what starting addresses. The first module loaded is the command
processor. It is loaded from the file NZCPR.REL, which has the code for
the command processor (ZCPR34) in so-called relocatable form.
There is some very interesting assembly/linkage razzle-dazzle that
goes on here. With the REL files one usually plays with, only the run-
time execution address of the code is unknown at assembly time and must
be resolved by the linker. Things are much trickier here. When the
command processor code was assembled, not only was its own run-time
starting address unknown, but the addresses of various other system com-
ponents, such as the message buffer and multiple command line, to which
it refers in countless places, are also unknown. Since there is no fixed
relationship between the addresses of the CCP and these other modules,
there is no way to define the addresses using equates in the code.
Put another way, when NZCOM converts NZCPR.REL into actual object
code, it must resolve not only the calls and jumps and data loads that
refer to other locations in the command processor but also those that
refer to the other system modules. Fortunately, advanced assemblers and
linkers -- including those from SLR Systems and a ZAS follow-on under
development by Alpha -- already have a mechanism to handle this problem.
It was Bridger Mitchell who recognized how this mechanism, called named
common, could accomplish what was needed here.
When code with symbols in named common is assembled, the correspon-
ding bytes in the resulting .REL file are marked not only for relocation
but for relocation with respect to a specific common block. The SLR as-
semblers support up to 12 named common blocks. NZCOM contains very so-
phisticated linking code that resolves the references to data items in
the common blocks, the addresses of which it gets, naturally, from the
NZC descriptor file.
Fig. 6 shows a partial listing of the file NZCMN.LIB, which is
referenced in a MACLIB statement in each module assembled for use by
NZCOM. Seven named common blocks are defined: _BIOS_, _ENV_, _SSTK_,
_MSG_, _FCB_, _MCL_, and _XSTK_ for the CBIOS, environment descriptor,
shell stack, message buffer, external file control block, multiple com-
mand line buffer, and external stack, respectively. Note that no common
blocks are defined for the RCP, FCP, or NDR. References to these package
must be made indirectly at run time, using data obtained from the en-
vironment descriptor in memory.
How does the NZCOM loader figure out that the file NZCPR.REL is the
command processor? You might think that it uses the name of the file,
but, in fact even if you had a copy of it called MYNEWCP.REL, NZCOM
would be able to load it just as well. The answer is that the source
code contains the directive
NAME ('CCP')
which gives the REL file an internal module name. It is this name that
NZCOM uses to determine what kind of module the code represents.
After the command processor is loaded, the other modules are loaded
in succession in similar fashion, except for two. The named directory
file NZCOM.NDR is a file that you can make or change with the standard
utility programs MKDIR or EDITNDR/SAVENDR. There is nothing in an NDR
file that requires relocation at all. The same is true for the Z3T ter-
rminal descriptor (TCAP) file. It can be created using the TCSELECT
utility.
When all the loading is done, a copy of the command processor ob-
ject code is written out to a file called NZCOM.CCP. This file is used
for subsequent warm boots, since we obviously cannot warm boot from what
is on the system tracks of the disk (the Digital Research command pro-
cessor is still there, after all). At this point we can resume the non-
technical discussion.
Changing NZCOM Systems
----------------------
Now that you have Z System running, you can start to work with it
and learn about it. I am not going to discuss Z System in general here;
the subject is much too extensive. One thing you can do is to get out
your back issues of TCJ and experiment with the programs described
there. Another is to buy the "Z System User Guide" published by Alpha.
That book describes the Z System from a less technical point of view
than Richard Conn's "ZCPR3, The Manual," also published by Alpha.
What I would like to discuss now is some of the ways you can use
the dynamic capabilities of NZCOM. First we will describe how you
change the entire operating system. For these examples we will assume
that you have been doing work in various directory areas on your system
and that you have set up named directories. Let's say you are in your
dBase II area now. Since you know that dBase II needs a lot of memory
to run efficiently (or should I say 'tolerably,' since it never runs ef-
ficiently!) and since (unlike WordStar 4, for example) it cannot make
use of any Z System features anyway, you want to load the minimum system
we created earlier. You can probably guess what the command is:
B2:DBASE>nzcom minimum
[More technical stuff: Fig. 7 shows the screen display you would
get with the "/v" verbose option on this command.] For the minimum sys-
tem NZCOM loads only a command processor, disk operating system, and
virtual BIOS. The other system segments disappear. This includes the
NDR or named directory register, so the prompt changes to
B2>
The START alias does not run this time. It runs only when NZCOM is
loaded from a non-NZCOM system (such as CP/M).
In general, when loading a new version of the operating system from
another that is currently running, NZCOM loads only the modules that
must be loaded, either (1) because they did not exist before or (2) be-
cause they are now at a different address or have a different size. For
example, when I load my FULL system from the NORMAL system to add an
IOP, only the CCP, DOS, BIOS, and IOP are loaded, since the RCP, FCP,
and NDR are in the same place as before and have the same size. When
modules do have to be loaded, files with the default names shown in Fig.
5 are used. Later we will discuss how you can load modules with other
names.
There are a number of system modules that never change in the pre-
sent version of NZCOM. (Yes, like the famous Al Jolson lines, you ain't
seen nothin' yet!) These include the environment descriptor, message
buffer, shell stack, path, wheel byte, and multiple command line buffer.
With the exception of module addresses in the environment descriptor,
data in these fixed system modules remain unaffected. This means that
if you had selected an error handler, for example, or a shell such as a
command history shell, they will still be in effect after a change of
system.
Because the multiple command line buffer is preserved through the
load of a new system, you can include NZCOM commands as part of multiple
command sequences, alias scripts, and shell (MENU, VMENU, or ZFILER)
macros. Thus, for example, you could have entered the command:
B2:DBASE>nzcom minimum;dbase etc.
In this case the operating system would have changed, and then DBASE
would have started running. I will not go into the technical details
here, but there are ways to write an alias script, which might be called
DB, that would check to see if the minimum system was already running
and, if not, automatically load it before invoking DBASE.
Nothing says the operating system can change only once in the
course of a multiple command line. You might have alias scripts that
change to a minimum system, run a specific command, and then reload the
normal system again. There is a time penalty associated with this
(though very little if you have the NZCOM files on a RAM disk), but the
result is that the application program sees a big TPA while it is run-
ning, but you always see a nice, full-featured Z System.
NZCOM does not even insist that you stay in Z System. On the con-
trary. On a cold load from CP/M it will build (if it does not exist al-
ready) a program called NZCPM that, when run from Z System, will restore
the original CP/M system.
[Technical aside: Even if you need absolutely every available byte
of TPA, you can still automate the process. You can use the submit
facility to run a batch job that exits from Z System entirely, runs an
application under plain CP/M, and then returns to Z System. You do have
to observe some precautions. For example, you have to make sure that
all command lines in the batch file that will execute while Z System is
not in effect are valid CP/M commands. Once the batch script has re-
loaded reloaded Z System using the NZCOM command, it can resume using
appropriate Z System commands, including multiple commands on a line.
Another factor to bear in mind is that NZCPM returns you to CP/M in
drive A user 0 no matter where you were when it executed. Since ZCPR3
(starting with version 3.3) writes its submit file to directory A0
rather than the current directory, there is no problem with continuing
operation of the batch file under CP/M. However, when you reload NZCOM
(it will be a cold load, including execution of START), you will not
automatically be back in your original directory. End aside.]
Changing Parts of the System
The NZCOM command is not limited to loading whole new operating
systems; with a slightly different syntax it can also load individual
system modules, rather like the LDR program in a manually installed Z
System. There are two important differences, however.
The first is that NZCOM loads code modules (IOP, RCP, and FCP) from
REL files rather than from absolute files such as SYS.FCP or DEBUG.RCP.
Absolute files can still be loaded using LDR, but this is undesirable
under NZCOM, since the addresses of the modules may change as different
systems are loaded. NZCOM has the advantage of using a single REL file
no matter which system it is being loaded into. In the future, RCPs,
FCPs and IOPs will be distributed in REL form instead of (or in addition
to) source code form. The .REL file is much smaller and can be used
without knowing how to assemble the code.
The second difference is that NZCOM can load command processors and
disk operating systems as well. This makes it very easy to change ver-
sions of the command processor (with or without security or named direc-
tory or submit support, for example) or to experiment with alternative
DOSs, such as Z80DOS or P2DOS. This will be a real boon to the develop-
ment of new operating system components, since one can test new versions
so easily and quickly.
For convenience, NZCOM can also load named directory files (of type
NDR) and terminal descriptor files (of type Z3T). This is so that you
do not have to have LDR.COM on your disk. On an NZCOM system, LDR is a
dangerous command, since it does not have safeguards against loading
absolute system components to addresses for which they were not assem-
bled. With an NZCOM system, you should remove LDR.COM from your disk.
Other NZCOM Features
--------------------
There are many more things that could be said about NZCOM that I
will save for another time. There is just one more that I want to men-
tion now, and that is the extra "Custom Patch Area" that can be defined
with MKNZC (see Fig. 1). This option in MKNZC allows one to establish
an area in protected memory just below the CBIOS (custom BIOS or real
BIOS). This area can be used by various operating system extensions that
one wants to preserve from one NZCOM system to another.
Because of the techniques it uses for patching the Z System onto
CP/M, NZCOM will not work when a resident system extension (RSX) is pre-
sent. Thus, for example, you cannot run NZCOM from inside a ZEX script
or if DateStamper or BYE is active in low memory (if they are loaded
above the CBIOS, there is no problem). I am presently using the patch
area for DateStamper. With NZCOM you can effectively have an above-BIOS
version of DateStamper without having to move your BIOS down.
I am also planning to experiment with putting BYE in the custom
patch area. I think this can be made to work, and it would permit NZCOM
to be used on my Z-Node (and I mean used actively -- so that the NZCOM
system can be changed even from a remote terminal!).
There are special facilities in NZCOM that I do not have the energy
to explain now whereby information about a currently running system can
be extracted before the new system has been loaded and used to initial-
ize the new system just before NZCOM turns over control to it. This al-
lows an RSX's hooks into the operating system to be maintained.
ZCPR Version 3.4
Now let's turn to the subject of ZCPR version 3.4, which will be
released along with NZCOM. Z34, as I will refer to it, is much more an
evolutionary step from Z33 than Z33 was from Z30. There are four new
features worth pointing out.
Type-4 Programs
The most important and exciting enhancement is the introduction of
what is called the type-4 program.
With Z33, I added support for a new kind of program to run under
ZCPR3. Programs designed to take advantage of the special features of
the Z System have, at the beginning of the code, a special block of data
called the Z3ENV header. This header identifies the program as a ZCPR3
program and contains the address of the ZCPR3 environment descriptor,
where all the information necessary to find out about the Z System fa-
cilities is available. It also contains a type byte. Conventional Z
System programs were of type 1. (Type-2 programs are similar but ac-
tually have the entire environment desciptor in the header. Programs
of this type are extremely rare. In some senses they are a holdover
from ZCPR2 and now obsolete.)
For the new type-3 program I added an additional datum in the Z3ENV
header: the starting address for which the code had been assembled or
linked. The command processor automatically loads the file to that
address before transferring control to it.
Type-3 programs are usually linked to run in high memory (for
example, 8000H or 32K decimal) where they do not interfere with most
data or code in the TPA. Programs that run as extensions of the
operating system (viz. history shells, extended command processors,
transient IF processor) or as the equivalents of resident programs
(viz. ERA.COM, REN.COM, SAVE.COM) are particularly suitable for imple-
mentation as type-3 programs. One cannot always foresee when these
programs will be invoked, and it is nice if the contents of memory at
the bottom of the TPA are not affected when they do run.
With type-3 programs one must choose in advance the address at
which they will run. If the address is too high, there may not be
enough room for them to load, and if too low, they are more likely to
interfere with valuable TPA contents. In most situations it would
clearly be preferable if the program could be loaded automatically as
high as possible in memory. I thought of this from the beginning but
compromised on the type-3 construct because it was so easy to code.
Joe Wright was not satisfied with this compromise. He soon wrote
an initial version of the type-4 program, which does relocate automati-
cally to the top of memory. With a lot of cooperation between us, we
have honed it to the point where it functions very nicely and does not
add very much code to the command processor.
Because type-3 programs run at a fixed address, albeit not neces-
sarily 100h, they can be assembled and linked in the usual fashion, and
the program files contain actual binary object code. Type-4 programs,
on the other hand, must be relocatable by the command processor at run
time. Thus object code alone is not sufficient.
One possibility would be to use a .REL file directly. This would
have been very convenient, but the code required to load a .REL file is
far too complex to include in a command processor running in a 64K mem-
ory segment. There is a less familiar relocatable type file known as
a .PRL (Page ReLocatable) file that, because it restricts the relocation
to page boundaries (and other reasons), is much easier to relocate.
A PRL file consists of three parts. The middle part is a standard
code image for execution at 100h. After this comes what is called a bit
map, where, for each byte in the code image, there is a bit of 0 or 1 to
tell whether that byte must be offset for execution at a different page.
The bit map is one eighth the length of the code image. Finally, one
page (256 bytes) at the beginning of the file serves as a header. This
header contains information about the size of the program so that the
code that loads it can figure out where the object code ends and the
bit map begins.
In the type-4 program, this header is extended to include the code
necessary (1) to calculate the highest address in memory at which the
program can be loaded and (2) to perform the code relocation to that
address using the bit map. The way this is accomplished is somewhat
intricate.
The command processor loads the first record of the type-4 file
into the temporary buffer at 80H as usual to determine the program
type. If it is type 4, the CCP then calls the code in the header. That
code calculates the load address and then (this clever idea was Joe's)
calls the command processor back to load the program code and bit map
into memory at the proper address. When this call is complete and con-
trol returns to the header code, it then performs the relocation of the
code image at the execution address in memory. Only then is control re-
returned to the command processor for initialization and execution of
the program.
The result of this tricky scheme is that most of the type-4 support
code that would otherwise have been required in the command processor is
in the header instead (this was my contribution to the type-4 concept).
Since a PRL file has a two record header anyway (almost all of which is
otherwise empty), you get to add this code for free.
Joe pointed out to me some dangers with my type-3 construct. Sup-
pose a type-3 program designed to run at 8000H is somehow loaded to 100h
instead. Any attempt to execute it is likely to have less than desirable
consequences, to put it mildly. This was not a serious problem with a
normal (at the time) ZCPR33 system. Since the command processor would
automatically load the type-3 program to the correct address, it took
some deliberate action by the user to create the dangerous situation de-
scribed. Of course, the poor fellow still running ZCPR30 who decided to
try out a type-3 program...
However, now that NZCOM is here, the user may very well decide to
drop back into CP/M from Z System to perform some tasks. In this situa-
tion, a type-3 program is a live weapon, just waiting to blow up the
system. The type-4 program poses a similar danger.
We have come up with two defense strategies. One can be implemented
in the program itself. There is code (TYP3HDR1.Z80) that can be placed
at the beginning of a type-3 program (based on ideas conceived indepen-
dently by Bob Freed and Joe Wright) that will verify that the code is
running at the proper address. This part of the code is, as it must be,
address independent (it uses only relative jumps). If the load address
is found to be wrong, a warning message is displayed and control is re-
turned to the command processor before any damage can be done. This is
the friendlier method, but it makes the programs longer.
The second defense method does not impose any overhead on the pro-
gram code. It is easier to use than the other method and it can gener-
ally be patched into existing type-3 programs in object form. It can
also be applied with type-4 programs, for which the first method cannot
be used (type-4 files begin with a relocation header and not with pro-
gram code, and the system must be prevented from trying to execute the
header when the program is invoked under CP/M).
With this method, one places a byte of C7H, the RST 0 instruction
opcode, at the beginning of the file. Execution of this instruction
causes a call to address 0, which induces a warm boot. This behavior
may be puzzling to the user, but at least it does no damage. How, then,
will such a program ever execute? The answer is that ZCPR34 checks the
first byte of a type-3 program to see if it is a C7H. If it is, the
command processor replaces it with a C3H, the JP instruction opcode. To
take advantage of this method, the program code must begin with a "JP
START" instruction in which the JP is replaced by RST 0 (note: you can-
not use JR START instead). The proper assembly language source code is
illustrated in Fig. 8. Note that the replacement of the RST 0 by a JP
is not required with a type-4 program since the header (which is where
this construct appears) is never intended to be executed as a standard
program, even under Z34.
The Extended Environment Descriptor and the Drive Vector
--------------------------------------------------------
The definition of the ZCPR3 environment descriptor has been modi-
fied and extended. I will not go into all the details here, but I will
describe the main changes.
First, to make some space available for additional important infor-
mation, the extended ENV eliminates definitions for all but one console
and one printer. Eventually there will be a tool (utility program) that
allows interactive or command-line redefinition of the characteristics
of these single devices so that you will actually have more rather than
less flexibility.
The extended ENV will now contain the addresses and sizes in re-
cords of the CCP, DOS, and BIOS (actually, the size of the BIOS is not
included). This information has been added to deal with problems in
some special operating system versions where the CCP and/or DOS do not
have their standard sizes of 16 and 28 records respectively, such as in
the Echelon Hyperspace DOS for the DT-42 computer. Future versions of
NZCOM, which will support variable CCP, DOS, and BIOS modules, will also
need this.
Finally, a long needed feature has at last been implemented; a
drive vector. The maximum-drive value in the ENV was not adequate in a
system with non-contiguous drives (A, B, and F, for example). Now you
can tell the system exactly which drives you have on the system, and the
command processor will do its best to prevent references to nonexistent
drives.
Ever More Sensible Named Directory Security
-------------------------------------------
With Z33 I made it possible to refer by drive/user (DU) to direc-
tories beyond the range specified by the maximum drive and maximum user
values in the environment provided the directory area had a name with no
assword. It seemed only reasonable that if a user could access the drive
by name, he should be allowed to access it by its equivalent DU as well.
The converse situation, however, was not handled according to simi-
lar logic. Suppose the maximum user was 7 but there was a password-
protected named directory for user 6. Under Z33 one had the anomalous
situation that the user could refer freely to the directory using the DU
form but would be pestered for the password if he used the (DIR) named-
directory form. This just didn't seem reasonable, and Z34 has corrected
this.
Extended ECP Interface
----------------------
With Z34 I have added an additional option similar to BADDUECP. The
BADDUECP option allows directory-change commands such as NAME: or DU:
that refer to illegal directories to be passed on to the extended com-
mand processor (ECP) instead of directly to the error handler. On my own
Z-Node, for example, I use the ARUNZ extended command processor to per-
mit references to reasonable facsimiles to the actual directory names to
work via alias scripts.
With Z33 attempts to execute a command containing an illegal wild-
card character or with an explicit file type would be flagged as errors
and passed directly to the error handler. With Z34 one has the option
(via the option BADCMDECP) to pass these forms of bad command to the ex-
tended command processor as well.
Here are a couple of examples of how this feature can be used with
the ARUNZ extended command processor. First, one can enter the following
script into the alias definition file ALIAS.CMD:
? help $*
Now when a user enters the command "?", he will get the help system in-
stead of an error message telling him that he entered a bad command.
You can also use this facility to allow further shorthand commands.
With the script definition:
DIM.Z3T ldr dim.z3t (or nzcom dim.z3t)
Now you can load the dim-video TCAP for your system simply by just en-
tering the name of the TCAP file. Using wildcard specifiers in the name
of the alias script you can make any command with a type of Z3T load the
corresponding TCAP file. Similarly, entering the name of a library (for
example, LBRNAME.LBR) on the command line could automatically invoke VLU
on that library. The same concept would allow one to enter the name of
a source-code file (for example, THISPROG.Z80 or THATPROG.MAC) to auto-
matically invoke the appropriate assembler (Z80ASM/ZAS or SLRMAC/M80 for
these two examples).
This feature opens another whole dimension for experimentation, and
I am sure that users will come up with all kinds of new ways to use it.
PLEASE NOTE: if this feature is implemented, you cannot use the old
version of ARUNZ that I so painstakingly documented in my last column
(alas, barely born and already obsolete). Previous versions of ARUNZ
used '?' and '.' for special purposes. Those characters were carefully
chosen because they could never appear in command names passed to ARUNZ,
but now they can! Therefore, in version 0.9H of ARUNZ I have changed
these characters to '_' (underscore) instead of '?' and ',' (comma)
instead of '.'.
That's it for this issue, I'm afraid. I still didn't get to a
discussion of defects in the shell coding for WordStar 4 (I hope these
will be corrected in version 5, which is apparently really in the works
at this time). My discussion of the ZEX in-memory batch processor and
the improvements I have been making to it will also have to wait still
longer. However, MicroPro has repeatedly said there will be no WordStar
version 5 for CP/M.
------------------------------------------------------------------------
1.* Command Processor CCP BD00 16 Records
2.* Disk Operating System DOS C500 28 Records
3.* NZ-COM Bios BIO D300 2 Records
4. In/Output Processor IOP D400 12 Records
5. Resident Command Proc RCP DA00 16 Records
6. Flow Control Processor FCP E200 4 Records
7. Named Directory Reg NDR E400 14 Names
8.* Environment Descriptor ENV E500 2 Records
9.* Shell Stack SHS E600 4 Entries
P. Custom Patch Area PAT 0000 0 Records
Customer's CBIOS TOP E800
Effective TPA size 49.0k
* Items 1, 2, 3, 8 and 9 are not changeable in this version.
Selection: (or <S>ave or <Q>uit) _
Figure 1. Screen displayed by the MKNZC program when run under CP/M.
This is the standard or default system definition.
------------------------------------------------------------------------
E806 CBIOS 0080 ENVTYP E6F4 EXPATH 0005 EXPATHS DA00 RCP
0010 RCPS D400 IOP 000C IOPS E200 FCP 0004 FCPS
E400 Z3NDIR 000E Z3NDIRS E700 Z3CL 00CB Z3CLS E500 Z3ENV
0002 Z3ENVS E600 SHSTK 0004 SHSTKS 0020 SHSIZE E680 Z3MSG
E6D0 EXTFCB E7D0 EXTSTK 0000 QUIET E6FF 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 0066 SPAR2
0042 SPAR3 003A SPAR4 0001 SPAR5 BD00 CCP 0010 CCPS
C500 DOS 001C DOSS D300 BIO 0000 PUBDRV 0000 PUBUSR
Figure 2. For the technically inclined, this is a listing of the con-
tents of the NZCOM.NZC system descriptor file produced by MKNZC.
------------------------------------------------------------------------
1.* Command Processor CCP CE00 16 Records
2.* Disk Operating System DOS D600 28 Records
3.* NZ-COM Bios BIO E400 2 Records
4. In/Output Processor IOP 0000 0 Records
5. Resident Command Proc RCP 0000 0 Records
6. Flow Control Processor FCP 0000 0 Records
7. Named Directory Reg NDR 0000 0 Names
8.* Environment Descriptor ENV E500 2 Records
9.* Shell Stack SHS E600 4 Entries
P. Custom Patch Area PAT 0000 0 Records
Customer's CBIOS TOP E800
Effective TPA size 53.25k
* Items 1, 2, 3, 8 and 9 are not changeable in this version.
Selection: (or <S>ave or <Q>uit) _
Figure 3. Screen displayed by the MKNZC program after eliminating the
IOP, RCP, FCP, and NDR modules in order to define a minimal Z System.
------------------------------------------------------------------------
E806 CBIOS 0080 ENVTYP E6F4 EXPATH 0005 EXPATHS 0000 RCP
0000 RCPS 0000 IOP 0000 IOPS 0000 FCP 0000 FCPS
0000 Z3NDIR 0000 Z3NDIRS E700 Z3CL 00CB Z3CLS E500 Z3ENV
0002 Z3ENVS E600 SHSTK 0004 SHSTKS 0020 SHSIZE E680 Z3MSG
E6D0 EXTFCB E7D0 EXTSTK 0000 QUIET E6FF 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 0066 SPAR2
0042 SPAR3 003A SPAR4 0001 SPAR5 CE00 CCP 0010 CCPS
D600 DOS 001C DOSS E400 BIO 0000 PUBDRV 0000 PUBUSR
Figure 4. For the technically inclined, this is a listing of the file
MINIMUM.NZC, which describes a minimum-size version of an NZCOM system
for the computer in Figs. 1 and 2.
------------------------------------------------------------------------
A>nzcom /v
NZCOM Ver 2.0 Copyright (C) 1987-88 Alpha Systems Corp 21 Jan 88
Input buffer start 1C00
Read buffer start 1D00
Write buffer start 3D00
Loading A0:NZCOM.NZC
Loading A0:NZCPR.REL for BD00 at 3D00
Loading A0:NZDOS.REL for C500 at 4500
Loading A0:NZBIO.REL for D300 at 5300
Loading A0:NZIOP.REL for D400 at 5400
Loading A0:NZRCP.REL for DA00 at 5A00
Loading A0:NZFCP.REL for E200 at 6200
Loading A0:NZCOM.NDR for E400 at 6400
Loading A0:NZCOM.Z3T for E580 at 6580
Writing A15:NZCOM.CCP
Booting NZ-COM...
Figure 5. This is the screen display produced by NZCOM as it loads the
default system definition NZCOM.NZC with the verbose option.
------------------------------------------------------------------------
Named COMMON declarations start here
For compatibility, these are the same names used by Bridger Mitchell's
JetLDR
common /_BIOS_/
CBIOS: ; Customer's BIOS address
common /_ENV_/
Z3ENV: ; Z3 Environment descriptor
Z3ENVS EQU 2 ; Size (records)
RCP EQU Z3ENV+12
RCPS EQU YES ; Used as existence test, not size
FCP EQU Z3ENV+18
FCPS EQU YES ; Used as existence test, not size
Z3NDIR EQU Z3ENV+21
Z3NDIRS EQU YES ; Used as existence test, not size
DRVEC EQU Z3ENV+52 ; Valid drive vector
CCP EQU Z3ENV+63 ; CCP entry
CCPS EQU Z3ENV+65 ; Size
DOS EQU Z3ENV+66 ; DOS entry (+6)
DOSS EQU Z3ENV+68 ; Size
BIO EQU Z3ENV+69 ; BIO entry
common /_SSTK_/
SHSTK: ; Top of Shell stack
SHSTKS EQU 4 ; 4 entries
SHSIZE EQU 32 ; 32 bytes each
common /_MSG_/
Z3MSG: ; Message buffer
Z3MSGA EQU 80 ; 80 bytes long
common /_FCB_/
EXTFCB: ; External file control block
EXTFCBS EQU 36 ; 36 bytes long
EXPATH EQU EXTFCB+EXTFCBS ; External path
EXPATHS EQU 5 ; 5 elements
Z3WHL EQU EXPATH+(EXPATHS*2)+1 ; The wheel byte
Z3WHLS EQU 1 ; 1 byte
common /_MCL_/
Z3CL: ; Multiple command line
Z3CLS EQU 203 ; Maximum command length
ZZPAT EQU Z3CL+256 ; Potential User patch area
common /_XSTK_/
EXTSTK: ; External stack
EXTSKTS EQU 48 ; Size (bytes)
CSEG ; Select Code Segment
End of NZCMN.LIB
Figure 6. This is a partial listing of the file NZCMN.LIB, which de-
fines the named common blocks used during assembly of modules for use by
NZCOM.
------------------------------------------------------------------------
B2:DBASE>nzcom minimum /v
NZCOM Ver 2.0 Copyright (C) 1987-88 Alpha Systems Corp 21 Jan 88
Input buffer start 1C00
Read buffer start 1D00
Write buffer start 3D00
Loading A0:MINIMUM.NZC
Loading A0:NZCPR.REL for CE00 at 3D00
Loading A0:NZDOS.REL for D600 at 4500
Loading A0:NZBIO.REL for E400 at 5300
Loading A0:NZCOM.Z3T for E580 at 5480
Writing A15:NZCOM.CCP
Booting NZ-COM...
Figure 7. This is the screen display when NZCOM loads the minimum sys-
tem from a running default system.
------------------------------------------------------------------------
; Beginning of program
;
ENTRY: DB 0C7H ; RST 0 opcode, will become JP
DW START
DB 'Z3ENV' ; ZCPR3 program ID
DB 3 ; Type 3
;
ENVADR: DW 0 ; ENV address filled in by Z34
DW ENTRY ; Execution address
;
START: ; Beginning of main program
Figure 8. Form of the Z3ENV header code in a protected type-3 program.
An attempt to execute this code under CP/M will result in a warm boot.
--------------------------------- end ----------------------------------