CFOG's PIP, May 1988, Volume 7 No. 3, Whole No. 65, page 41

NAJ'S ZCPR GUIDE

by Naj Najarian, President, Lehigh Valley Computer Group with editing by Bill Snell, newsletter editor of LVCG

PREFACE

To date, all the instruction manuals and articles on ZCPR have been written for the highly computer-literate reader. There is no guide introducing the reader to ZCPR which explains all that computerese jargon and gives concrete, useful examples. The extant guides are written by and for the assembly language programmer. What about the rest of us?

So this dissertation will strive to be an introductory guide which leads the reader into ZCPR, starting out with an explanation of not only what ZCPR is, but why it was developed and what advantages it offers to the regular computer user. Not the software developer, not the industrial technician. It will be a biased guide.

Expect lots of pig-headed opinions and few apologies, but all for the sake of practicality. The examples are based on personal use, with some reference to how others could use the same techniques. So I'll probably wander a bit too.

It means that the examples will get detailed, but, I hope, not so detailed as to become incomprehensible. I want to show how I use certain ZCPR techniques to make life on my Kaypro easier. I don't intend to show everything about ZCPR and all its tools. That's a whole book, if not a whole series of books. I hope also to update this guide constantly, so that as new tools and new revisions of old tools come out, you can keep up to date.

I. JUST WHAT IS ZCPR?

This question requires a little discourse on operating systems. ZCPR stands for Zilog Command Processor Replacement. It's designed to replace CP/M (which stands for Command Processor for Microcomputers). The Console Command Processor (abbreviated as CCP. Fair warning: computerese is rife with three-letter abbreviations. Given enough time, I'll collect them into a glossary) is the part of the operating system of the computer that a) tells the computer to load and run a program when you give it the name of one (It knows to load the file called WS.COM and run it when you say WS) or b) to run the built-in commands TYPE, DIR, SAVE, REN, USER and ERA (these are called resident commands because they reside in the computer's memory; the other type, the kind that take up space on the disk, are called transient because they're only in memory when you run them.)

There is another part of CP/M that comes with your computer, called the BDOS (Basic Disk Operation System) which is the part of the operating system that finds, creates and deletes files, prints characters on the screen, figures out file size -- all the basic operations that programs use. If a program wants to start a new file, for example, it tells the BOOS, "Hey, BOOS, open up a new file and call it ELEPHANT.TXT," and the BDOS will do just that. It saves programmers from reinventing the wheel with every program they write. The BDOS handles all the common operations.

This system also lets programs work on any machine with CP/M's BDOS because the BDOS does not vary among different brands of computer. The BDOS on a Kaypro is virtually the same as the BDOS on an Osborne, is virtually the same as the BDOS on an Apple running CP/M (Note that I hedged my bets with "virtually." Where the BDOS is stored in memory will effect its exact coding, but that should be the only difference). That means that the only part of the operating system that varies from computer to computer is the BIOS or Basic Input/Output System. That's the part that tells the different chips in your computer what you've got (how many disk drives, how many different ports, whether or not you have a built in modem or clock, what type of keyboaid is attached) and how to operate. A program that wants to create a new file sends a code number to the BDOS which tells the BDOS to open a file and the BDOS in turn sends a code to the BIOS telling it to open a file on a specified drive.

All that was to explain to you that there's an additional piece parallel to ZCPR which replaces the CP/M BDOS just as ZCPR itself replaced the CP/M CCP. ZRDOS (for Zilog Replacement Disk Operating System), when paired with ZCPR, makes an integrated operating system known as Z-System. It is the only part of all this Z-stuff that is not Public Domain (abbreviated PD, really!) and costs money. [A program released for free copying by the public, without any copyright being retained by the author, is said to be in the public domain. We often apply the term loosely to refer also to programs whose copyright is held by the program author but released for free copying for non--commercial purposes.] Consequently, ZCPR systems (those without the ZRDOS) are much more common than full Z-systems.

