mwilson@NOSC.ARPA (09/26/86)
I want to add automatic disk logging to my BDOS ( P2DOS ), but I'm not
sure about how to go about it. So far, I've produced some very wrird behavior
patterns from the BDOS, but no success.
I think what needs to be done is for BDOS to check each drive's status
upon it's selection, and reset it if it is R/O.
Any comments or help would be greatly appreciated.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marc Wilson
ARPA: ...!crash!pnet01!mwilson@nosc ( preferred )
...!crash!pnet01!pro-sol!mwilson@nosc
UUCP: [ ihnp4 | cbosgd | sdcsvax | noscvax ]!crash!pnet01!mwilson@nosc
"The difference between science and the fuzzy subjects is that science
requires reasoning, while those other subjects merely require
scholarship."
-Lazarus Long
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SAGE@LL.ARPA (09/26/86)
I have not really thought through the question of how one would make
the disk operating system (DOS) perform automatic disk logging, but I do
not think that it is sufficient or necessary to simply check for which
disks are set to read-only status. First of all, the user may have set
a disk to R/O status (using STAT or another utility), and that diskette
may not have been changed. In fact, relogging that diskette would
defeat the purpose behind the user's setting it to R/O status, i.e., to
prevent any writing to that diskette. Secondly, after a diskette is
swapped without resetting with a control-c, the diskette is not yet
marked as read-only.
I think that what has to be done is the following. Whenever DOS is
asked to write to a disk, it must check the allocation table implied by
the directory on the diskette with the allocation table stored in the
BIOS. If the diskette has not been swapped, the two tables will agree;
if they have been swapped chances are very high that they will not
agree. The standard Digital Research BDOS does this, and if it finds
that the tables do not agree, it then sets the disk status to read-only,
which precipitates the "BDOS ERROR: DISK R/O" error message. If you
want the DOS to log in the swapped disk, you must take a more complex
action at this point.
I am sure that the required actions to handle this situation are
more complex than meets the eye. If you want to try hacking, have fun!
I would start by adding code to log in the new disk in such a way that
the write operation can then proceed. Good luck. If you simply want
this very nice capability in your system, I strongly recommend that you
look into purchasing ZRDOS from Echelon, Inc. (415-948-3820). Although
ZRDOS is the DOS used with the Echelon Z operating system, ZRDOS can be
used as the DOS in a standard CP/M2.2 system as well (it does require a
Z80 or compatible microprocessor). ZRDOS offers quite a few nice
features in addition to automatic disk logging, and I am sure that
Echelon will be happy to send you more detailed information. As good as
ZRDOS is, by the way, it still cannot handle all disk-swap situations.
I believe that it has trouble, at least on some systems that support
automatic recognition of multiple disk formats, when the swapped
diskette has a different format, such as when you remove a Kaypro SSDD
diskette and put in an Ampro DSDD diskette. I say all this as an
indication that automatic disk logging is not as easy as one might think
at first. ZRDOS has gone through a lot of development to get to the
point it is at now.
Jay Sage
prindle@nadc.ARPA (09/26/86)
CP/M 3.0 (A.K.A. CP/M-Plus) does automatic disk logging as a matter of course. It does this two ways - first by comparing the allocation tables of the disk and BIOS, as suggested by Mr. Sage, and secondly, if operating with a drive that can detect disk removal/insertion (by interruptions of the write-lock photocell), by using that information. And as Mr. Sage suggests, there are some problems when swapping formats (this, on a C-128/1571 CP/M system), but it largely works just fine. C-128 CP/M 3.0 supports a virtual drive (E:), and as expected, disk swaps to honor requests for the virtual drive do not trigger the automatic logging. Frank Prindle Prindle@NADC.arpa
bridger@RAND-UNIX.ARPA (09/27/86)
A slight correction to the discussion: the Digital Research CP/M 2.2 BDOS computes a checksum of each directory sector when it logs in a new disk (unless cks=0 in the disk parameter block). When a disk directory sector is read, it is these stored checksums, not the bitmap of allocated disk groups, that are compared with the values computed from the (possibly changed) disk. Writing to a file causes the allocation map (in memory) and the user-supplied file control block to be updated, and causes the data to be written to the disk sectors (when the bios flushes the host buffer); it does not alter the disk directory. The directory information -- which groups are allocated to which files -- is only updated on the disk when a file (or one extent of a file) is closed. Auto-logging DOS's usually can't totally prevent trashing a disk. Suppose that a program creates a file and writes to it, leaving it open, and the user then swaps in a different disk. The dos won't detect the change until the program causes a directory access. So, if the program continues to write to the file, the data will go onto the new disk, overwriting whatever is in those groups; the R/O error will occur at the close (or other directory operation). Perhaps the original question -- "auto-logging of disks" -- was really a query about a BIOS operation (as Jay has suggested). A well-designed bios will do a media-determination check whenever SELDSK is called with bit 0 of register E RESET (e.g. E = 0 or 2) and will set the dph and associated dpb accordingly for sides/density/format ... CP/M 2.2 calls SELDSK with E bit 0 reset after a ^C and when next selecting a disk that has been logged off. Of course, only some of the 100+ 5 1/4" formats can be distinguished by their format pattern. Bioses that support "foreign" formats may do so automatically (within the supported subset); others may simply provide a different logical drive and require the user to install the dpb/dph information before using it. For example, it is possible to set the Advent/Plu*Perfect Systems Turborom on a Kaypro so that the bios automatically distinguishes Kaypro DSDD 512 format from Ampro DSDD 512. *BIOS-level* auto-disk format determination should be compatible with any cp/m 2.2-type dos, requiring only ^C, reset, or logoff/logon at the dos level. --bridger mitchell