.op .cw 10 .po 9 THE Z-SYSTEM: 8-bit Software Grows Up By David McCord, Staff Consultant, Echelon, Inc. Remember CP/M 2.2? Sure you do! After all, it was the de facto standard operating system for microcomputers before IBM invaded the arena with their PC. However, over the past two years or so, the 8-bit computer market that CP/M 2.2 represents has been steadily losing ground to the 16-bit market represented by the MS-DOS operating system. One of the major reasons for this shift has been because CP/M 2.2 has been perceived as being outdated and difficult to use, especially in turnkey applications. Other reasons abound, such as having to warm boot the system whenever a disk is changed, lack of a named directory capability, and more. And, although the 8-bit system has always had the advantages of lower hardware cost and a large body of developed software, the disadvantages were forcing developers and users to move to the 16-bit systems. At Echelon, we see 8-bit hardware as the natural solution to most personal computing and process control requirements. In terms of performance, a Z80 based system has the same throughput as an 8088 based system, without the overhead of the large amounts of RAM required by 8088 based software. We have developed a new operating system, called the Z-System, to free 8-bit hardware from the constraints imposed by the old (and archaic) CP/M 2.2 operating system. The Z-System is a natural evolution of 8-bit operating systems, to the point where the Z- System has a greater utility and functionality than MS-DOS. Yet it remains compatible with any CP/M-2.2 applications software available. This allows you to take advantage of the low hardware cost of 8-bit systems and the large body of software already developed for use under CP/M 2.2. Structure The memory map of a Z-System is presented in Figure 1. The BIOS is basically the same as that used under CP/M, with a modification to the Cold Boot routine to do some additional initialization. The Z-System consists of two major parts: 1) ZCPR3, and 2) ZRDOS. ZCPR3 is an acronym for Z80 Console Processor Replacement, version 3, and it replaces the portion of CP/M known as the Console Command Processor (CCP). (Some of you may be familiar with ZCPR2; ZCPR3 is a major revision of ZCPR2.) ZRDOS is an acronym for Z80 Replacement Disk Operating System, and it replaces the portion of CP/M known as the Basic Disk Operating System (BDOS). The combination of these two items replaces all of the software that make up the CP/M 2.2 operating system supplied by Digital Research, and Echelon offers it at substantial savings by comparison. The key elements that differentiate the Z system from CP/M are the sections shown in Figure 1 that contain "segment" as part of their names; these are known as "system segments", and each is dynamically changeable, or, may be omitted if the features they contain are not desired. A loader utility facilitates dynamic changes of all of these segments, "on the fly". An interesting point to note is that ZCPR3 can be implemented into a standard Digital Research operating system without having to acquire ZRDOS; many of the features discussed in this article are derived from ZCPR3. The modification to the original BIOS so that ZCPR3 can be used is very easy to implement in either case. .pa .pn 2 .fo Page # Intrinsic Features There are a wealth of important features available under the Z-System, far more than I can touch on in this brief article. Some of the major ones are shown in Table 1, and compared with CP/M 2.2 and MS-DOS. The system segments of the Z-System contribute most of these features. Some of the unique features of the Z-System are: -Conditional testing and execution of commands at the operating system level. This facility allows a single batch processing program to execute differently depending on the results of tests; for instance if a command parameter is supplied, perform the batch commands using that parameter, or if no parameter was supplied, use a default parameter. Another example is a branch within a SUBMIT file depending on whether or not a particular filename is present. This conditional testing functionality is provided by the Flow Control Package Segment. -Named directories with optional password security. Under ZCPR3, a named directory is a symbolic name assigned to a drive/user area combination. The system may be configured such that the system prompt (usually of the form DU> where D is the active drive and U the active user area) can report the name of the directory in the prompt, such as A15:ROOT>. The systems integrator may take this a step farther, and omit the drive/user code in the prompt, resulting in a prompt of ROOT>. This is a very effective tool in turnkey systems as the end user no longer has to deal with arbitrary drive and user numbers; instead he may use mnemonic names that are self descriptive, as BASIC or HELP. It is also ideal where a large hard disk is being used, and can partition the storage into smaller, more manageable parts. In situations where security is a concern, the directories can be passworded so that a password is required to log into the directory. Programs and files that must be kept secure can be kept in a passworded directory, inaccessible without the proper password. This function is provided by the Named Directory Segment. -Dynamically variable user privilege levels. The facility of ZCPR3 known as the WHEEL can allow you to disable commands, such as ERA (erase a file) and others, to nonprivileged users. This is also available from within application programs as well. This concept improves system security substantially. -Searching of alternate directories for invoked programs and files. This is known as the PATH function of ZCPR3. It liberates the user from one of the more glaring "user unfriendly" aspects of CP/M 2.2: always needing to specify what drive the program to be invoked is residing on. The PATH is dynamically variable to offer maximum flexibility. -Multiple dynamically loadable command packages included. The best example of this in the MS-DOS environment is the COMMAND.COM program. However, this is the only command package included with MS-DOS. ZCPR3 includes up to four command packages, and their source code, which allows you to tailor your commands to suit your needs. -Terminal independence. The ZCPR3 Environment Descriptor contains what is known as the Terminal Capabilities (TCAP) Segment. This segment contains data about the type of terminal being used on the system, consisting mainly of the escape sequences to perform functions such as clear screen, cursor addressing, sequences generated by the terminal's arrow keys, highlighting on/off, and etc. The 70+ utility programs supplied with the Z-System take full advantage of this information to enhance interaction with the user. The end result is that programs do not need to be changed or patched when a different terminal is connected to the system; only a different TCAP segment is loaded. The Z-System presently is supplied with data for over 50 terminal types. .pa -Multiple commands per line. This is an excellent productivity enhancement. Users can enter a sequence of commands all at once, and go on to other things while the machine executes those multiple commands. And because the commands are stored in a defined buffer area within the Z-System, application programs may insert operating system level commands into the buffer to allow program chaining without having to resort to the "tricks" necessary under CP/M. -Communication between Z-System utilities for status information and messages. The ZCPR3 message buffers allow programs to communicate with each other without necessitating the use of data files. This permits sharing of information between programs without the code and disk space overhead of the shared data file approach. All of the above features and more are intrinsic to the Z-System. Utility Features There are many additional features possible once the Z-System is installed, based on various utility programs supplied with the Z-System. Some of these features are: -ALIAS capability. ALIASes are short programs with a filetype of .COM which contain a command or sequence of commands. For example, I could create an ALIAS with the name of CLEANUP.COM that contained the commands: ERA *.BAK;ERA *.HEX;ERA *.SYM Then, when I enter CLEANUP at the system prompt, it will clean up (erase) all files in the current directory with filetypes of COM, HEX, and SYM. -Integrated HELP facility. The HELP.COM utility program is designed to work within the Z System environment, and uses the TCAP data to enhance presentation of help information to the user. Multiple files are supplied with the Z-System for use with the HELP program, so that a large amount, (over 400k-bytes) of documentation can be online to assist the user, disk space permitting. -Multiple Shells. Several of the utilities available under the Z-System are SHELLS (MENU, VMENU, VFILER, etc.). Programs that are shells are capable of calling other programs, and when that program finishes executing, then control is returned to the shell that called the program. Shells may also be nested, that is, have the capability of having multiple shells active at any given time. See the discussion of MENU in the applications section of this article for a detailed discussion of the capability of shells. -Dynamic re-assignment of system devices from the command line using device driver names. This is a very powerful facility for assigning different printers, system consoles, modems, and other peripherals via names instead of IOBYTE values under CP/M 2.2. The systems integrator can choose the device names, and is not restricted to arbitrary designations like LST:, CON:, etc., but can use names like ADM3A, EPSON, etc., if he chooses. -Integrated error handling. Under CP/M 2.2, if a user enters an unrecognized command or file name, CP/M simply repeats the input back to the user, and adds a question mark. This is not very user friendly! The Z-System allows various programs to be installed as error handlers for this type of situation, and offer a variety of options to the user as to what to do next. There are over 70 utilities designed for use under the Z-System. Each adds unique and exciting features; disk editors, memory utilities, device programming tools, unerase programs, and much, much more. .pa Applications The Z-System has an enormous potential for increasing efficiency in all applications of microcomputers. Tasks such as software development which have multiple steps can be automated using ALIASes and the command processor ZEX.COM, so that a single command may compile, assemble, link, cleanup, and execute a program under development, yet determine if errors occurred in the process and terminate the process if this is the case. For turnkey applications, shells such as the MENU.COM program can go a long way in enhancing user interaction and system performance. Software Development For an example of the kind of tools available under the Z-System to improve software development productivity, see Listing 1. The file shown is a command file for ZEX.COM, which is a third generation command processor based on the SUBMIT and XSUB programs that are bundled with standard CP/M 2.2. Note in the example file the use of '$1' to represent command line parameter substitution, just as with SUBMIT and XSUB. This command file for ZEX makes extensive use of the Flow Control Package of the Z-System, as shown in the use of IF, ELSE, and FI (ENDIF) statements. Through the use of these Flow Controls, the system is capable of detecting errors such as no parameter to substitute for $1, no file existing to use as source, and whether or not to continue on the the link stage if warning errors were detected depending on operator input. This type of intelligent batch processing is light years ahead of standard CP/M 2.2, and even ahead of many mainframe computer operating systems! Also available at very low cost (and no royalty fees) are the assembly language "building blocks" used to write major portions of the Z-System, called SYSLIB3. SYSLIB3 consists of hundreds of assembly language routines, written for use with a Z80 processor. Programmers developing software for use under the Z-System will have the advantage of having the common routines used in most programming tasks already written, and will not have to build applications software from scratch. A detailed discussion of SYSLIB3 is beyond the scope of this article, but it remains a very powerful tool to enhance programmer productivity. Turnkey Systems For the systems integrator who is designing turnkey systems, the various shells of ZCPR3 offer an unprecedented capability of integrating stand-alone programs into a cohesive system. An example of this is shown in Listing 2, which is the input to the MENU.COM shell for use with the Z-System utility called DISCAT, a disk cataloging system. To introduce you to the way that MENU works, first a few words about the structure of the DISCAT system used in the example. DISCAT is a collection of modular .COM programs, the largest of which is 8k bytes long. Each module is dedicated to a specific function, such as putting a disk name into a disk directory, updating the master catalog file from a target disk, creating the master catalog file, etc. This modular approach greatly reduces RAM requirements and was very helpful in the program development phase, since each program is small, and there is little or no code interaction between the functions of the system. The MENU shell is the element that unifies these small programs into a cohesive unit. The file shown in Listing 2, which is referred to as a .MNU filetype, is created with any standard word processing program. The MENU program also ignores the high-order bits of the characters contained, so if the word processing program used to create the file sets the high bits of characters (like WordStar), this does not create a problem. The structure of a .MNU file is divided into two major parts; the first is the section of the file that is displayed to the user when the program is invoked. This is the section of the example between the single '#' symbols. This section, when displayed, is capable of using the data in the TCAP segment of the Z-System to highlight sections of the display and enhance interaction with the user; I have omitted these highlight commands in the interest of clarity, but the capability exists. The second part of the file is the section between the second single '#' symbol and the double '##' symbol. This section is used by the MENU shell to generate commands based on a single keystroke by the user. The way that these commands are then acted on is by sending them to the ZCPR3 Command Processor for execution. For instance, in our example there there is a line in the second section that contains "2era working.cat". This means that if the user types the "2" key, the command "era working.cat" will be generated and sent to the ZCPR3 Command Processor for execution. The command will be executed, and then the MENU program will regain control, and wait for the next keystroke by the user. This is the simplest command lines that can be generated by the MENU program in conjunction with this .MNU file. Things are more sophisticated in the example line in the second section that contains 'ccatmake "Name of Catalog File to Create--"'. This line will be used to generate a command when the user types a 'C' (upper or lower case is equivalent). We can also see that the program named CATMAKE is going to be invoked. But what does the MENU program do with the characters enclosed with quotation marks? The answer is that MENU uses this as a prompt to the user, and and gives the user the opportunity to enter some data, followed by a . Then MENU substitutes this operator input for the text enclosed by quotation marks into the command line it is building. In this example, where the user had typed a 'C', and when prompted with 'Name of Catalog File to Create --' had responded with 'MASTER.CAT', the resulting command line generated and sent to the ZCPR3 Command processor for execution would be: CATMAKE MASTER.CAT The program CATMAKE.COM would be invoked by the ZCPR3 Command Processor (because CATMAKE is not an intrinsic command), and CATMAKE expects a command line parameter of the filename to be created, so it will then create MASTER.CAT. When CATMAKE terminates, the first section of the .MNU file will be presented to the user, and MENU will await another keystroke to generate the next command. The MENU system does not require that programs used within it be specially designed for use under the Z-System as the DISCAT programs are: any executable program may be called from within a MENU. MENU also offers options to the systems integrator as to whether end users will be allowed to terminate the MENU program or not, and has a debug mode of operation as well. The net result of using MENU in your turnkey system is that no longer will users have to be highly trained in the commands necessary to run the system; instead, the MENU system can function as a command "translator" so that even users who are not trained at all can use the system, without having to go through the training necessary to accomplish the same result in your application. Also, your system can become modular, with a array of small programs, instead of one large program with overlays, etc. It is even possible that you could cut back on the RAM required in your system, and reduce hardware costs. .pa S U M M A R Y The Z-System is a genuine third generation operating system that is extremely flexible and possesses features found in no other operating system. It can greatly enhance the efficiency of microcomputers no matter what application. For information about the Z-System, contact: Echelon, Inc. 101 First Street Los Altos, CA 94022 Phone (415) 948-3820 Modem 212-type (415) 489-9005 .pa Memory Map of the Z-System ----------------------------- Top of RAM (RAMTOP) | ZCPR3 External Stack | ----------------------------- RAMTOP - 30 Hex | ZCPR3 Multiple Command | | Line Buffer | ----------------------------- RAMTOP - 100 Hex | ZCPR3 Named Directory | | Segment | ----------------------------- RAMTOP - 200 Hex | ZCPR3 External File | | Control Block | ----------------------------- RAMTOP - 230 Hex | ZCPR3 Message Buffers | ----------------------------- RAMTOP - 280 Hex | ZCPR3 Shell Stack | ----------------------------- RAMTOP - 300 Hex | ZCPR3 Environment | | Descriptor Segment | ----------------------------- RAMTOP - 400 Hex (ENVBASE) | ZCPR3 Flow Control Package| | Segment | ----------------------------- ENVBASE - 200 Hex | ZCPR3 Input/Output | | Package Segment | ----------------------------- ENVBASE - 800 Hex | ZCPR3 Resident Command | | Package Segment | ----------------------------- ENVBASE - 1000 Hex (SEGMENTBASE) | BIOS with modified Cold | | Boot Routine | ----------------------------- SEGMENTBASE - Length of BIOS (BIOSBASE) | ZRDOS (Z80 Replacement | | Disk Operating System) | ----------------------------- BIOSBASE - E00 Hex (BDOSBASE) | ZCPR3 Command Processor | | (Replaces CP/M's CCP) | ----------------------------- BDOSBASE - 800 Hex | TPA (Transient Program | | Area) | ----------------------------- 0100 Hex | Page 0 Buffers and | | Reserved Locations | ----------------------------- 0000 Hex Figure 1. The Z-System uses up to 5 kbytes more RAM than a conventional CP/M-80 system. Many of the Segments may be omitted to reduce this overhead. .pa Comparison of the Z-System, CP/M-80, and MS-DOS Z-System CP/M 2.2 MS-DOS 1) Compatible with CP/M 2.2 software Yes Yes No 2) Terminal-independent video capabilities Yes No No 3) No warm boot required when changing disks Yes No Yes 4) User-definable shell capability Yes No Yes 5) Multiple ASCII-programmable shells included Yes No No 6) Integration of stand-alone executable programs via menus Yes No No 7) Multiple dynamically loadable ram- resident command packages included Yes No No 8) Named directories with optional password security Yes No No 9) Searching of alternate directories for invoked programs and files Yes No No 10) Conditional testing and execution at the operating system level (IF/ELSE/ENDIF) Yes No No 11) Dynamically variable user privilege levels for commands Yes No No Table 1. The Z-System possesses many advanced features, of which MS-DOS contains only a few. .pa ; ; M80.ZEX -- MACRO-80 Assembler and Linker ; with M80 Error Checking ; ; ^& Suppress FALSE IF Printout ; if nul $1 ;note Print Error Message echo ^G**** No Parameter Specified **** else ;note Perform Assembly if ~exist $1.MAC ;note Print File Not Found echo **** File Not Found **** else M80 =$1 FINDERR if 0 ;note No errors found, link file ERA $1.BAK ERA $1.COM L80 /P:100,$1,A:VLIB/S,A:Z3LIB/S,A:SYSLIB/S,$1/N,/U,/E else if 0 2 ;note see if the errors are warnings echo ^G***WARNING ERROR*** if input Type T to Continue or F to Abort (Warning Errors) ERA $1.BAK ERA $1.COM L80 /P:100,$1,A:VLIB/S,A:Z3LIB/S,A:SYSLIB/S,$1/N,/U,/E fi ;note on IF INPUT else ;note error is fatal echo ^G***FATAL ERROR IN ASSEMBLY*** fi;fi ;note IF REG 0 and IF REG 0 2 ERA $1.REL fi;fi ;note on IF NUL and IF ~EXIST ; ; Assembly Complete ; Listing 1. An example ZEX file that automates the assembly and link process using the Microsoft M80/L80 assembler/linker. This example makes use of the Z-System's conditional testing capability (IF/ELSE/ENDIF) to determine various error conditions. .pa -dxp # DISCAT Menu SubSystem 1 -- MASTER Catalog Functions -- -- WORKING Catalog Functions -- F - Free Space Scan 1 - Update WORKING Catalog M - Merge WORKING Catalog into 2 - Delete WORKING Catalog MASTER Catalog 3 - Cleanup WORKING Files S - Scan MASTER Catalog U - Update MASTER Catalog V - Verify MASTER Catalog -- General Catalog Functions -- -- Miscellaneous Functions -- B - Backup the MASTER Catalog W - VFILER C - Create a New Catalog File X - Dir N - Place a Name on a Disk Z - ZCPR3 Cmd # f!catfree "Names of Disks -- " m!catmerge working s!catscan "Input Files and Disks to Scan For -- " ucatupd /r v!catcheck master bmcopy master.cat m ccatmake "Name of Catalog File to Create -- " ncatname B31:"Name of Disk -- " 1catupd /wr 2era working.cat 3era *.bak;era working.cat wvfiler x!xd z!"Enter Command Line -- " ## Listing 2. An input file to the MENU.COM Shell. The file consists of two sections. The first section is displayed to the user, and the second section is used by the MENU.COM Shell to interpret the input by the user.