CP/M

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

/ CP/M / CPM_CDROM.iso / jsage / znode3 / tcj / tcj28.mag < prev next >

Wrap

Text File | 1994-09-02 | 40.3 KB | 815 lines

The ZSIG Column #4, March 9, 1987 The ZSIG Corner Jay Sage For this issue I will finally get to my long promised discussion ofì techniques for customizing the Z-COM automatic installation version of theì Z-System. Before turning to the main subject, however, there are two otherì items I would like to cover. One is some follow-on discussion to theì material I presented last time on recursive aliases; the other is aì description of the latest ZSIG releases. More on Recursive Aliases ------------------------- Art Carlson forwarded to me a letter he received from Dreas Nielsen inì response to my discussion of recursive alias techniques using VALIAS andì ARUNZ. Dreas, well known in the ZCPR community for his excellent shellì utility programs, GETVAR and RESOLVE, took me to task for doing somethingì the hard (and not quite correct) way when there was a not-too-hard andì completely correct way to do it. And he proved it by offering a marvelousì technique for 'recursing' aliases without any of the problems I warned aboutì with my technique. To me this is a wonderful example of the richness ofì ZCPR3. No matter how thoroughly one knows it, there are always significantì new techniques and applications to be discovered. The learning andì excitement never ends! We will illustrate the technique using a simple example based on theì following script that is designed to display a message on the screen showingì how many times it has been run already. The script is alias ONELOOP: ECHO THIS IS LOOP NUMBER REG P6 As the ZCPR3 user register number 6 is incremented using the 'P'-for-plusì option, its new value is displayed on the screen. If we wanted to make the alias operate recursively, our first instinct,ì as described in my previous column, would be to expand it to the following: alias MANYLOOP: ECHO THIS IS LOOP NUMBER REG P6 ECHO DO IT AGAIN? IF IN MANYLOOP FI As I explained last time, the trouble with this is that each time we runì through the loop by answering the input prompt affirmatively we go one IFìèlevel deeper and accumulate another FI on the end of the command line. ì Eventually either the command line becomes too long or, more likely, weì exceed the allowed eight levels of IF nesting. Dreas's idea is based on turning this alias around so that there is noì FI on the end to accumulate. He permutes it to the beginning of the scriptì and writes the alias this way: alias RECURSE2: FI ECHO THIS IS LOOP NUMBER REG P6 ECHO DO IT AGAIN? IF IN RECURSE2 If this alias is invoked with a 'true' IF level already in effect, this willì work just fine. The alias will drop one IF level lower at the FI command,ì do its main work, and return to the original IF level with the "IF IN"ì prompt. If the answer is affirmative, we will be back in the very same IFì state we were in when the alias was invoked the first time. The alias willì be re-invoked, and the whole operation will repeat. On the other hand, ifì the answer to the prompt is negative, the alias will stop running, and weì will fall out the bottom at the same IF level as we entered originally butì in the 'false' state. To deal with the need to enter one IF level higher and to terminate theì 'false' IF state at the end, we simply call the above alias from anotherì alias with the following script: alias RECURSE: IF TRUE RECURSE2 FI The "IF TRUE" command will push us one IF level deeper and put us in aì 'true' state. (This, by the way, is the first time that I have ever seen aì use for the "TRUE" option with the IF command. If, like me, you neverì implemented that option because you could not figure out what on earth itì could possibly be used for, you can substitute any other option that isì guaranteed to return a 'true' state, such as "IF NULL" with nothing after itì or "IF A=A"). The RECURSE2 alias will now run as we described earlier, andì when the recursion is terminated by a negative answer, the FI in RECURSEì will terminate the resulting 'false' IF state and return us to the originalì IF level that we were at when RECURSE was invoked. One has to stretch things a bit to come up with any disadvantages toì this technique. The best I can do is the following two minor points. ì First, two aliases are required to get things started, and this will slowì things down a bit, especially on a floppy-disk system. Secondly, theì technique, while simple in principle, may not be easy to remember when oneì wants to set up a quick recursive alias, as in the application I describedì in my last article. The VALIAS/ARUNZ-type recursive alias may still beì useful in such a case. If you are a purist and have a strong, perhaps even irresistible, urgeì to do things right (and especially if you have a RAM disk so that you canìèafford to indulge such compulsions), Dreas's technique can be nicelyì automated by creating the following two slightly more complex andì generalized aliases: alias RECURSE IF NULL $1 ECHO SYNTAX: $0 ALIASNAME PARAMETERS ELSE RECURSE2 $* FI alias RECURSE2 FI $* ECHO RUN "$1" AGAIN? IF IN $0 $* Now suppose we have our edit/assemble/link alias as follows (where it, inì turn, calls on the SYSLINK alias to perform the linkage with the libraries): alias WORK EDIT $1.Z80 Z80ASM $1/R IF ~ERROR SYSLINK $1 FI If we enter the command "RECURSE" all by itself, we will get the ì message "SYNTAX: RECURSE ALIASNAME PARAMETERS". If we enter the commandì "RECURSE WORK MYPROG", the "IF NULL" test in RECURSE will be 'false' butì will be toggled 'true' by the ELSE command. Then RECURSE2 will be invoked,ì and the command line and IF status will progress as shown in Fig. 1. Theì "..." in the IF states designates any IF levels in effect at the time thatì RECURSE was called. Similarly, the command text 'pending' designates anyì command-line text following the invocation of RECURSE. The figure does not show the operation of every command. Theì edit/assemble/syslink sequences are not shown in detail. Between steps 8ì and 9 we assume that the "IF IN" prompt was answered with a 'Y'. Thisì brings us at step 9 back to the exact state we were in at step 4, and stepsì 4 through 8 will be repeated over and over so long as the "IF IN" prompt isì answered affirmatively. Between steps 10 and 11 we assume that the "IF IN" prompt was answeredì with 'N', so we get the state shown in step 11. Since the current IF stateì is 'false', the command "RECURSE2 WORK MYPROG" is flushed, leaving us atì step 12. The FI command terminates the 'false' IF and drops the flow stateì one level lower. Any pending commands that were on the command line afterì the invocation of RECURSE are now free to run at step 13. I just tested out these aliases on my SB180 by putting them into myì ALIAS.CMD file, which lives on the RAM disk. The scripts had to be alteredì slightly, with all invocations of RECURSE2 from within RECURSE and RECURSE2ì being replaced by "ARUNZ RECURSE2 ..." or "ARUNZ $0 ...". They worked likeì an absolute charm. Thank you Dreas Nielsen!!! ------------------------------------------------------------------------------ è Step IF state Command Buffer Contents ---- -------- ----------------------- 1 ... RECURSE WORK MYPROG;pending 2 ... IF NULL WORK MYPROG;ECHO SYNTAX: RECURSE ALIASNAME PARAMETERS;ELSE;RECURSE2 WORK MYPROG;FI;pending 3 F... ELSE;RECURSE2 WORK MYPROG;FI;pending 4 T... RECURSE2 WORK MYPROG;FI;pending 5 T... FI;WORK MYPROG;ECHO RUN "WORK" AGAIN?; IF IN;RECURSE2 WORK MYPROG;FI;pending 6 ... WORK MYPROG;ECHO RUN "WORK" AGAIN?;IF IN RECURSE2 WORK MYPROG;FI;pending 7 ... EDIT MYPROG.Z80;Z80ASM MYPROG/R;IF ~ERROR; SYSLINK MYPROG;FI;ECHO RUN "WORK" AGAIN?; IF IN;RECURSE2 WORK MYPROG;FI;pending 8 ... ECHO RUN "WORK" AGAIN?;IF IN;RECURSE2 WORK MYPROG;FI;pending 9 T... RECURSE2 WORK MYPROG;FI;pending 10 ... ECHO RUN "WORK" AGAIN?;IF IN;RECURSE2 WORK MYPROG;FI;pending 11 F... RECURSE2 WORK MYPROG;FI;pending 12 F... FI;pending 13 ... pending Fig. 1. Evolution of the command line and IF states as the operation of theì command "RECURSE WORK MYPROG" unfolds. ------------------------------------------------------------------------------ A Z-Letters Feature ------------------- Thanking Dreas Nielsen for his letter reminds me that Art Carlson and Iì would like very much to start up a Z-Letters feature in TCJ, a kind ofì letters-to-the-editor section specializing in Z-System questions, comments,ì discussion, and ideas. I am willing to handle answering or otherwiseì responding to those letters, but I will depend on you readers to send themì in. And rest assured that we are not looking only for letters like Dreas'sì containing brilliant suggestions. A good set of simpleminded questionsìèwould be quite well appreciated, thank you. They would help us a great dealì in learning what aspects of Z-System are confusing to users so that we canì try to clarify them. New ZSIG Releases ----------------- We have quite a few excellent new programs to release on ZSIG diskettesì this month. I have not yet finalized exactly what will be included onì release diskettes #2 and #3, but I don't want to pass up this opportunity toì publicize them. First of all, I am very happy to report that all the programs Iì proposed two issues back have now been written, and I will describe themì first. K;S4;I4 FCP10.LBR This is the new flow control package (FCP) that I wrote with valuableì assistance from Howard Goldstein (New Haven, CT). This program wasì described in some detail in the last column, so I will not say too muchì about it here. The two most important innovations are 1) the additionì of AND and OR commands and 2) the FCP's ability to load and run IF.COMì in high memory where it will not interfere with data in the beginning ofì the transient program area at 100H. COMIF10.LBR This is the companion transient IF processor that is intended to replaceì IF.COM. Also described last time, it offers an enormous number of newì test conditions and syntax forms. This one was also written by meì together with Howard Goldstein. SETPATH1.LBR This is an extended version of the original PATH command. It allows oneì optionally to add and remove path elements from the beginning or the endì of the existing path. The path display is also improved. Robertì Demrow, a fellow member of the Boston Computer Society CP/M Group wroteì this one. EDITND.LBR Al Hawley (Z-Node #3 in Los Angeles) really went all out with tools toì work with the named directory register (NDR). EDITND lets one edit theì names directly in the NDR. Names and/or passwords can be added,ì deleted, and changed. SAVNDR.LBR After you've edited the NDR, this program lets you save the results toì an NDR file. Again by Al Hawley. è LOADND12.LBR The last in the Hawley set, this program can automatically update theì names in the NDR using either the special file name system in LDSK or byì loading an NDR file whose names are applied to the current floppy diskì only. The next ZSIG release will also include the following programs. ZPATCH11.LBR This is another masterpiece from Steve Cohen (Chicago, author of 'W',ì the wildcard shell, on the first ZSIG diskette). It is by far the bestì file patcher I have ever seen -- a real joy to use. Steve sure isì clever when it comes to shells! Who would have thought to make a fileì patcher into a shell? But this way one can run a command from insideì ZPATCH and then return to one's exact place to continue working. Theì 'X' command in ZPATCH automatically runs the file one is currentlyì patching (provided it is a COM file) so that one can see the effect ofì the changes. Marvelous! MEX2Z.LBR This is yet another brainstorm of NAOG chief Bruce Morgen (who has quiteì a stormy brain). MEX2Z and my adaptation of it for MEX-Plus, MEX+2Z,ì give the MEX communication programs the ability to 'shell', that is, toì run a Z-System command apparently from within MEX. For example, if youì enter the MEX command line "CPM;CRUNCH FN.FT", you will exit from MEX,ì the file will be crunched, and then you go right back into MEX. This isì especially handy when you are trying to debug a MEX script. Bruceì picked up on the very clever trick introduced by Ted Emigh in FINDERR,ì namely, running a program that examines information left behind inì memory by the program that ran before it. In this case it is the MEXì command line buffer that is picked up. Even if you don't use MEX, it isì worth looking at these programs just for their educational value. FF10.LBR I finally decided to do something about the shortcomings of FINDF, theì utility for determining where files are located in your system. FF hasì a 16-bit configuration word that can be patched (roll out ZPATCH!) toì define which drives should be searched by default (this is particularlyì useful when your constellation of drives has a hole in it, such as A, B,ì C, and F). You can override the default drive list by specifying a setì of drives to scan on the command line. A whole list of fileì specifications can be given, and each one is automatically wildcarded,ì saving the user a lot of typing. If you want to find all programsì starting with "SD", just enter "FF SD". The "SD" turns into "SD*.*"ì automatically. Similarly, "FF .LBR" will find all library files. "FFì SD,.LBR" will find both. PPIP15.LBR è This is the next step in the evolution of PPIP (PPIP14 is on ZSIGì diskette #1). The main addition is support for DateStamper time andì date stamping. Having fallen in love with DateStamper, I just had toì have some file copying tools that would preserve the time and dateì information, so I added that capability to PPIP and to ZFILER. ERRSET11.LBR This little tool lets you either display the current or directly enter aì new error handler command line. Strictly speaking, error handling inì ZCPR3 is not performed by loading an error handling program but byì executing an error handling command line. This command line is storedì in a 16-byte string in the message buffer. When an error handler isì installed by invoking its name manually from the command line, it writesì only its name alone into that buffer. ERRSET lets you enter a completeì error command line, such as A15:VERROR. By including an explicit DU: orì DIR: form, the error handler will be found and loaded faster. On theì other hand, ERRSET will let you enter the name of a nonexistent errorì handler, so watch out. Power has its price. Written by yours truly. R76;I8 Customizing Z-COM ----------------- We now turn to the piece-de-resistance for this article -- a discussionì of techniques for customizing Echelon's automatically installing Z-Systemì package known as Z-COM. This will be the first of a two-part series. Thisì time I will cover the more elementary aspects of the subject, thoseì modifications that can be made by changing only data structures in the Z-COMì files. Next time I will delve into customization techniques that involveì serious hacking (such as modifying the Z-COM code itself). I will begin with an overview of what Z-COM is, the philosophy behindì it, the procedure for installing it on a particular computer, and how oneì uses it to create a Z-System automatically. Then I will give an elementaryì discussion of how it works and the structure of the COM file that magicallyì transforms one's ordinary CP/M machine into a 'Z' machine. Next I will showì you how to make some simple patches that eliminate the initializationì operations that are performed by the startup file and make Z-COM come upì ready to go instantly. This includes setting the wheel byte, defining theì symbolic command search path, putting in the terminal capability descriptorì (TCAP) for the user's terminal, installing the user's named directories,ì installing an external error handler, and even setting up an initial shell. With those techniques mastered, we can then go on to make changes toì the system modules. The simplest of these is replacing the standard ZRDOSì that comes with Z-COM with the latest-and-greatest Public-ZRDOS-Plus versionì 1.7. Slightly more complex is the replacement of the environmentì descriptor (ENV) and the two command modules: the RCP (resident commandì package) and the FCP (flow control package). For these changes we have toì edit some configuration files, assemble new code modules, and install theì new modules into the Z-COM file. By this point you will be ready toìègenerate and install a new version of the ZCPR3 command processor, anì operation that requires one important extra step (a simple one, but one thatì must not be overlooked). Why Z-COM Consider this situation. The Z-System is a wonderful replacement forì CP/M, one that greatly enhances the utility and ease of operation of anì 8-bit Z80-compatible computer. I can't understand why anyone would notì enjoy and benefit from its features and capabilities. However, installingì it in the conventional fashion required changing the BIOS (Basic Inputì Output System), the hardware-dependent part of the operating system. ì Unfortunately, many (actually most) manufacturers consider their BIOS to beì proprietary (or embarrassingly poorly written), and they refuse to releaseì the source code. And even if they do make it available, perhaps for anì extra fee, what if you do not know how to make the required changes toì support the ZCPR3 command processor? Well, enter Z-COM. Z-COM was the brilliant conception of Joe Wright, the nation'sì preeminent BIOS writer (author of the BIOSes for the Ampro Little Board,ì Micromint SB180, and the soon-to-be-available ON! computer from Oneac). ì With Z-COM one does not need the BIOS source code because there are noì changes to make in it. One doesn't even need MOVCPM. Z-COM runs on almostì any standard CP/M 2.2 system, converting it in situ to a Z-System. Thereì are a few CP/M 2.2 computers on which Z-COM will not work (usually becauseì at least some part of their memory space operates in a funny way), but theì great majority will. For those of you with CP/M version 3 (aka CP/M-Plus --ì a real misnomer in my opinion), I'm afraid you are out of luck. CP/M 3 isì fundamentally different from CP/M 2.2, and no one has yet been able toì concoct magic powerful enough to transform it into a Z-System. I hope my discussion here will inspire some of you to purchase Z-COM. ì If it does, then see the ads in TCJ by Sage Microsystems East and Echelonì for more information. I personally think that a modified Z-COM is the bestì way to implement Z-System, because, as we will see by the end of this seriesì of articles, it gives one far greater flexibility than with a manuallyì installed system. Installing Z-COM Here is a brief description of how one gets Z-COM running on one'sì system. The standard procedure goes like this. Take a freshly formattedì disk, 'sysgen' the CP/M 2.2 operating system to it, copy onto it all theì files on the Z-COM release disk, put this disk into drive A, and reboot theì system either with the reset button or by entering control-c. Now enter theì command "SUB ZCCOM". This starts a batch operation, and you can now sitì back, relax, and watch your computer do all the work. Toward the end of theì process, which takes a couple of minutes, a program called TCSELECT will runì and ask you to choose your terminal from a large menu. The result will be aì file called MYTERM.Z3T containing information about your terminal thatì permits Z-System programs to perform screen operations without installation. è What's Going On During Installation In the first part of the installation process, the Z-COM systemì creation program ZCLD.COM determines the memory address at which your BIOSì operates and generates a corresponding Z-System. To do this, it reads in aì number of special relocatable files (most with file type SPR, which standsì for system page relocatable) and produces four new files: ZC.COM, ZCX.COM,ì ZC.ENV, and ZC.CP. The first file, whose operation we will describe inì detail below, is the one that transforms the vanilla CP/M system to theì amaretto-double-chocolate almond Z-System with jimmies (if you don't knowì what jimmies are, ask someone from Boston). The second file, ZCX.COM, is a program that transforms you back. Why,ì you ask, would one ever go back to vanilla after experiencing the ecstasy ofì amaretto-double-chocolate-almond? Well, Z-System does have one significantì drawback. You don't get all those great features for free. They cost aì considerable chunk of TPA (transient program area) -- 5.5K in the case of Z-COM (though we will see next time how to reduce this if you are willing toì forego some of the features). The smaller TPA has almost never caused anyì problem with the programs I use, but some people do have problems, and it isì nice to know that a simple "ZCX" command will bring back the old CP/M withì its full-sized TPA. Next time I will explain how we can even change to aì different Z-COM system with a larger TPA. The third file, ZC.ENV, is the environment descriptor file for theì system that ZCLD created. It is automatically included in ZC.COM, so itì does not have to be loaded using LDR, but it is used by Z3INS to install theì environment information into the utilities. The last file, ZC.CP, does not even appear in a directory listing; itì is hidden up in user area 15, out of harm's way. The user is not normallyì concerned with this file, though if you want to create another Z-COM systemì disk, you have to remember to copy it, as well as the others mentionedì above, to the new diskette. We will discuss its purpose later. How ZC.COM Works As we said above, ZC.COM is the program that transforms your mundaneì CP/M system into an exciting and powerful Z-System. How does it do it? ì Several simple principles are involved. ZC.COM is basically a loader program. The file itself consists of twoì parts. The first page of code (100H to 1FFH) is the loader code. Theì second part (200H to 2DFFH) is the memory image of a Z-System that is copiedì into place by the loader. The process is like the 'big bang' theory ofì creation -- the whole Z-System just appears complete in one operation! The memory map of the ZCOM-System generated for my BigBoard I computer,ì on which I performed these experiments, is shown in Fig. 2. Its real CP/Mì BIOS is at E800H. The Z-System addresses were determined by running theì utility SHOW.COM after Z-COM was loaded. The corresponding addresses in theìèZC.COM file were obtained by inspecting it with a debugger. Once a fewì addresses (like the RCP and FCP, which have obvious headers), wereì determined, the rest was obvious. The ZC.COM system image is at a constantì offset from the real system. In this example, that offset is BA00H. If Z-COM is installed on a different system, the real system addresses and theì offset value will be different, but the addresses of the system segments inì the ZC.COM image will be the same. In general, the offset between theì corresponding addresses will be 2E00H less that the address of the nativeì BIOS. ----------------------------------------------------------------------------- System Component ZC.COM Address System Address ---------------- -------------- -------------- CPR 0200 - 09FF BC00 - C3FF ZRDOS 0A00 - 17FF C400 - D1FF Virtual BIOS 1800 - 19FF D200 - D3FF Named Directory Register 1A00 - 1AFF D400 - D4FF Shell Stack 1B00 - 1B7F D500 - D57F Z3 Message Buffer 1B80 - 1BCF D580 - D5CF External FCB 1BD0 - 1BF3 D5D0 - D5F3 PATH 1BF4 - 1BFE D5F4 - D5FE Wheel Byte 1BFF - 1BFF D5FF - D5FF Environment Descriptor 1C00 - 1C7F D600 - D67F TCAP 1C80 - 1CFF D680 - D6FF Multiple Command Line 1D00 - 1DCF D700 - D7CF External Stack 1DD0 - 1DFF D7D0 - D7FF Resident Command Package 1E00 - 25FF D800 - DFFF Flow Control Package 2600 - 27FF E000 - E1FF I/O Package 2800 - 2DFF E200 - E7FF Fig. 2. Addresses of system components in the ZC.COM file and in theì example system for which it was generated. ----------------------------------------------------------------------------- How does this system function? If you are familiar with Z systems, youì probably recognize all of the system components above except for the oneì called 'virtual BIOS'. That is where the key to Z-COM lies. Remember, weì needed a BIOS that would run below the Z buffers, but we had no way toì relocate the actual BIOS. So instead we create a virtual BIOS -- a block ofì code structured just like a real BIOS. It has a table of jump instructions,ì one after the other, that perform the required BIOS functions: CBOOT, WBOOT,ì CONST, CONIN, CONOUT, LIST, and so on. How does this virtual BIOS actuallyì carry out those functions without knowing anything about the systemì hardware? Easy! It simply jumps to the corresponding entry points in theì real BIOS! Well, it actually is not quite that easy. There are a few specialì details that have to be taken care of. Most of the functions are performedì as described above, but there are some important exceptions. The mostì important one is the WBOOT, or warm boot, function. Normally when a warmì boot is performed, the CPR (and often the BDOS as well) is reloaded from theì system tracks of the A diskette. If that were allowed to happen here,ì goodbye Z-System! ZC.COM would only work until the first warm bootìèoccurred, and then we would have to run it again. Not very satisfactory! To prevent that from happening and to keep Z-COM running, the virtualì BIOS 'traps' warm boot calls. That is a fancy way of saying that instead ofì simply passing the call to the real BIOS it does the work itself. What doesì it do? Well, it has to reload the ZCPR3 command processor to the properì address, BC00H in this example. Since the ZCPR command processor does notì reside on the system tracks, we have to get it from somewhere else. Joeì Wright could have gotten it from records 2 through 17 in ZC.COM, but heì chose instead to maintain a separate file with just the image of the commandì processor. Remember the file ZC.CP that we mentioned earlier, the oneì stashed away in A15:? That's it. Although I don't know of any reason why CBOOT, the cold boot routine,ì would ever be called once the computer was initially booted up, the CBOOTì routine is also trapped by the virtual BIOS and vectored (another fancyì word) to the same code as the virtual warm boot. In Echelon's simpler auto-install package Z3-DOT-COM, which does notì have support for Input/Output Packages (IOPs), the story would now beì complete. The IOP, however, has to get first shot at some of the BIOS I/Oì routines, namely console status, console input, console output, list output,ì list status, punch output, and reader input. In a manual installation of Z-System with IOP support, the BIOS code would have to be modified. With Z-COM this is quite straightforward. The virtual BIOS calls to theseì functions simply go (are vectored) to the appropriate entry points in theì IOP module. The initial IOP code included in ZC.COM is just a dummy IOPì that simply turns around and forwards the calls from the IOP to the realì BIOS entry points. Easy Z-COM Patches Now that we understand what Z-COM is and how it works, we can start toì make some changes. If you look at the STRT startup alias with Z-COM, youì will see that it turns on the wheel byte, loads the TCAP and named directoryì register, and sets up the symbolic search path. For our first set ofì patches, we will eliminate the need for a startup alias. We will make theì system come up fully tailored to our preferences, and we will save the timeì wasted by the STRT alias. The first step is to get Z-COM running and to use the utility programsì to set it up as we like it. We will generally turn the wheel byte on (theì STRT alias presumably already ran WHEEL to do that for us). We can set upì our named directories using MKDIR and LDR or the new ZSIG named directoryì editor EDITND. We can choose our path using the PATH command or the newì ZSIG SETPATH utility. An external error handler can be defined in theì message buffer by invoking the desired error handler manually at the commandì line or by running the ERRSET utility (this can include a DU or DIRì specifier to speed up the search for the error handler). Finally, if weì want to, we can even invoke a shell, such as the history shell HSH. Now all we have to do is clone this system using our favorite debugger. ì If you can afford Echelon's DSD, I cannot recommend it highly enough. Itì will quickly spoil you. On the other hand, I will describe here theì procedure using Prof. Falconer's lovely DDTZ, a public-domain Zilog-mnemonicìèversion of DDT. Here is the sequence of commands to use. Don't forget thatì the addresses that refer to the real system are the ones for my BigBoard. ì You should make a table like that in Fig. 2 with the addresses for yourì system and make the appropriate substitutions in the commands below. A0:SYS>ddtz zc.com ; Run debugger and load ZC.COM -md400,d6ff,1a00 ; Copy running NDR, Shell Stack, MSG ; ..buffer, PATH, WHL, ENV, and TCAP ; ..into ZC.COM image -g0 ; Exit from debugger A0:SYS>save 2dh zcnew.com ; Save new version of ZC If you have a shell running while this process is being carried out, youì have to include the SAVE command on the same line as the DDTZ command, sinceì when the shell loads it wipes out the memory image in the TPA. By puttingì the SAVE command on the same line, it is run before the shell is reloaded. I have used the above technique and found it to work very nicely, but aì word of caution is in order. A purist would copy the memory areas only forì the specific segments to be modified. The external file control block andì the parts of the message buffer other than the byte at offset 0 (D580, whereì the error-handler-flag is kept) and bytes at offsets 10H to 1FH (D590-D59F,ì where the error handler command line is kept) would not be copied. Copyingì the entire message buffer works as described above, but if you try to make aì ZEX batch file to do this, you will get into trouble, since ZCNEW.COM willì then contain an image of the message buffer with the ZEX-running flag set. To test ZCNEW, make a new STRT.COM alias that just echoes a signonì message (first rename the old one in case you want it back later), run ZCXì to exit from Z-COM, and then run ZCNEW. Your own personalized Z-Systemì should pop (almost) instantly to life. After determining that it is reallyì working correctly, you can rename ZCNEW.COM to ZC.COM. Again, I recommendì keeping old versions with names like ZC1.COM, ZC2.COM, and so on, on anì archive disk. Putting in a New DOS Now let's make a change that could not be accomplished using utilityì programs, as all of the above changes could be. Let's replace the older,ì non-public version of ZRDOS that comes with Z-COM with the latest versionì 1.7 of Public-ZRDOS-Plus. The first part of the process is same as that inì a manually installed Z-System. One takes the ZRDOS generating programì ZRDINS17.COM, installs it using Z3INS, and runs it. Having been installed,ì it will automatically know the three facts it needs: where the DOS, ENV, andì wheel byte are located. After it finishes running, there will be a binaryì image file called ZRDOS17.BIN. With a manually installed Z-System we would now have to go through aì somewhat complex process involving 'sysgening' a system image from theì system tracks, patching in the new DOS using a debugger, and 'sysgening' theì image back onto the system tracks. With Z-COM things are actuallyì considerably easier, since the two 'sysgening' steps can be skipped. Hereì is the command sequence: è A0:SYS>ddtz zc.com ; Run debugger and load ZC.COM -izrdos17.bin ; Initialize the file control block -r900 ; Read with offset 900h so that the object ; ..file will load at A00h -g0 ; Warm boot out of debugger A0:SYS>save 2dh zcnew.com ; Save new version As before, exit from Z-System with the ZCX command (or just hit the resetì button if that is more convenient). Then load the new system and run theì DOSVER utility. Voila! There is version 1.7. Now let me show you a trick that makes patching even easier and doesn'tì require a debugger at all. Just use the following command sequence: A0:SYS>get 100 zc.com ; Load ZC.COM at address 100H A0:SYS>get a00 zrdos17.bin ; Load ZRDOS17.BIN at address A00H A0:SYS>save 2dh zcnew.com ; Save the new memory image With this technique there is no computing of offsets, and it uses only ZCPR3ì built-in commands (GET and SAVE). The one thing you have to remember isì that the GET command loads entire files, and so this technique can only beì used to patch in things that come in contiguous blocks with a length that isì an integral multiple of 128 bytes. If you look at the memory table ofì ZC.COM, however, you will see that this includes all system modules thatì ever exist in the form of files: the CPR, DOS, NDR, ENV, TCAP, RCP, FCP, andì IOP. These patches can be done very nicely from alias scripts. Forì example, since one might often change one's named directories, the followingì alias might be handy: alias PUTNDR: IF NULL $1 ECHO SYNTAX: $0 NDR-FILE-NAME ELSE ERA ZCNEW.COM GET 100 ZC.COM GET 1A00 $1.NDR SAVE 1DH ZCNEW.COM ECHO TEST ZCNEW.COM FI Similar aliases could be used for replacing other modules such as RCPs andì FCPs. New Command and System Modules Speaking of RCPs and FCPs, let's talk a little about how we generateì new versions of these and other system modules. There is no need to discussì the patching techniques. They are the same as what we have already seen. ì The question is: how do we generate the new SYS.RCP, SYS.FCP, and SYS.ENVì modules? è The procedure is the same as in a manual install system, except that inì a manual install system we already had the necessary Z3BASE.LIB file that isì required for the assembly of new system modules. So far we have not neededì one with Z-COM. To make things easier, Joe Wright has kindly provided usì with a generalized Z3BASE.LIB file. All we have to do to adapt it to ourì system is to use an editor to fill in the address of the environmentì descriptor in the "Z3ENV SET ..." definition near the top of the file. Oneì further hint: while you are at it, change the SET to an EQU. If you useì Z3BASE.LIB to assemble a file in Zilog mnemonics, the assembler will notì accept SET, since that is a Zilog opcode. You would have to change it toì ASET in that case, but there is no reason not to use the universal EQU. ì Some programs also require definitions for YES and NO, so you might want toì add the lines: YES EQU TRUE NO EQU FALSE One last addition. The RCP, FCP, and ENV modules do not need it, but otherì files, and most notably the command processor code, require an equate toì define the address of the entry point to the command processor. This is aì part of the normal Z3BASE file, but Joe Wright forgot to put it in. ì Someplace after the Z3ENV equate, add the line: CCP EQU Z3ENV - 1A00H Now you should be all set to assemble up new system modules, like the newì FCP10 from ZSIG. You might also want to assemble a customized SYS.ENV withì the correct values of maxdrive and maxuser and your own choice of printerì and console definitions (see "ZCPR3, The Manual" for details). "ZCPR3, The Manual" explains in detail how to carry out the assemblies,ì though I find that the discussion there makes the process look moreì complicated than it really is. Basically, you assemble the module to a HEXì file, convert the HEX file to a COM file using MLOAD, and then rename theì COM file to the proper name for the module (e.g., "REN SYS.FCP=FCP10.COM). ì If you have the SLR assemblers, you can assemble the module directly to aì COM in a single pass and skip the MLOAD step. Finally you test the moduleì by loading it using LDR. Replacing the Command Processor Replacing the command processor is no more difficult than changing anyì of the other modules in the system. In fact, as we will soon see, it isì much easier to test a new CPR with Z-COM than it is with the manuallyì installed Z-System. The basic procedure is as we described for the RCP or FCP. As usual,ì edit the configuration LIB file (Z3HDR.LIB or Z31HDR.LIB if you are using myì experimental version ZCPR315D) and assemble the code. One additional hint. ì Again, if you have the fabulous SLR Systems assemblers SLRMAC, Z80ASM, orì SLR180, select the option to assemble directly to a COM file, not to a HEXì file. It is a shame that so many books and articles have taught theì unnecessarily complex patching method based on HEX files with theirìèextremely tricky offset calculation. It is much easier to work with a COMì file where the load offset in the debugger is quite straightforward, namely,ì 100H below where you want the file to go, no matter what address it wasì assembled for. If you are using an assembler that can produce only a HEXì file, then use the public-domain MLOAD to convert it to a COM file just asì was done to make the RCP and FCP files. Now that you have ZCPR3.COM or some such file, all you have to do isì substitute it for the file ZC.CP in A15:. It would be a sign of foolhardyì optimism to destroy the original ZC.CP. I would recommend renaming it toì something like ZCOLD.CP and then copying the new one into place with aì command like "PPIP A15:ZC.CP=ZCPR3.COM". Now just hit control-c to warmì boot, and the new CPR will be running! If things did not work out as you intended (and especially if the newì CPR just crashed the system), you can reboot and reload ZC.COM. Remember,ì you did not change the CPR image in ZC.COM yet, and things will be fine soì long as you don't warm boot. Before that happens, you should renameì ZCOLD.CP back to ZC.CP. Then you can try again. That is sure a lot easierì than all the 'sysgening' required to test a new CPR with the manuallyì installed Z-System. If all went well, the system is now running just the way you hoped itì would. Once you've tested it and are satisfied that it really is workingì correctly, you can patch the new CPR into ZC.COM so that it will be readyì immediately after Z-COM loads. The following commands will do it: A0:SYS>get 100 zc.com A0:SYS>get 200 a15:zc.cp A0:SYS>save 2dh zcnew.com As usual, once you have verified that ZCNEW is working, rename it to ZC.COM. Summary and Plans ----------------- That wraps things up for this time. You now know how to make enoughì patches to mold a Z-COM system pretty well to your own tastes. If you haveì Z-COM, I hope you will experiment some before the next column appears. Inì that column we will really dig into Z-COM and do some wild things. If youì have any suggestions or questions, please send them along. My address andì phone numbers are listed below. As a little reward for those of you who plowed through this whole pieceì (or who were taught the trick I was as a freshman in college to read the endì of a paper or essay before you start at the beginning), here is a littleì tidbit. ZCPR version 3.3 is coming very soon. I already have a nearlyì complete version of it patched into the Z-COM I worked up for this article. ì I expect that Z33 will have been released or will be very close to releaseì by the time this column appears, and I will devote some space to aì discussion of its new features in the next column. Jay Sage è 1435 Centre Street Newton Centre, MA 02159 voice: 617-965-3552 modem: 617-965-7259