towson%amsaa@sri-unix.UUCP (01/16/84)
From: David Towson (CSD) <towson@amsaa> Tony - I was very surprised to see that you consider it the responsibility of the BIOS to detect a disk-change. I should think that would be an OS chore. Comment ? Dave towson@amsaa
Tli%usc-eclb@sri-unix.UUCP (01/16/84)
From: Tony Li <Tli@usc-eclb>
Date: Mon, 16 Jan 84 12:35:06 EST
From: David Towson (CSD) <towson@amsaa>
To: Tli@usc-eclb
cc: Info-Cpm@brl-vgr
Re: Function 37
Return-path: <towson@amsaa>
Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 09:37:31-PST
Tony - I was very surprised to see that you consider it the
responsibility of
the BIOS to detect a disk-change. I should think that would be an OS
chore. Comment ?
Hi Dave,
As you must realize, detection of a disk-change is actually a hardware
function. The little microswitch on the disk drive door is usually
the mechanism. It is, of course, up to the BIOS to pass this along to
the OS.
Cheers,
Tony ;-)Tli%usc-eclb@sri-unix.UUCP (01/17/84)
From: Tony Li <Tli@usc-eclb>
Date: Mon, 16 Jan 84 16:47:20 EST
From: David Towson (CSD) <towson@amsaa>
To: Tli@usc-eclb
cc: David Towson (CSD) <towson@amsaa>, Info-Cpm@brl-vgr
Re: Function 37
Return-path: <towson@amsaa>
Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 13:57:58-PST
Tony - It is my understanding that CP/M-80 detects a disk change by
noting that the directory information that has been read from the "first"
disk no longer matches the information read from the "second"
disk, and that
when this happens we get the familiar (although usually unwelcome) message
"BDOS ERROR R/O", and the system must be reset. Is this not so ?
I think that that's exactly correct. Just one question: How often
does CP/M-80 read the directory? I don't know. As I said, I'm not an
expert on CP/M-80.
Second question: If a given drive does have the door switch, and I want
to have my BIOS pass the information from this switch to CP/M, what
should the BIOS put where ?
I don't know. I haven't done it.
Cheers,
Tony ;-)THESS%dec-marlboro@sri-unix.UUCP (01/17/84)
From: "Ted Hess" <THESS@dec-marlboro> Folks - CP/M-80 & CP/M-86 will read a directory whenever: 1) You open a file 2) Close a file 3) Do a directory operation like delete, rename etc... 4) The first disk i/o performed (on each drive) after "warm boot","disk reset", or ^C (which causes warm boot). 5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent). NOTE: No matter what block size or disk organization you use, this is one of CP/M's natural (and most inefficient) constants. Oh yes, CCP/M gets around this by using an LRU disk cache and expecting the BIOS to inform it that a drive door changed state. The unfortunate fact about this feature is that it is very difficult to flush these buffers from inside an application. It seems that CCP/M won't flush the buffers and mark them invalid if there are any files open on that drive. The problem, I suppose is to prevent a disk change while a file is open, however, I don't think anything is being gained by preventing an application from trying to guarantee all the data it has modified (including the directory itself), be up to date! Sorry, didn't mean to flame CCP/M - It's really quite nice. /ted --------
towson%amsaa@sri-unix.UUCP (01/17/84)
From: David Towson (CSD) <towson@amsaa> Ted - Thanks for the information - very helpful. One question: What is an LRU ? In the equipment maintenance business, it means "line replaceable unit" a term derived from "flight line". It refers to any "box" that can be quickly replaced in an aircraft standing on the flight line. I doubt if that's what you mean by "LRU disk cache". By the way, as another bit of trivia, some folks in the maintenance business take LRU to mean "least replaceable unit", which is a small part, and is therefore the exact opposite of "line replaceable unit" - very confusing. Dave
towson%amsaa@sri-unix.UUCP (01/17/84)
From: David Towson (CSD) <towson@amsaa> Jerry - Right you are. When I said "reset the system" I was thinking of "warm boot", not hardware reset; but I was too lazy to go back and edit the message after I read it over and decided I'd used the wrong term. In view of all I am now typing, I'd have been way ahead if I'd edited the message. Ah well, what the heck... The BIOS I'm using (Omikron Mapper-I BIOS for the TRS-80 Model-I) has a nice trap built in that allows "dignified" recovery from an open door. It displays the message "NOT READY TYPE C", and then waits for you to close the door and type "C" (for "continue", I suppose). However, when you switch disks and then try to write to the new disk without doing a warm boot first, it nails you with the familiar BDOS ERROR, and there is no dignified way out. I'd much prefer a nice friendly question like, "HEY DUMDUM, do you REALLY want to do this ?", to which I could respond "Y" to continue or "N" to abort. Someday, I'll hack that in. Dave
WANCHO%simtel20@sri-unix.UUCP (01/17/84)
From: "Frank J. Wancho" <WANCHO@simtel20>
At the extreme risk of prolonging this discussion, I'm surprised that
no one noticed Jerry's not-so-subtle clue in his last message:
fn 37 can wipe out the diredctory of a HARD (not removable) disk.
Most, if not all BIOSes are set up with hard disk logical drives
having CKS set to ZERO. This is a crude but somewhat effective way to
indicate to CP/M that the drive is fixed rather than removable, and
not to bother doing the checksum calculation/compare. This would be
fine in a single-user environment, but potentially devastating in a
multi-user one.
Function 37 "RESET DRIVE" is actually misnamed. It should have been
named "RESET WRITE PROTECT VECTOR", which write-enables the indicated
drives, as opposed to "resetting" them. A subtle but significant
difference. An unsynchronized Function 37, combined with the fact
that hard disk drive integrity via checksum is bypassed, will indeed
cause unpredicatable results.
The correct and safe sequence is:
Function 25: Return Current Disk (needed for Function 14 below)
Function 13: Reset Disk System (ends up selecting A)
Function 14: Select Disk (to reselect the original current drive)
--FrankTli%usc-eclb@sri-unix.UUCP (01/22/84)
From: Tony Li <Tli@usc-eclb> All right, if were really going to discuss this, let me give you a copy of my source. The following is the description of Function 37 from the CCP/M-86 manual. Admittedly, this isn't the same as the CP/M 2.2 filesystem, but I would be surprised if there were any significant differences. Anyhow: ---------------------------------------------------------------------- DRV_RESET Reset Specified Disk Drives Entry Parameters: Register CL : 025H (37) DX : Drive Vector Returned Values: AL : Return Code BL : Same as AL The DRV_RESET system call is used to programmatically restore specified removable media drives to the reset state (a reset drive is not logged in and is in Read-Write status). [Presumably there are no files open on a drive which is not logged in. - Tony] The passed parameter in register DX is a 16-bit vector of drives to be reset, where the least significant bit corresponds to drive A, and the high-order bit corresponds to the sixteenth drive, labelled P. Bit values of 1 indicate that the specified drive is to be reset. Refer to Section 2.17 [CCP/M-86 1.0 Programmers Guide] for more information regarding the use of this system call. This system call is conditional under Concurrent CP/M-86. If another process has a file open on any of the drives to be reset, the DRV_RESET system call is denied, and none of the drives are reset. Upon return, if the reset operation is successful, DRV_RESET sets register AL to 00H. Otherwise, it sets register AH to 0FFH. If the BDOS Error mode is not in Return Error mode (refer to the F_ERRMODE system call), the system displays an error message at the console identifying the process owning the first open file that caused the DRV_RESET request to be denied. ---------------------------------------------------------------------- Section 2.17 goes on to stipulate that "If all the open files on a removable drive belong to the calling process, the process is said to 'own' the drive. In this case, the file system performs a qualified reset on the drive and returns a successful result. This means that the next time a process accesses this drive, the BDOS performs the log-in operation only if it detects a media change on the drive." ---------------------------------------------------------------------- Conclusion: In the safest case, one should close all files before performing a DRV_RESET. However, if you do not, and your BIOS is somewhat flakey about detecting a media change (or your hardware is), you might not get the reset. This would probably result in destruction of the newly inserted media, as has been described by JEP. Cheers, Tony ;-)
POURNE%mit-mc@sri-unix.UUCP (01/23/84)
From: Jerry E. Pournelle <POURNE@mit-mc> It is not required that you RESET the system if the BIOS is properly written, but you will have to do a ^c warm boot if you have changed disks; R/O actually means that the bit map doesn't match t he current directory entries. As to BIOS detecting door opening, on 5 1/4" disks there is no hardware detect is there? Nor do I know a way to detect whether a door HAS BEEN OPENED although you can have (and my BIOS does) a look at the door to see if it is open NOW and put up a message like "Load Drive A" or "Please close Door" or some such; I recall startling some Morrow and Compupro troops a couple of years ago by inviting them over to the house and showing them I could access non-existent disks, open doors, or anything else, and recover from it. But that was before fn 37, which can have unrecoverable errors.
POURNE%mit-mc@sri-unix.UUCP (01/23/84)
From: Jerry E. Pournelle <POURNE@mit-mc> wearily I repeat: under circumstances not known to me, but which have happened to Systems Interface Consultants, Proteus Engineering, and other correspondents, fn 37 can wipe out the diredctory of a HARD (not removable) disk. This is an interesting feature. May you have many interesting features.
STORK%mit-mc@sri-unix.UUCP (03/11/84)
From: Eric Stork <STORK@mit-mc>
Charlie Strom:
,
Thanks for the 3/10/84 net-msg on BDOS Function 37. A couple of months
ago there was a lot of net traffic on this subject.
That triggered me to do some investigation. Here is what
learned, in part from thoughtful messages from FJW, W8SDZ,
and some others, and in part from my own hacking:
,
* FJW provided the key by pointing out that Function 37 (F-37)
does NOT reset the disk to which [DE] points,
but rather disables the write-protect that
normally prevents a write if the disk map on the
disk does not match the disk map in memory.
,
* That leads to the logical conclusion that when
one uses F-37, one must ALSO assure that the
disk map in memory matches the actual disk.
,
* Through experimentation (switching disks and
looking at the disk map in memory, which one
can do using DDT or SID, and BDOS F-27) I found
that every time a did a SEARCH FOR FIRST file
(BDOS F-17) the disk map was reset.
,
* My conclusion (and I'd welcome criticism!) is
that F-37 can be safely used to reset a specific
disk so long as it is followed by a F-17 operation.
Of course, any file on the disk being removed has to be
closed first, to save the data.
,
* The disasters described by some seem to happen when
one does a file write (or delete) after F-37 and
a disk switch BUT before a disk map reset with
F-17.
,
* Of course, that leaves the question of why use
F-37 at all? I don't if I don't have to -- I'm
old enough to have become a devout coward who avoids
needless risks. But there are times when F-13 will
not do the job. Sometimes F-13 does undesirable things
to the program you're in -- then there is not other way
if a disk switch is needed. Or is there?
,
* Hope this helps. I'd welcome further analytical
discussion. I agree that Pournelle's current BYTE
advice, though helpful in warning people, should have
gone further than just say "don't do it".
,
Eric.MMOON.ES@PARC-MAXC.ARPA (03/13/84)
When all else fails, give 'em hell, Jerry. I for one would rather have to investigate a completely bogus warning five times than have to rely on blind faith. If the net doesn't want to know but I suspect most on the net do in the future please copy me, thank you very much. MMoon.es
POURNE%mit-mc@sri-unix.UUCP (03/18/84)
From: Jerry E. Pournelle <POURNE@mit-mc> godalmighty dam. i gather that anything short of perfection is to be avoided; that if one cannot explain what's happening in a hurricane you shouldn't warn anyone that it is coming. your analysis is insteresting, but I do not know how to "change" a hard disk, and I can assure you that fn 37 has managed to write garbage all over the directory in two different hard disk systems. by your logic I should not warn anyone about that since I don't know why it does that. i followed the discussion with some interest; reseting the write vector seems to be the REAL name of the fn 37. I hadn't known that when I wrote my piece; indeed, i put the note about 37 on the net at the same time that I turned in the article. holy catfish