A number of newer TCJ readers have commented that with this column theyì
feel that they are coming into the middle of a very involved discussion thatì
is hard to catch on to. Of course, one answer to that problem is for newì
TCJ readers to purchase back issues. I have been writing this columnì
regularly since issue #25, and I am quite sure that all those back issuesì
are still available. That solution notwithstanding, it is probably not aì
bad idea to stand back every so often and try to comprehend a largerì
picture. That is one of the tasks I will undertake this time.
Detailed technical content will not be forsaken entirely, however,ì
since I regard that as the primary purpose of my column. At this point, Iì
suspect that I am too much of a Z-System expert to talk about very manyì
topics at a level that is appropriate for beginners. To serve their needs,ì
I have been very actively soliciting articles from other authors. In thisì
issue, for example, we have the first of the columns I promised a couple ofì
issues back on how to set up a remote access system (aka bulletin boardì
system) under the NZCOM auto-install version of Z-System. Lee McEwen (akaì
Chris McEwen) has done a lovely job with that assignment.
The technical discussion this time will focus on some issues that aroseì
in trying to install ZSDOS or ZDDOS on an SB180 computer with the XBIOSì
enhanced operating system. Before you say "But I don't have an SB180," letì
me assure you that the techniques have more general applicability. Theì
specific XBIOS problem is one that has come up often and has been the sourceì
of considerable frustration to XBIOS users. [They are in good company, byì
the way. Just as I was finishing this article, I got a call from Bridgerì
Mitchell about this very subject!] I am only sorry that it took me so longì
to get around to working on it. Gene Pizzetta, a fellow Bostonian, was theì
squeaky wheel that finally got my attention, and he has contributed a numberì
of his own ideas to the solution.
Announcements
Before we get down to business, I have, as usual, a few announcementsì
to make. First I would like to remind readers once again about Billì
Tishey's superb collection of help files for the hundreds of Z-Systemì
programs now available. Bill can now generate diskettes in many formatsì
besides Apple (using his son's Commodore 128), and he is willing to fillì
your diskettes with the files for only $10. My column in issue #36 gave theì
following procedure to follow: (1) send enough formatted diskettes (plainlyì
labeled with the format) to hold at least 1000K bytes (up from 800K backì
then); (2) use a reusable disk mailer or enclose a mailer suitable forì
returning the diskettes to you; and (3) enclose a return address label,ì
return postage, and the $10 copying fee. Bill's address is 8335 Dubbsì
Drive, Severn, MD 21144. If you prefer (or if you need 96-tpi, 8" SSSD, orì
NorthStar hard-sector formats), you can send the diskettes to me as well.
Second, I would like to make a special point of calling your attentionì
to the GEnie RoundTable discussions that take place every Wednesday at 10pmì
Eastern time. The first such session of each month is devoted to Z-System,ì
and I am the moderator, so this is your chance for a real-time dialogue withì
me. Go to page "685;2" on GEnie and enter "Room 2".
There are several changes to report in the roster of Z-Nodes. ì
Regrettably, Bob Paddock's node #38 in Franklin, PA, has gone off the air. ì
To offset that loss, however, node #73 in the St. Louis, MO, area has comeì
back to life after being down for several years. Sysop George Allen and co-sysop Walt Stumper would be happy to hear from you at 314-821-1078 (PC-Pursuit MOSLO/24). The equipment is currently a Xerox 820-II with a 10 Megì
drive, but the sysops hope to expand soon to a 30+ Meg Ampro.
On the Z-Node front, I am also sorry to report that Z-Node Centralì
(Lillipute) was downed by hardware failures on both computers! They haveì
been off the air for a couple of months already as I write this, and sysopì
Richard Jacobson has just faced the truth: that it will not be coming back. ì
Ladera Z-Node (#2) in Los Angeles will take over as Z-Node Central. Chicagoì
area callers looking for Z support should check out the Antelope Freewayì
system run by ZDOS-coauthor Carson Wilson for CFOG (Chicago area FOG). Thisì
is one of a small number of remote access systems running under the Z3PLUSì
flavor of Z-System. The phone number is 312-764-5152 (PC-Pursuit ILCHI/24). ì
We expect that its 'System One' will soon be a Z-Node ('System Two' supportsì
MS-DOS).
Finally, there have been some very significant developments with BDS C. ì
Leor Zolman completed some major additions to the Z version (BDS Z), and theì
final release has just gone out as I write this column in mid October. ì
Programs generated by BDS Z now have a full Z-System header and can beì
linked as type-3 programs to load and run at an arbitrary address. ZDOSì
coauthor Cam Cotrill has already released a substantial amount of BDS Z codeì
for performing the functions in the SYSLIB, VLIB, and Z3LIB assembly-language libraries that are not already built into BDS Z.
Leor has now turned over all of the marketing and some of theì
development responsibility for BDS C to me. Recognizing that the $90 priceì
tag of the full package, however reasonable for what one gets, is anì
impediment to new users who want to experiment with C, we have prepared aì
low cost introductory package that (1) includes only one version of the codeì
(either standard CP/M or Z-System), (2) contains only the essential files,ì
and (3) comes with an abridged version of the manual (and without the fancyì
BD Software binder). This package will be offered for only $60. Otherì
parts of the full package can be added later: $25 for the second version ofì
the compiler, $25 for the support materials (RED editor, CDB debugger, andì
the parts of the manual covering them), or $40 for both at once. If theì
whole package is ordered at once, it comes complete with an attractiveì
binder (also available with the introductory package for $5 extra).
It should be noted that BDS Z generates programs that run perfectlyì
well under standard CP/M. Naturally, they will not recognize Z-Systemì
features like named directories, but they will accept the now standard DU:ì
extended drive/user syntax instead of the older U/D: format of standard BDSì
C. The only disadvantage of using BDS Z rather than BDS C on a standardì
CP/M system is that the programs carry Z-System overhead (about 800 bytes)ì
that don't provide them with any functionality.
What is a Microcomputer Operating System For?
The basic function of an operating system is to make one's life --ì
one's computing life, that is -- simpler. When microcomputers first cameì
out, the biggest burden was dealing with the hardware. It was no fun forì
the computer user and programmer (largely synonymous in those days) to haveì
to deal over and over with the intricacies of the physical operation of theì
hardware, such as getting characters to and from the terminal or paper tapeì
reader/punch, not to mention the dauntingly more complex task of managingì
data on a magnetic tape or floppy diskette drive.
Gary Kildall's CP/M operating system provided a solution -- and a veryì
good one (by and large) in my opinion -- to those problems. It did so byì
implementing a standardized and modular interface that handled the basicì
device communication tasks. CP/M, which stood (I believe) for "Controlì
Program for Microcomputers," was the master program that one got running onì
the computer right after power up. It would then allow one to load and runì
other programs, with control always returning to the CP/M master programì
after each user program finished.
Besides accepting and interpreting commands issued by the computerì
operator, an operating system like CP/M also provides resident code (alwaysì
ready in memory) for performing certain functions that application programsì
will often want to use. The simpler functions are things like sending aì
character to the terminal screen; the more complex ones include fetchingì
from or writing to a floppy diskette the information associated with aì
logical entity known as a file.
With these functions implemented in the operating system code,ì
application programs are easier to write and do not have to include the sameì
code over and over. More importantly, they can run on a variety of hardwareì
platforms, since the details of the physical hardware are handled by theì
operating system code, and the program can deal with things at a logicalì
level.
Logical vs. Physical
Perhaps this is a good time for a brief aside on this matter of logicalì
versus physical. We use the adjective "physical" when we are talking aboutì
things that are actually in the hardware. In the case of a floppy disk, forì
example, the physical items are the bits of data stored as magnetizationì
patterns. These bits are grouped into sectors, and the sectors into tracks. ì
In the case of a terminal screen, the physical items are the patterns ofì
illuminated dots that we recognize as letters, numbers, and other symbols.
On the other hand, we use the adjective "logical" to describe thoseì
things which are essentially the creation of our minds (and programs). Forì
example, there is no such physical thing as a "file." No matter how youì
examine a diskette, you will never find a file on it (as such); you willì
find only sectors and tracks. It is our choice to organize the data on theì
disk in a way that associates groups of such sectors with a file names andì
to store the file names in a particular group of sectors on the disk.
Modularity
CP/M is modular in the sense that it divides up the functions of theì
operating system into separate packages. One part is called the BIOS (basicì
input/output system). This part, which lives at the very top of the memoryì
address space, deals directly with the hardware. It reads and writesì
physical sectors from and to a diskette; it determines whether or not a keyì
has been pressed on the keyboard and, if so, which key; and it sendsì
characters to the screen. The BIOS is the only part of CP/M that isì
different for each hardware implementation of a CP/M computer.
The second CP/M module is called the BDOS (basic disk operatingì
system). It deals with logical constructs. We have already spoken ofì
files. When a file is referred to, the BDOS figures out which physicalì
tracks and sectors contain the data for that file. Another logicalì
construct is lines of text. The BDOS has a function to send a complete lineì
of text to the screen (as opposed to the BIOS, which can send only a singleì
character), and it has another function to get a complete line of text fromì
the user, allowing a limited amount of editing. These functions make itì
much easier for the application programmer to write his or her program.
The last CP/M module is called the CCP (console command processor). Itì
gets a command typed by the user at the console and takes the appropriateì
action to carry out that command. Some commands, such as DIR or ERA, areì
implemented directly in the CCP code. Others require that a COM file beì
loaded from diskette and executed.
Command Processing Under CP/M
For the most part, CP/M accomplishes the functions it was designed toì
perform in admirable fashion. However, it was so concerned with solving theì
hardware interface problem (the programmer interface) that it devotedì
relatively little attention to the user interface. To be fair, it was bornì
in the days when 16K of memory cost about $500 (in 1970s dollars, no less)ì
and occupied an entire S-100 card (bigger by far than a whole SB180FXì
computer with 512K). Today we might not think that 64K is very much (someì
say that OS/2 feels dreadfully cramped in less than 3 Megs!), but it makes aì
lot of things possible that 48K (or even less) would not allow.
CP/M's command processor did little more than the minimum it wasì
required to do, namely to run a few resident commands and to load externalì
commands from disk. It did not provide many services to make the operator'sì
life easier. You had to specify rather exactly the command you wantedì
performed; no leeway was allowed. And if you made a mistake, CP/M did notì
try to help; it just shrugged its shoulders and emitted a question mark.
The Niceties of Z-System
The Z-System has evolved over a period of nearly a decade now, but itsì
goal from the very beginning has always been to make it easier and moreì
convenient to operate the computer. My ideal is to have the computer doì
everything that it possibly can do for the user and leave to the user onlyì
those tasks that no computer could possibly figure out on its own. Theì
command processor improvements I have introduced and the utilities I haveì
written have all been directed toward that goal. I will now run through aì
short summary of Z-System features and try to indicate how they make theì
operator's life easier. This list is adapted from my book, "The ZCPR33ì
User's Guide."
User Area Access
CP/M introduced the concept of disk "user" areas, which allowed theì
operating system to group files into separate logical directoriesì
(physically the files are all stored in the same directory, but they areì
tagged to indicate the user area). Unfortunately, CP/M provided noì
practical way to access files across user areas, which made them almostì
useless.
Back in the days when disks held only about 100K, there wasn't muchì
need for this kind of organization, but today floppy diskettes commonly haveì
a capacity between 350K and 1.3 Meg. Hard disks with many tens of megabytesì
are also inexpensive and common. Under these circumstances, a singleì
logical drive can hold hundreds or even thousands of files, and some way toì
organize them becomes essential.
Z-System makes it very easy and convenient to organize your files basedì
on user numbers. Where CP/M allowed only a drive prefix to a file nameì
(D:NAME.TYP), Z-System allows drive and/or user number prefixesì
(DU:NAME.TYP) so that files in other user areas as well as other drives canì
be referenced directly. In addition, Z-System allows meaningful namesì
(similar to DOS subdirectory names) to be assigned to drive/user areas. ì
This provides an interface that is far more suitable to the way people thinkì
and remember. With the DU: form, the operator has to think about theì
hardware (something he or she should not have to do, remember?); with namedì
directories, the operator thinks in terms of function (TEXT: for text files,ì
BDSC: for the C compiler, DBASE: for database files, and so on).
Terminal Independence and the Environment
While some would argue that the DOS hardware and software standardsì
established by IBM's market dominance have resulted in an enforcedì
mediocrity, there is no doubt that having a single environment in which toì
operate makes life much easier for applications programmers. Programs forì
DOS generally work right out of the box on any IBM compatible computer. ì
Configuration is required only for fine-tuning.
CP/M, on the other hand, was designed to allow programs to run on anì
extremely wide variety of hardware. In those days, "personal" computer tookì
on a different meaning -- each person designed and built his own hardware. ì
CP/M could be made to work with all of them, but elaborate configurationì
procedures were generally required, especially to match programs to theì
particular terminal used. To this day, we still have to deal with thisì
hardware diversity.
What CP/M could have but failed to provide was a means for conveying toì
application programs information about the operating environment. Z-Systemì
has several modules that afford such communication. An area called theì
environment descriptor (ENV) contains information about the systemì
configuration. Another system area called the message buffer (MSG) storesì
information that one program can leave for another program that runs laterì
to read.
Part of the ENV is a section called the TCAP or Terminal-CAPabilityì
descriptor. The TCAP allows a program running under Z-System to determineì
the type of terminal in use and to adapt to the control codes it uses forì
special video operations. The ENV has information about the size of theì
screen and the printer's page. It also contains such information as the CPUì
clock speed and which disk drives are available (why allow attempts to logì
into drive C: if there is no drive C: -- it often just hangs the computer). ì
The Z-System supports many optional operating system features contained inì
optional modules, and the ENV contains information about these modules also.
The ENV and TCAP not only relieve the user of the nuisance ofì
installing programs; they also make it very easy to change the installation. ì
Suppose, for example, you want to print some files in 132-column modeì
instead of the usual 80-column mode. Under CP/M you might very likely haveì
to get out a configuration program to redefine the printer setup. With a Z¡
System print utility, you would simply change the mode on your printer, runì
CPSET (console/printer set) to select the 132-column printer definition, andì
run the same print program as before.
Command Processing Enhancements
Under CP/M, you have to specify where the COM file to be run is locatedì
(otherwise the current drive is assumed). This is a perfect example ofì
something that a computer can easily be smart enough to do for you, and Z¡
System does. As with modern versions of DOS (which took many years to catchì
on to this Z-System feature), you specify a list of directory areas that theì
operating system will scan for a requested COM file. If you wish (as youì
might when you know that your COM file is not on the search path), you canì
specify a directory using either the DU: prefix or the named directory DIR:ì
prefix, and you are thus not limited to the current user area or the path.
With Z-System one is also no longer limited to issuing commands one atì
a time (DOS has been even slower to catch on to this). A single line ofì
command input can contain a whole sequence of commands. As a result, you doì
not have to interrupt your thinking to wait for one command to finish beforeì
you can specify the second and subsequent steps in a process. You can workì
out a strategy for what you want to accomplish and issue all the commands atì
once, before you forget or get confused.
Many oft-repeated computational tasks involve sequences of commandsì
(e.g., editing, assembling, linking, running; or editing, spell checking,ì
printing). In such cases, the Z-System alias facility (similar in some waysì
to SUBMIT but far more flexible) can be used to define a new command name,ì
which, when invoked, performs the entire sequence. This saves the user aì
lot of typing but more importantly eliminates the need to remember exactlyì
what the sequence is. Basically, you solve the problem once and put theì
solution into an alias script. From then on, the computer is smart enoughì
to take care of the complex details for you. I have given many examples ofì
this in past columns.
Conditional Command Execution
There is only so much one can accomplish on a computer (or in life)ì
without making decisions. Have you ever seen a programming language with noì
ability to perform tests and act in different ways depending on the results? ì
Flow control (IF/ELSE/ENDIF) is unique to the Z-System command processor. ì
Other operating systems that offer flow control at all limit it to operationì
inside a batch or script language.
A special set of Z-System commands can test a wide range of conditions,ì
and the command processor will use the results of the tests to decide whichì
subsequent commands will be performed and which will be skipped. Thisì
allows the Z-System to respond in a remarkably flexible and intelligent way. ì
The solution to a complex computing task, one that requires on-the-spotì
decision-making, can be worked out once and embedded in an alias command. ì
Then you won't have to tax your brain the next time you need to perform thisì
task, and novice users will be able to do things on your computer that wouldì
have been beyond their own ability to figure out.
Command Processor Shells
If you do not want to deal with the operating system at the commandì
level or if you want to have a command processor with different features,ì
the Z-System shell facility allows you to install substitute user interfacesì
of your own choice at will. They can even be nested within each other.
Shells come in two common varieties: menu shells and history shells. ì
The menu interfaces allow the user to pick tasks with single keystrokes andì
have the shell program generate the complex sequences of commands requiredì
to perform those tasks. The menu system shields the user from complexity,ì
saves typing, and greatly reduces the chance of error.
History shells are enhanced command processors that remember yourì
commands and allow you to recall and edit previous command lines. I wishì
the Apollo Domain minicomputer system I use at work (not to mention my DOSì
computer) had a history shell one quarter as nice as Z-System's LSH or EASE. ì
They work like powerful wordprocessors on your command history, allowingì
searching and extensive editing.
What If You Make a Mistake
This is one of the other areas in which most operating systems behaveì
in an abominably primitive manner. When you issue a command that cannot beì
performed, they just issue an error message and then dump you back to squareì
one. Often you are not even told what sort of error occurred (considerì
DOS's wonderfully helpful "bad command" message).
The Z-System behaves in a civilized manner under these circumstances. ì
When an error occurs, the command processor turns the bad command line overì
to a user-specified error handler. The most sophisticated error handlersì
allow the operator to edit the command and thus recover easily from typingì
mistakes. In a multiple command sequence, if subsequent commands wereì
allowed to run after an earlier command failed, there could be disastrousì
repercussions, and an error handler is indispensible.
The system environment even contains an error type, which the errorì
handler can use to give you more specific information about what went wrong. ì
It may be the familiar error of a COM file that could not be found, butì
there are many other possible causes for the difficulty. A file that youì
specified as an argument might not have been found (e.g., "TYPE FILENAM"ì
when you meant "TYPE FILENAME"), or you may have specified an ambiguous fileì
name to a program that cannot accept one (e.g., "TYPE *.DOC").
System Security
Like minicomputer and mainframe operating systems, the Z-System is aì
secure operating system. This means that it has mechanisms for limitingì
what any particular user can do or get access to. Dangerous commands (suchì
as erasing, copying, or renaming files) can be disabled when ordinary usersì
are operating the system but enabled when a privileged user is at work. ì
Areas of your disk can be restricted from access for storage of confidentialì
or other sensitive information. These security features come in very handyì
in the implementation of a remote access system or bulletin board (see Leeì
McEwen's article in this issue). There is no need for additional securityì
to be provided by the remote interface program (BYE). The Z-System alreadyì
includes a full suite of programs for regulating and controlling systemì
security.
Summary
To sum it up, the goal of the Z-System is to provide an operatingì
system that can be tailored extensively to user preferences and that can beì
made to handle on its own and automatically as many computational details asì
it can, leaving the user free to concentrate solely on those aspects ofì
computer operation that require human intelligence.
Faking Out The System
For the technical part of this column, I would like to talk brieflyì
about some techniques for adding extensions to a Z-System that it was notì
designed to accept. The need for this trick arose in connection with theì
installation of ZSDOS and ZDDOS (and their clock drivers) on an SB180ì
computer with the XBIOS enhanced BIOS, but it can be useful in otherì
situations as well.
XBIOS is a very nice and flexible system. One of its main features isì
that it keeps much of the BIOS in an alternate memory bank, leaving a muchì
larger TPA (transient program area) for application programs than did theì
standard BIOS from MicroMint. The configuration and loading process,ì
however, is somewhat unconventional (a forerunner in some ways to the NZCOMì
and Z3PLUS techniques).
The XBIOS system is loaded not from system tracks on the disk but fromì
a file. This file is generated by a special utility program called SYSBLDì
(SYStem BuiLD) that allows one to define in a rather flexible way theì
configuration of one's personal Z-System, including the names of the CCP andì
DOS files to be used. Those component files, however, must be available inì
REL format, and the new Z-System DOS components are supplied in ZRL formatì
only (because they have hooks to other parts of the system that can beì
resolved only by that format).
Changing Systems Using JetLDR
JetLDR is a lovely little utility written by Bridger Mitchell thatì
knows how to load almost any module in a Z operating system. It is muchì
faster and more careful than its predecessors, LDR and LLDR, and it is notì
limited to the non-code Z modules -- such as the NDR (named directoryì
register) -- or to code modules preassembled for a fixed system -- such asì
an RCP (resident command package) module FIXED.RCP. It can load codeì
modules assembled in ZRL format to whatever address that module occupies inì
the current system and with all the hooks to other Z-System modulesì
generated at load time. Thus MYRCP.ZRL, assembled once, can be used in anyì
system configuration that allocates enough room for an RCP of that size.
Most remarkably, JetLDR can load even main operating system modules:ì
CCP, DOS, or BIOS. Special adjunct configuration files (CFG) are used toì
help it in some of these specialized tasks (a little more about that later). ì
JetLDR's internal help screen is reproduced in Fig. 1 so you can see theì
whole list of modules it can handle. It is available from the usual Zì
suppliers for $20.
So, the obvious solution to the problem of getting ZSDOS or ZDDOSì
running under XBIOS is first to generate and boot a standard ZRDOS systemì
(ZRDOS.REL comes with the SB180) and then to replace ZRDOS with, say, ZDDOSì
using the JetLDR command:
JETLDR ZDDOS.ZRL
ZSDOS can be loaded just as easily. On my system I have ARUNZ aliases thatì
swap DOSs in a jiffy this way in case I want to perform some experiments.
There's The Rub
Now comes the problem. It's very nice that we now have ZDDOS or ZSDOSì
loaded and running, but if we want to take advantage of its wonderful timeì
and date features, we must find a way to load its clock and (for ZSDOS)ì
stamping module, too. The ZDOS utility SETUPZST makes it very easy toì
create the required loader, LDTIM.COM; the problem is: where can LDTIM putì
the driver code? [Aside: For those who own it, I am told that theì
DateStamper BSX module will work with ZSDOS, but I have not tried thisì
myself. It requires no memory to load.]
In an NZCOM system, the MKZCM system definition utility allows one toì
specify a "user buffer" area in memory, and this is just perfect for theì
clock/stamp module. ZDOS even has special facilities for taking advantageì
of this buffer. LDTIM can automatically determine the location of thatì
buffer and install the drivers there, and a special patch to NZCOM (includedì
with the ZDOS package) gives NZCOM the ability to reconnect the driversì
automatically after a new DOS is loaded.
XBIOS's SYSBLD utility, unfortunately, does not support such a userì
buffer (this is true even in the 1.2 version that is able to load ZRLì
files). There is a way to trick the system into making some room for extraì
memory modules. This is to assign the extra memory space needed to one ofì
the standard modules, such as the RCP. For example, if you use an RCP ofì
the usual 2K (16 record) size and need one page (two records) of memory forì
a ZDDOS clock driver, you simply specify an 18-record RCP space. Then, whenì
SETUPZST asks you for the address to which the clock driver should beì
loaded, you give it the starting address of the last page of this RCP space.
Once these steps have been followed, ZDDOS should be running with dateì
stamping. ZSDOS could be installed similarly except that even more extraì
space would have to be allocated to the RCP. Although what I have describedì
so far will get the system running, there is some danger that an oversizeì
RCP could be loaded by accident and overwrite the clock driver. To preventì
this, the ENV module should be patched to indicate that only the actual 16ì
records (10H) are available.
For those who do not face the problem of installing ZDOS on an XBIOS¡
equipped SB180, there are other uses of this kind of trick. For people whoì
do not have the necessary tools (e.g., MOVCPM) to move the BIOS down to makeì
room for special drivers (such as RAM disk drivers and special I/O boards),ì
this same trick can be applied to open up protected-memory space for them. ì
Other people may find it useful for quick experiments with special driversì
before going to the trouble of moving the operating system around.
There is one final refinement I would like to mention. It is somethingì
I learned from Gene Pizzetta, who took my general recommendations above andì
worked out the details (see his file, ZD-XB11.LBR, available on many Z¡
Nodes). I have usually used either the IOP or RCP modules for this trick,ì
but Gene recommended using the NDR instead. The reason for this is that theì
IOP, RCP, and FCP get allocated in 128-byte chunks, while the NDR getsì
allocated in much smaller 18-byte chunks, the space required for one name. ì
If your clock driver takes, for example, 270 bytes (10EH), you would have toì
allocate three extra records, because the driver is a tiny bit over twoì
records. If you steal space from an NDR, you can add just two records, butì
reduce the number of names in the NDR by 1.
Changing Command Processors
Generating a new CCP using JetLDR is a little trickier than changingì
the DOS. JetLDR could, as it does with a DOS or BIOS module, load the newì
CCP into its operating position in memory, but this would be of questionableì
value, since the CCP would survive only until the next warmboot. So,ì
instead, when processing a CCP ZRL module, JetLDR normally writes theì
resulting absolute-code CCP to a file ZCCP.CCP (in the root directory, Iì
believe).
This is where CFG files come into play. They are special code modulesì
that JetLDR uses to perform special processing (see the file JLTOOLS.LBR onì
Z-Nodes for more detailed information). For example, CCPCFG.ZRL is one thatì
tells JetLDR how to deposit the absolute CCP code that it generates directlyì
into the XBIOS ram image of the CCP in banked memory (from which it isì
loaded on each warm boot). A similar CFG file could be written to tellì
JetLDR how to install the new CCP onto the system tracks of the currentì
drive-A disk, but so far no one has done this. I would be happy to provideì
the CCPCFG module to XBIOS owners who would like it or to others who wouldì
like to use it as a model for writing other CFG files (send me a formattedì
disk with your copy of JetLDR, return mailer, etc.).