II. WHY ZCPR?

CP/M was designed to work on an 8-bit chip called the 8080. developed by Intel Corporation. It works also on an earlier chip, the 8085, and a later chip from a competitor, Zilog Corp., the Z80. The Z80 chip does everything the 8080 does and then some. Rick Conn, a developer who works for the Department of Defense, realized that CP/M could be rewritten to take up less memory and run faster if it took advantages of the added instructions of the Z80 chip. And so, over a period of years, he and a cadre of programmers have gradually improved CP/M with a fully compatible operating system which now does more than CP/M ever did. Similarly, ZRDOS operates much faster than the CP/M BDOS. I recently updated one of my Kaypros on which I had run ZCPR and the old CP/M BDOS for a long time. I was stunned by the improvement in speed of disk operations. I didn't do any timing because, truthfully, I didn't expect to notice the difference. But the system runs so much faster that I probably could time the difference with a plain old stopwatch. (I should go into additional improvements in ZRDOS, but this is about ZCPR, not ZRDOS.)

Later on, I'll discuss how switching to ZCPR affects your system in terms of actual diskspace. The guts of it reside on the same place as CP/M did, that is, on the place reserved on every disk for the operating system, called the SYSTEM TRACKS. It's the part that gets SYSGENed onto any disk you want to keep in drive A:. Which is to say you lose no disk space, and need it only on the disks you want to keep in drive A:. True, some of the other features do take up extra space, but we're talking about perhaps as little as 10K. If that worries you, jump ahead to the section labelled COSTS. It's worth it. Don't take my word for it; ask any other Z-System user.

III. HOW ZCPR WORKS

