Date   : Wed, 04 Jul 1984 08:51:00 MDT (Wed)
From   : Richard Conn <RCONN@Simtel20.ARPA>
Subject: Some Metrics on the ZCPR3 Release

       The following is my reply to a query I have been hearing
recently -- if I know how to modify a BIOS to install ZCPR3, do I
really want to or would ZCPR1 or ZCPR2 do the job?  I felt the
community in general may be interested in the reply.

Yes, it sounds like you *could* install ZCPR3 if you wanted to.  Make
sure you get the source to your BIOS ... all you need to modify is the
BIOS cold boot routine.

ZCPR3 is small in general, depending, of course, upon the features you
select.  My "standard" ZCPR3 system which I use on the AMPRO in slave
mode only interjects about 60K of overhead on disk, but the AMPRO acts
only as a slave in this mode, providing screen display recording and
(in the future) printer spooling.  If used as a primary system will
all of the bells and whistles of ZCPR3 enabled, around 200K of disk
space on the system disk will be taken up by the tools.

Whether you want ZCPR3 for a small system or not depends upon what you
want to do with that system.  ZCPR1 provided a minimum of features to
make any CP/M system more livable.  All (in most cases) COM files
could be placed on disk A and B could be left blank for data and
applications.  ZCPR1 would search along a simple path each time a
command was issued.  ZCPR2 will also do this, as will ZCPR3.  ZCPR1
offered a simple, fixed command-search path, ZCPR2 offered a more
complex command-search path which could be dynamically changed by the
user as he desires (the user could select search from $$ [current
disk/user] to A$ [disk A/current user] to A0, etc), and ZCPR3 offers
what ZCPR2 offered plus flow command packages (IF/ELSE/FI(Endif)),
resident command packages, error handlers, and shells which can all be
dynamically changed by the user at any time.  With these additional
features of ZCPR3 comes additional cost, with the worst cost being
around 10K of additional disk overhead and 2 1/2K less TPA.  The
bottom line is that if your needs are simple (ie, "all I want to do is
run dBASE II"), then ZCPR1 could be all you need.  If your needs are
or could grow into something more complex (ie, "I want command files
which can do looping and IF-THEN-ELSE tests, MENU-driven front ends
for applications environments, the ability to replace the command
processor dynamically with another command processor (shell), and
scripts which can expand into complex command streams from a simple
command I issue"), then ZCPR2 is an intermediate step (with MENUs) and
ZCPR3 is a more advanced step (with all the features mentioned above).

       ZCPR2, while it offered a lot of interesting features and
capabilities, did so at some cost.  A lot of the operating system
overhead existed in the utilities themselves.  ZCPR3 has utilities on
the order of 1/2 to 1/3 the size of their ZCPR2 counterparts because
almost all of the opsys overhead in the ZCPR2 utilities is now gone.
In the phase 1 distribution, the largest utilities were 8K in size
while most of them fell into the 4K or under range.  This makes ZCPR3
more attractive than ZCPR2 for almost all types of systems.

       The smallest system I have seen ZCPR3 run on so far is the
AMPRO Bookshelf.  It has two 400K floppies, and the system overhead on
the A drive, which includes my editors, communications software, and
ZCPR3 tools (not all of them) still leaves about 200K free on the A
drive and all 400K free on the B drive.  With the new AMPRO Bookshelf
coming out with two 800K floppies, I don't see a need to increase the
system overhead at all.

       So, I hope this answers most of your questions.  Your interest
in I/O redirection is answered in the I/O packages of ZCPR3.  These
are packages which can be reloaded dynamically by the system and
provide hosts of I/O drivers beyond what the CP/M I/O byte supports.
In my main system, my prime I/O package supports 8 consoles (which are
combinations of devices, like CRT and modem in parallel and CRT input
with CRT and remote computer output for display recording), 6
printers, and two each of the readers and punches.  It is NOT like
UNIX I/O redirection (using < and > on the command line), but it can
support similar functions.  The standard question which is probably on
your mind is if redirection to a disk file is possible.  The answer is
yes, but I am not happy with any of the solutions I have found except
one, and I don't plan to give that one away.  The heart of the problem
is that the BDOS is not reentrant -- a routine which calls the BDOS,
which in turn calls the BIOS, which in turn calls the BDOS for disk
output will not work since the data from the first BDOS call will be
lost.  I am using a reentrant BDOS (still in testing) which will allow
this, and, with this, disk I/O redirection can be done (especially
with an I/O package doing the work).  If this BDOS is released,
however, a complete competator to CP/M will be out, and it would be
tantamount to stabbing DR in the back, which I would hate to see
happen, especially considering that without them, we wouldn't be in
the world we are with CP/M and its clones, like MS-DOS.  Note that all
of the ZCPRs do not compete directly with DR since you still need the
CP/M 2.2 BDOS to run them.  The ZCPRs do cause competition with CP/M
3.0, but I don't feel that this is a problem since it is all in the
family (one DR product vs another).  Besides, we may someday see a
CP/M 3.0-based ZCPR, and that would be that.

Finally, a Z80 is required for ZCPR1 and ZCPR2 (altho Charlie Strom
created ZC8080 from ZCPR2 which runs on 8080's).  ZCPR3 runs best with
a Z80, but a simple flag makes it run with 8080's as well.

As a bottom line, from my perspective having the needs to use MENUs,
shells, and aliases (scripts) with shell variables, I have moved over
to ZCPR3 completely.  My I/O redirection needs are met by the I/O
packages (note that even with disk I/O redirection, I prefer using a
slave machine [the AMPRO] to direct disk I/O because of some added
flexibility I am discovering with this approach).  And my applications
needs with dBASE II, Word Star et al, MultiPlan, etc, are also met.
Even when I have applications which need large amounts of TPA (the 48K
TPA [out of 62K possible] I have under a full ZCPR3 is not enough), I have
applications-oriented disks which I use which give the needed larger
TPA.

       Rick