To use this replacement VBIOS, you have to run MKZCM and create an NZCOMì
system with 4 records allocated for the BIOS instead of the standard 2. ì
Because the BIOS must start on a page rather than just a record boundary,ì
MKZCM will sometimes make automatic adjustments to the BIOS size. ì
Therefore, you should specify changes in MKZCM starting with the higher¡
numbered modules; the adjustment in the BIOS allocation should be made last. ì
If an attempt to enter a value of 4 results in MKZCM using 5, then you couldì
go back (if you don't like wasting memory) and make one of the other modulesì
(such as the NDR) one record larger and then respecify a 4-record BIOS.
There are many other ways that NZCOM can be used to introduce systemì
enhancements without having to make changes in the real BIOS. As anì
example, we will show how to add support for the drive vector in environmentì
descriptors of type 80H and above (implemented with NZCOM and Z3PLUS). Theì
drive vector is a 16-bit value stored as a word beginning at offset 34H inì
the environment descriptor. It specifies which disk drives are actuallyì
implemented on a system. The lowest order bit in the word is for drive Aì
and the highest for drive P. A zero in a bit position indicates that theì
corresponding drive is not available. For example, on my SB180 the bytes atì
addresses ENV+34H and ENV+35H were 7FH and 00H, respectively. Thus the wordìèvalue is 007FH or 0000,0000,0111,1111 binary, indicating that I had drivesì
A, B, C, D, E, F, and G. When the hard disk E partition developed a problemì
that made it unusable, I changed the 7FH value to 6FH, thereby disablingì
drive E. You can display the drive vector using menu selection 3 in theì
SHOW program (ZSHOW for Z3PLUS).
The ZCPR34 command processor knows about the drive vector and will notì
allow command references to unsupported drives. But what about programsì
that you run? Unfortunately, the BIOS generally knows only which drives areì
potentially implemented, and it may try to access a nonexistent drive. Whenì
'smart' BIOSes encounter this problem, they often prompt the user as to whatì
to do next. This is fine if you are sitting at the console and can takeì
appropriate action to recover, but if the system is being run remotely,ì
there is generally no way for the remote user to recover. In fact, becauseì
the 'smart' BIOS uses direct hardware calls to display the "Abort, Retry,ì
Ignore?" message rather than calls through the BIOS vector table, the remoteì
user does not even see the message and just thinks the system has crashed. ì
My Z-Node got hung once that way when I forgot to put a diskette back into aì
floppy drive. A caller attempted to access it, and when I got home, theì
BIOS was dutifully beeping at me and waiting for me to tell it what to do.
My first stab at writing a VBIOS that observes the drive vectorì
restrictions is shown in Table 2. Now that I have read Lee Hart's column, Iì
am sure that this code can be made shorter, faster, or both! But I willì
leave that as an exercise for the reader. (I already see one place where Iì
could save a byte.)
The listing assumes you are starting with the ZSNZBIO described earlier. ì
Just add the extra equate for DRVEC under the /_ENV_/ common block andì
replace the simple ISELDK (intermediate select disk) code with the slightlyì
more complex version shown in the Table. I put this on my Televideo, andì
the results were most pleasant. Now when I attempt to access a nonexistentì
drive, the system does not force a direct-CBIOS warmboot that drops me outì