ZCPR works its wonders by dividing up its memory into segments. Where the CP/M CCP was just one hunk of memory, ZCPR is divided by function. For example, the DIR, ERA, TYPE and other resident commands are stuck into one part of memory (called the RCP or Resident Command Processor), and the part that loads and runs programs is situated elsewhere. Other segments (ECP, FCP, Error Handler, and so on) have no equivalent in CP/M. There are so many different sections (segments is the technical term) that there's a segment that's an index of all the other segments (it's stored in a file called SYS.ENV because it describes the environment of the system).

Because the CCP is neatly divided up, different segments can be swapped in and out. An example for those who with an IOP (Input/Output Processor): if you're going to be editing and printing a number of files with the new version of WordStar, you could load the IOP that lets you print while you do other work on the computer (Background Printer, by name, or BP for short), until you get to some hellacious formating, at which point you'll load the keyboard re-definer into the IOP [NUKEY is thus far the only keyboard macro program written for the IOP; it's not nearly as nice as XtraKey, but it won't take up any TPA that WS 4.0 needs so much.)

[NUKEY is proprietary; for some systems the public domain Z33KEY.RCP gives keyboard redefinition capabality where you are willing to give up your resident command package, not a bad option on a fast hard disk system or a big RAM disk system. -- bhc]

An example for the rest of us: once in a while, while I'm editing, I'll want a calculator on hand. CALC is an RCP that replaces the TYPE, DIR and other commands with a tiny pocket calculator that you can use within any other program. So I'll load that RCP in and run WordStar. And as soon as I'm done editing, I'll load the regular commands back in so everything's back to normal. (Obviously Backgrounder ii would be ideal for these operations. ed.)

How the segments work.

Let's take a look to see how the CP/M CCP operates. When you type in a command, it first checks to see if it is a command that it has in memory (DIR, TYPE, and so on). If not, then it trys to load into memory from the disk a file with the command name, but ending in .COM, and then runs it. If there's no file by that name, then it prints on the screen what you typed followed by a question mark to tell you that it couldn't execute the command.

Generally, ZCPR functions the same way. You give it a command (or a whole series of commands seperated by semi-colons). First it checks the resident commands in the RCP (usually DIR, TYPE, ERA, sometimes COLD, CP, R, and a few others). If it's a resident command, it runs it. If it's not in the RCP, it checks the FCP (file command processor, you remember). That's where ZCPR holds all the IF commands.

Digression #1: Full list of RCP and FCP commands:

RCP Commands (mix 'n' match at install time)

CLS   clears the screen
COLD   cold boot (same as hitting the red switch in the back)
CP   copy a file
DIR   disk directory
ECHO   sends characters to screen (or printer)
ERA   erase files
TYPE   display file on the screen
LIST   send file to printer
NOTE   for comments in a command
PEEK   view memory
PEEP   view a file w/forward and backward scrolling and string search; not yet in common use (it's just been released)
POKE   set memory by sticking numbers into it
POR   view and set I/O ports
PROT   set file attribute bytes
REG   set and display registers in memory for own use
REN   rename files
R   reset disk system (when you switch disks, no need to press CTRL-C)
SP   show space remaining on disk
TST   test for program error
WHL   set the wheel byte (for BBS system security)
WHLQ   to find out whether the wheel byte has been set

FCP Commands

T   are there any false(s) thus far?
F   is there already a false lurking about?
AMBIG   is there a wildcard in the command line (like *.*)?
ARCHIVE   has file been backed up?
BG   is Plu*Perfect's Backgrounder running?
COMPR   is the file squeezed or crunched?
DS   ??? [Probably query for Plu*Perfect's DateStamper utility -- bhc]
EMPTY   is the file 0K big?
ERROR   have we goofed yet?
EXIST   does the file exist on a given drive?
INPUT   answer this question, and if you answer 'Y' or ' ' or [RETURN], continue
NULL   anything in the command?
LIST   is there a list of things in the command?
REG   does a register equal a value?
RO   is the file set for read-only?
SHELL   is a shell (like ZFILER) running?
SYS   is this a system file (not shown up in a DIR)?
TAG   has this file been tagged by a shell?
TCAP   got video capabilities (almost always yes)?
WHEEL   is the wheel byte set (for security)?
ZEX   is ZEX running?

Only first 2 letters of the conditions are important. With ZCPR 3.3 it is not virtually standard to have all the tests above available, because what can't be fit into memory is stored in a file named IF.COM that is loaded and run automatically when necessary.

A leading '~' negates; different conditions can be joined together by ANDs and ORs; a test is introduced by an IF, ended with a FI, and sometimes split by an ELSE. Values are tested by various operators, equals, different from, greater than, greater than or equal to, less than, less than or not equal to, which can be entered symbolically [but greater than and less than aren't on this print wheel! -- bhc] or alphabetically by EQ, NE, GT, GE, LT, and LE.

A trivial example which I've indented for legibility [and slightly modified to fit PIP's column width]:

IF EXIST C:*.BAK;
  IF INPUT DO YOU REALLY WANT ME
           TO ERASE THE BAK FILES?
    ERA *.BAK;
  FI;
  ELSE;
    ECHO THERE AREN'T ANY BAK FILES;
FI;

End of Digression.

So, the system checks the command on the command line it's a command that's in memory, a resident command. If the command's not in memory, then it'll try to load it from the disk. But not just from the logged disk. ZCPR will search the PATH, a set of different user areas and drives for the file. PATH, what's that?

Lengthy Digression #2: User areas

In CP/M, a drive is divided into 16 user areas, arbitrary divisions of a disk, distinguished by numbers 0 through 15 (actually, with ZCPR, through 31, but the last 16 really aren't useful except in hiding files from yourself). On a CP/M 2.2 system, you always start in user area 0. In fact, you probably have little reason to use more user areas and you pobably never knew that there were other user areas because you really don't need them.

On a hard disk, however, you have to have a way to divide up your hard disk. You wouldn't want all 8 megabytes in the same user area. Could you imagine the directory? It'd take half an hour just to list it to the screen. So the designers of CP/M developed the notion of a user area. You can store files on different user areas of a disk, and log into them almost as if they were different disks. But there's no cross--communication between user areas. If you're logged on Drive B: in user area 2, and you say go to Drive A:, you will be on drive A:, in user area 2. The system can't see a file on any other user area of any drive.

[Actually, the reason for this had nothing to do with large hard drives, which were rare and expensive in those days, but had to do with multiple users on a system. You isolated each user's work in a separate area. Hence the name user area. -- bhc]

There is vertical communication across boundaries, but not horizontal. That means, if you're running WordStar in A6:, it won't be able to find its overlays (WSOVRLY1.OVR and WSMSGS.OVR) in A0:. Ugh. There are two ways around that. One uses ZRDOS to define a whole area as PUBLIC, that is, a call from any area on the same drive will find the file if it's in any user area defined as PUBLIC. The other uses a slight modification of the CP/M BDOS to let you label certain files, instead of whole areas, as public. They'll be invisible when you do a DIR, but programs will be able to find them.

In CP/M 2.2, you can't change the logged drive and user at the same time. To change user area, you had to use the USER command. A royal pain: to move from A0: to B6:, you had to enter B:[RETURN] and then USER 6[RETURN]. In ZCPR a simple B6:[RETURN] will get you there. And to get to any area on the same drive, just the number and a colon. [CP/M Plus uses the same technique. -- bhc]

End of Lengthy Digression #2.

The PATH is a list, in memory, of drives and user areas to search for a file. You have to have a PATH, even if it's only to the current drive and user area, which is written in ZCPR as $$. If no path is set, the system will never find anything because it doesn't know where to search. After the current drive and user area, it is common to search the current user area on drive A:, written as A$. After that, you could have it search all over both disks (B0 B1 B2 A1 A2), but that slows down things a tremendously. And if you have no disk in a drive in the PATH, the system will hang as it trys to search an empty floppy drive.

Normally, the ROOT is the last drive and user area on the path, typically A15:. Some ZCPR tools know to go directly there instead of searching all over first. My path is rather brief: $$ A0 A15.

With ZCPR Versions 3.3 and later, do not need to include the current drive/user in the path. If you set the path so that it goes only to the root directory, and the program you want is NOT in the root, you can precede the command with a drive and user specifier in the form du:, or if you want the current drive and user, simply a period or colon, and the system will search the specified du: or the the current drive/user first, before going along the PATH. This is especially nice on a hard disk system, but in a floppy disk environment where the desired program is very likely in the current user area, I'm not sure it's an advantage.

In case you've forgotten, we're still tracing a command through ZCPR. When the command is found along the PATH the system loads the program into memory and then runs it.

Loading a program into memory and running it are two distinct operations for ZCPR. You can modify a program after loading it and before running it. GET, a resident command, will load a file into memory without running it. POKE, another resident command, will change a value in memory. And GO, another resident command, will then run the program that is already in memory.

Why would you want to do that, you ask? Because it gives you a lot of power. Most industrial strength programs contain sections of memory which are nothing but configuration bytes. WordStar and dBase are perfect examples. You can constantly re-install WordStar without keeping the install program on disk. Just GET it into memory, POKE in values for the variant installation, and GO. You can change insert, word-wrap, justification, margins, even printers on the fly. You'll need an index of patch points. One of the best articles is Ted Silveira's in PROFILES (July/August 1985 and republished May 1987). The WS-BIBLE also lists the different patch points. I use this method to give me a copy of WordStar that opens a file in non-document mode. I have an ALIAS which consists of the commands GET 100 WS.COM;POKE 0378 FF;GO; and does just that. I use the same technique to load more than one copy of dBase. One has everything set the way dBase normally is; another loads it with BELL OFF, INTENSITY OFF, ECHO OFF, and TALK OFF. And another is the same except for the addition of COLON OFF.

[Here's another digression: an ALIAS is simply a command or series of commands that goes by another name. Each ZCPR ALIAS is a COM file that contains one or more commands. Like SUBMIT files they can pass parameters, that is, they can accept and operate on additional information that you put on the command line. For example, you might have switched from SD.COM to DIRR.COM as your favorite extended directory program. You might create an ALIAS called SD that is simply DIRR $1 $2, so that if you forgot the change and entered SD *.COM $s[RETURN] you wouldn't get a silly SD? from the CCP. There are several ZCPR utilities that build ALIASes as COM files. BALIAS and SALIAS are two of them. Each is an editor-like program that creates a stand--alone COM file whose commands can be edited with the editor function of the program. -- bhc]

You can use the POKE and GO technique for even fancier tricks. Say you have two different copies of WordStar installed for your two printers, a dot matrix and a daisy-wheel. Since WordStar stores all of its printer settings in one chunk of memory, you could keep your regular copy of WordStar on your disk for common use, and a copy of only the printer chunk of memory of your alternative version for when you want to print with your secondary printer. You need only write an alias (call it FANCYWS or some such) to load the primary copy into memory (GET 100 WS.COM), overlay the chunk for the secondary printer (GET 300 DAISY.BIN), and then run what you've got (GO $*). The only hard part is getting a copy of the printer part of your alternative WordStar (DDT WS.COM[RETURN] M300,F800,D100[RETURN] G0[RETURN] [note that's a zero and not an oh] SAVE 5 DAISY.BIN[RETURN]). Now you have two WordStar's set up for different printers (complete with the different Pause-for- Paper-Change settings) at a savings of 16K.

When you exit WordStar, ZCPR will take the next command on the command line (everything after the semi-colon up to another semi--colon), if there is one, and go through the whole process again. Your whole command line can be up to 200 characters long. Very useful for ALIASes.

But what if after checking the RCP, FCP, CCP, and the PATH, ZCPR still hasn't found the command? Then it runs a program called CMDRUN.COM which it expects to find in the root of the PATH (and if there's no file by that name in the root, go on to the next step). This is called the ECP, or extended command processor. You can rename any program CMDRUN.COM, and ZCPR will run that program. That means, if you find a program that does nothing but put out a long beep, you can have it do something as silly as beep to alert you that you goofed.

It is common now to use ARUNZ. ARUNZ uses a text file called ALIAS.CMD, which contains your ALIASes as lines of text, rather than as stand-alone COM files. Each series of commands can have more than one name or ALIAS. [For example, the series of commands that I use to edit, save, compile, and overlay on VDE a new set of function keys can be called as EDITVDT, EDITBENZ, BENZ, EDIT, or VDT, all with the same result. -- bhc]

ARUNZ is short for ALIAS RUN ZCPR and is explained exhaustively in an article by Jay Sage, its designer, in issue #31 of The Computer Journal. Lately, the the term SCRIPT has become popular or the series of instructions invoked by an alias because the computer performs them as would an actor reading a script. A potent metaphor.

My ALIAS.CMD file is huge, but here are a few samples, followed by explanations.

A xdir A: /aauog
BACKUP crunch $1 $"To where " [$"Today's date: "] /oa
NWS get 100 ws.com;poke 0378 ff;go $*
ZF=XF=VF=VFILER=XFILER=ZFILER zf
: lx / $0 $*

If I enter A[RETURN] (that's it, just the letter A), and a search of memory and the PATH turned up nothing, then in ARUNZ.CMD the system will find the command that tells it to run the program called XDIR to give me a directory of all files on all user areas of drive A:.

You can even prompt for input in an ALIAS. When I want to backup a file or a user area, I just type BACKUP B0:*.*. The ALIAS prompts me to put in the destination drive and the date stamp with the strings between the quotes preceded by the dollar sign.

When I enter

NWS PROGRAM.ASM [RETURN]

ZCPR won't find NWS as a resident command, won't find a file called NWS.COM along the PATH, but will find in ALIAS.CMD, the ALIAS NWS and execute the following: get, that is load WS.COM into memory at 100 (where most programs are run); poke, that is put the value FF at memory location 378 (hexadecimal); and run the now modified edition of WordStar that is in memory with the file PROGRAM.ASM as the one to edit. The $* tells ARUNZ.COM (renamed CMDRUN.COM, remember) to add everything in the line after the NWS to the command. It's one example of the sophistication of the Z-System I don't have to specify the number of parameters that will be on the command line with $1 $2 $3 as we do with SUBMIT.

One final example: when I switched from the program VFILER to the new improved version, ZFILER, it took me the longest time to remember the program was ZF.COM, not VF.COM. Sometimes I would even type XF by mistake. Now, no matter what I type, it knows to run ZFILER (truly named ZF.COM). That's what all those equal marks do.

Now, if the command is not in ALIAS.CMD either, then the system would execute the line after the colon at the bottom. Used to be, that was ECHO I DON'T KNOW HOW TO "$0", YOU MORON. That means the command name would be substituted for the $0, and the system would print a line on the screen, using the ECHO command from the RCP, saying, for example, I DON'T KNOW HOW TO "SBASE", YOU MORON. Clever, but not terribly helpful. Now it sends the command line to a program called LX. That gives me effectively two ECP's in one (LX used to be, and sometimes still is, run alone as the ECP; renamed CMDRUN.COM and put on the root).

LX tries to run commands from a library (by tradition in the root directory) called COMMAND.LBR. And what that means is you can store a whole lot of ".COM" files in a library and run them. That saves disk space, and neatens things up. At this writing. I have 35 files in mine (takes up 190K) and saves 30K. The larger your block size the more space you'll save. Those with small floppies and 1K blocks won't save much space at all. Those with hard disks with 4K blocks will save lots of space. Plus that's 35 names I don't have to look at every time I do a DIR. You can keep all your editing utilities in there: FTNOTE, INDEX, FILTW, maybe even BRADFORD and others. By the way, LX will let you run programs in other libraries elsewhere too. Just remember to precede the directory with an hyphen: LX -B6:UTILITY WSDOCON LESSON1.MSS will run WSDOCON.COM from within the library called UTILITY on b6: on the file called LESSON1.MSS in the default directory.

That / option in LX let's us take advantage of the final part of the processing system, the ERROR HANDLER (Hey! No abbreviation!). If LX doesn't find the command as a COM file in COMMAND.LBR, it passes the command to whatever program has been installed as the error handler (usually you just run the program, and it installs itself as the error handler). Some people use Z33ERROR, which makes an analysis of the type of error and makes a report. I prefer VERROR which loads the whole command line (the offending and all subsequent commands), and let's me correct my mistake, using WordStar control keys to move about the command line. I either correct the command, add to it or zap it away with a CTRL-Y. [A newer error handler/shell is called EASE. -- bhc]

[Naj describes a complete Z-System extended command processing rigmarole. Unless you have an exceptionally quick system you may find that all this sometimes seems to take all day. My own choice is to use ARUNZ with its ALIAS.CMD file as the end of the process, with no error handler. Using EASE only as a history shell allows me to recall previous command lines and edit them when that's desirable. -- bhc]

IV. INSTALLATION

So what does ZCPR cost you? In terms of memory, a decent ZCPR installation will take up some memory. By decent, I mean a full ZCPR setup, with or without an IOP. I have only 58K instead of the Kaypro CP/M standard 63 or so. But it's not important memory space unless you want to run a humongous program with lots of add-ons. [See my separate article "TPA -- What It Is and How Much You Have" elsewhere in this issue of PIP. -- bhc]

In my set-up, I can run WordStar 3.3 and a keyboard redefiner set up with more than one set of keys. The only time I've ever found a memory limitation is when I run a commercial outliner program written in TURBO Pascal. The program runs fine, but it takes up so much memory that it won't let me also add a keyboard redefiner in the background. The same is true with the new 4.0 version of WordStar. It'll load, but you can't add any other memory-hungry background program. You have to replace or eliminate your IOP instead, if you've got one.

As for compatibility, don't worry about it. ZCPR is by design 100% CP/M compatible. Except for memory limitations (and those are EXTREMELY rare, there can be no such thing as a program that runs in CP/M and not in ZCPR. And I still have yet to find a program so large that it won't run alone in ZCPR.

So what about disk space? This is a concern of floppy users alone. The different system segments (SYS.RCP, SYS.FCP, SYS.ENV) must reside on disk so that you can load them into memory. And you have to have a way to load them. If you use LLDR.COM, you can stick them all in a library, and load them from within the library. LLDR.COM takes up 8K, and the library of segments will take up at least 3K. When ZCPR cold boots, it tries to run a program called START.COM. You can get away without it, but you're only asking for trouble. For the sake of flexibility and ease, you oughta include that too.

That file is an alias with the instructions to execute at cold boot (when you turn your machine on, or press the reset button). It will include at the very least a line telling the system to load the different segments, something like:

LLDR ZPACKS,SYS.ENV,SYS.RCP,SYS.FCP

START.COM will take up the minimum file size for your system, usually 1 or 2K. Disk costs thus far: SSDD, 12K; DSDD 14K. That's really all you need, but I'd go nuts without ARUNZ as my ECP (ado another 4K), and that means an ALIAS.CMD, file, too. I've got 2K worth of aliases in mine; let's assume you will too. That's 18K or 20K. Now, in order to recoup some of that, you may want to include LX.COM (3 or 4K) so that you can run stuff from within your COMMAND.LBR. Disk expense: 21K for a single-sided Kaypro floppy system, 24K for double--sided.

All the literature says you can install ZCPR yourself. Don't you believe it. It is physically possible, but it's not worth the mental aggravation. Let someone experienced do it for you, or at least guide you. Because the watchword of ZCPR is customization, there are a lot of options to choose. Let someone who knows what each does help you. There are all sorts of hidden considerations. I boot from A15: because I want to hide my ZCPR files down there. That creates some problems that need to be worked around. I also thought it silly to have to correct someone else's choice of PATH on startup. I've had to correct other bugs in the system. Some users may want the possibility to name every user area (ZCPR lets you call a user area by an eight letter long name which you can use just as you would the drive and user number. EDIT:[RETURN] would log the user area named "EDIT"), but the default maximum is only 14. I know one fellow who wants 48 for his 3-drive hard disk system.

Your local ZCPR guru can explain things to you and turn your computer into a custom workstation.

But watch out. Once you're comfortable with your new ZCPR system, you'll refuse to go back to CP/M. Or to anyone else's setup. I've become so addicted that I had to design a SSDD version so I could boot my workstation on a friends ancient (read unmodified) Kaypro in order to work on his machine.

One last expense consideration. Money. ZRDOS is the only part of ZCPR that is not in public domain. Everything else is free. The files, the programs, the tools, all have been placed in the public domain. The only thing you need invest is time. And that you'll spend lots of. Getting to know ZCPR in order to customize it is a learning process. And since ZCPR is constantly being rewritten and expanded, it is a continual learning process. You will never know it all because there's always more to know.

[There has been a change in the marketing of Z-System. The indicated cost of ZCPR's latest incarnation plus the latest version of ZRDOS should be in the vicinity of $120. I believe the newest version will be or is called NZ-COM. It has a host of new features, including but not limited to dynamic reconfiguration of the system, and there will be one for just about everybody even CP/M 3 folk like Osborne Executive and Commodore 128 users will be able to install a Z-System simply and easily, without a lot of help from a local guru. -- bhc]