CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / jsage / znode3 / tcj / tcj43.wz / TCJ43.WS

Wrap

Text File | 1993-06-07 | 13.3 KB | 237 lines

TCJ #43 The Z-System Corner Jay Sage This time my column is going to be quite short. In response to myì requests, a number of authors have submitted some very interesting articles,ì but there has not been enough space to print them. I want to make sure thatì those articles are not delayed further. One of them is on the superb LSHì history shell by Rob Friefeld, who has contributed quite a number ofì excellent Z-System programs (SALIAS, VCOMP, and BCOMP, to name a few). Youì should not miss that article. After working first with the original Z-System history shell (HSH byì Michael Rubenstein) and then with EASE by Paul Pomerleau, it occurred to meì that it would be even nicer to have a full-screen history shell. What Iì envisioned was bringing the full resources of a wordprocessor to bear on theì command transcript, so that commands could be easily viewed, modified,ì reordered, and regrouped. If the history file were a standard ASCII file,ì then one could massage the file with a standard editor or even prepareì 'history' scripts in advance for special purposes. After seeing the splendid full-screen work Rob Friefeld had done in hisì SALIAS (Screen ALIAS editor), I asked him if he would take on the task ofì writing such a history shell. He did, and he has done a splendid job. Iì would, therefore, like to publicly take credit for that all-importantì management skill of asking the right person to do a job! Software Update Service While Echelon was still in business marketing the Z-System, they offeredì a very nice product called SUS or Software Update Service. People who haveì modems and a nearby Z-Node or RCP/M system generally do not have muchì trouble picking up the latest releases of public-domain Z-System and generalì CP/M software. However, for those who do not have modems or for whom theì nearest Z-Node is an expensive long-distance call, obtaining a full set ofì Z-System tools or keeping up with new releases is much more difficult. ì The Echelon SUS was designed to solve that problem by making the materialì available on diskette by mail. It was a disk subscription service, andì roughly every month subscribers would get a diskette full of public-domainì software. I am happy to announce that SUS is coming back, thanks to the urging andì energy of Chris McEwen, sysop of the Socrates Z-Node (#32), in Plainfield,ì NJ. Chris and Bill Tishey, together with Sage Microsystems East, will beì offering an even more extensive service than Echelon's. Bill Tishey, asì most of you know, has for some time been maintaining a complete catalog ofì Z-System programs (ZFILESnn.LST) and a compendium of HLP files covering allì of them. At frequent intervals, Bill releases an update LBR with all theì new help files. Now, in addition to that service, Bill will be puttingì together diskettes with the software as well as the documentation. This means that you will be able to purchase diskettes with the completeì set of Z-System programs and/or subscribe to a monthly update service. Billì and Chris will be handling most of the diskette production; SME will handleì the orders and bookkeeping and will produce diskettes in the few formatsì that Chris and Bill cannot handle (8" IBM SSSD, NorthStar hard-sector, andì Amstrad 3"). We have not yet worked out all the pricing details for all the options,ì but by the time you are reading this column, we will have flyers availableì with all the information. Just drop me a letter or postcard, or leave aì message for me in any of the ways indicated in the sidebar to this column,ì and I will get a flyer to you. To give you some idea of what we are talkingì about, a 6-month SUS subscription to a US address will probably be $48 ($8ì per disk) and a year's subscription $72 ($6 per diskette). As you can see,ì we are trying to keep the price very low. We really want all of you to beì able to get and use all these wonderful programs. Fully Customizing NZCOM My technical topic for this time will be about designing fully customizedì NZCOM Z-Systems. I have always been satisfied with the systems that can beì produced so easily using the MKZCM (MaKe nZCoM) menu-driven utility, and soì I never really delved into this area very much. About a week or so ago,ì however, Dave Goodman brought the problem to me. He has a NorthStar Horizonì with an add-on hard disk, and the operating system has a ROM stuck somewhereì in the middle of the address space. That left some disjoint blocks of freeì memory, and Dave really wanted to make use of all the space. I told him myì standard answer to that problem. In section 5 (especially subsection 5.2.3) of the NZCOM manual, I pointì out that the NZCOM system is defined by a descriptor file and that this fileì (with type ZCM) is a pure ASCII file that can be edited with one's favoriteì text editor. The manual recommends that everyone make certain changes soì that the descriptor will properly reflect the user's hardware environment,ì such as the disk drives available and the characteristics of the system'sì printer and terminal. I did not actually come out and say it explicitly, but there is anì implication that other values in the ZCM file can also be changed. Theì truth is, I believe, that I avoided this subject in part because I was notì entirely sure which values could and which values could not be changed. Myì suggestion to Dave Goodman was that he experiment with designing a customì memory map for his system, edit the values into the ZCM file, and see whatì happened when he tried to load it. Dave's report back to me, now confirmed by my own experiments on myì Televideo 803H, indicated that ALL values can be changed. The onlyì requirement is that the values provide a memory map with no modulesì overlapping. When you use MKZCM to design the system, it takes over theì responsibility for generating a valid memory map; if you do the designì yourself, you better be careful. A Helpful Utility This suggests a very nice utility program that some thoughtful soul couldì contribute to the community. This utility (let's call it ZMAP) might do aì number of helpful things. First, it could display, perhaps in someì graphical or semi-graphical way, the memory map of a Z-System, the oneì actually running or one specified in the form of a ZCM or ENV file (andì maybe even the Z3PLUS descriptor file of type Z3P). Present utilities, suchì as SHOW (ZSHOW) and Z3LOC, list the module addresses in a fixed order, notì in order of increasing memory address. Thus they are not very helpful inì determining if there are gaps or overlaps in the map. Ideally, ZMAP wouldì flag any such defects or potential defects in the map so that they could beì corrected before they cause harm. The final item on my wishlist -- and this might better be implemented inì a second, independent program (ZDESIGN perhaps) -- would be a general Z¡ System designer, along the lines of MKZCM but without its restrictions. Oneì would be able to specify the order of all the modules in memory and theirì sizes. Given the highest memory address available, the program would thenì figure out and display the memory map. One should be able easily to alterì the order of the modules, and one should be able to override specificì addresses to create gaps if necessary (but not to force overlaps). Once theì desired system has been designed, the program should write out a ZCM or ENVì file for it. Such a program is a good candidate for implementation with aì high level language such as BDS Z or Turbo Pascal. And it sure would haveì helped me with the experiments that I am about to describe (several mistakesì resulted in crashes). My Experiments Fig. 1 shows a printout of the standard NZCOM.ZCM file on my Televideoì 803H. It has already been customized in several ways using MKZCM. First,ì it allocates a 4-record VBIOS. I use a version that fixes the 803's fauxì pas of clobbering the index registers during BIOS calls and implements aì check of the Z-System drive vector for BIOS disk-select calls as describedì in a previous column. It also has room for a 20-record RCP, which allows meì to use a full-featured RCP with Carson Wilson and Rob Friefeld's residentì history shell, CLED (see RCPZRL11.LBR on Z-Nodes). ----------------------------------------------------------------------------- E606 CBIOS 0080 ENVTYP E3F4 EXPATH 0005 EXPATHS D300 RCP 0014 RCPS 0000 IOP 0000 IOPS DD00 FCP 0005 FCPS DF80 Z3NDIR 0023 Z3NDIRS E400 Z3CL 00CB Z3CLS E280 Z3ENV 0002 Z3ENVS E200 SHSTK 0004 SHSTKS 0020 SHSIZE E380 Z3MSG E3D0 EXTFCB E4D0 EXTSTK 0000 QUIET E3FF 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 0000 SPAR2 0000 SPAR3 0000 SPAR4 0000 SPAR5 BB00 CCP 0010 CCPS C300 DOS 001C DOSS D100 BIO 0000 PUBDRV 0000 PUBUSR Figure 1. The ZCM descriptor file for the normal NZCOM system I use on myì Televideo 803H computer. ----------------------------------------------------------------------------- I decided to be cautious, especially after one of my new system designsì caused the system to hang, and I made a series of systems, each differentì from the previous one in a relatively small way. I am not going to show youì all the steps along the way but will go right to the most radicallyì different version. See Fig. 2. If you look carefully, I think you willì find that only the command line buffer (Z3CL) is still in the same place asì it was in the original system (but it is bigger now). ----------------------------------------------------------------------------- E606 CBIOS 0080 ENVTYP E3F4 EXPATH 0005 EXPATHS D700 RCP 0014 RCPS 0000 IOP 0000 IOPS D480 FCP 0005 FCPS D200 Z3NDIR 0023 Z3NDIRS E400 Z3CL 00FB Z3CLS E180 Z3ENV 0002 Z3ENVS E100 SHSTK 0004 SHSTKS 0020 SHSIZE E280 Z3MSG E2D0 EXTFCB E300 EXTSTK 0000 QUIET E2FF Z3WHL 0004 SPEED 0010 MAXDRV 001F MAXUSR 0001 DUOK 0000 CRT 0000 PRT 0050 COLS 0018 ROWS 0016 LINS 000F DRVEC 0000 SPAR1 0050 PCOL 0042 PROW 003A PLIN 0001 FORM 0000 SPAR2 0000 SPAR3 0000 SPAR4 0000 SPAR5 BA00 CCP 0010 CCPS C200 DOS 001C DOSS D000 BIO 0000 PUBDRV 0000 PUBUSR Figure 2. A radically reconfigured NZCOM system produced by manuallyì editing the ZCM file. ----------------------------------------------------------------------------- Perhaps you are wondering why I didn't make the most dramaticì demonstration possible by changing absolutely every address (and perhapsì size, too). Well, there was an extra constraint that I was exploring withì this system. I am running ZDDOS, and I have specified that the clock driverì be loaded into the so-called user buffer. I have even applied the NZCOMì patch (NZCOMPAT.HEX) that comes with the ZSDOS/ZDDOS package so that whenì new system configurations are loaded, the clock driver will be reconnectedì to the DOS automatically without the need for running LDTIM again. If you know a lot about Z-System, you will know that there is no suchì thing as a user buffer! The user buffer is a special creature of NZCOM; itì is not defined in the Z-System environment descripter (or -- look closely --ì in the ZCM file). How, then, does one determine where this special gap inì the memory map of an NZCOM system is located? That is exactly what Iì wondered myself. I could have called ZDOS authors Cam Cotrill or Hal Bowerì and asked them how they infer its location, but I decided to experimentì instead. What I found after various trials and errors was that the NZCOMì patch seemed to be happy and able to find the LDTIM clock module so long asì the command line buffer stayed in the same place. Apparently, theì assumption is made that the user buffer is the memory from 100H above theì start of the command line buffer up to the real CBIOS (E400 to E5FF in myì case). I did not perform exhaustive tests of this hypothesis. Let us just sayì that it is not terribly prudent to try to make use of a 'user buffer' with aì fully customized system. It would be wiser to design the system with a gapì below the CBIOS for the clock driver and to create a version of LDTIM withì an explicit load address. The NZCOMPAT patch should be omitted from NZCOMì if such custom systems are going to be used. A Few Bugs There were a few bugs in NZCOM that surfaced during this testing thatì suggest that NZCOM.COM was not quite designed to work rigorously and toì handle the most general system loading situations. Sometimes I found thatì NDR modules became empty, and the command search path was rarely preservedì with these systems. Code-containing modules, such as the FCP, RCP, DOS, andì so on, cannot be moved from one address to another. If their startingì address changes, the code must be reloaded fresh from the ZRL file. On theì other hand, modules that contain data, such as the NDR, shell stack, path,ì message buffer, and so on, can and should be moved to any new address, soì long as there is room for the old contents in the new home. NZCOM sometimesì failed to do this. Maybe now that I have uncovered these small problems, Iì can pass the information on to Joe Wright, and he can fix up the code toì handle these situations.