RCONN@Simtel20.ARPA (07/03/84)
From: Richard Conn <RCONN@Simtel20.ARPA> ZCPR3 is not in the public domain. However, I have no intentions of making any money on it (altho I may make some thru Echelon, but that is just gravy), and distribution is taking place via the conventional "public domain" channels. ZCPR3 is being released to the User Community, whatever that is. You see, the whole issue of PD software has turned into such a mess ... if I "call" it PD software, I lose all rights to it. In the manner it is going out, the PD community can freely access it without any loss of rights on my part. There are conveniences in acquiring it thru Echelon, such as hardcopy of the documentation and support, but Echelon is just an alternative you have (as opposed to SIG/M, BBSes, etc). Feel free to access it in any manner convenient to yourself. Rick
RCONN@Simtel20.ARPA (07/04/84)
From: Richard Conn <RCONN@Simtel20.ARPA> 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