PDA

View Full Version : How does CP/M handle changed disks?



alank2
February 27th, 2018, 06:33 AM
I know some disks had a disk change line. Did that get reported to CP/M? Did CP/M do something else to detect a changed disk? How did it know if any of its buffers are no longer fresh?

glitch
February 27th, 2018, 06:35 AM
At least on many of the implementations I've used, you need to whack CTRL+C and do a warm boot if you change disks. Otherwise, you'll be greeted with a nice BDOS error when you go to write...usually, in my experience, right as you need to save out several hours' of debugging work :p

alank2
February 27th, 2018, 06:47 AM
It sounds like it isn't very tolerant of it, or at least it requires you to be mindful of it. Does CP/M have something it uses to know it isn't the same disk? How does it know to generate the BDOS error? Is there a disk SN or something? Does it read a block and verify it against what it had? Or perhaps it does nothing?

durgadas311
February 27th, 2018, 07:04 AM
I know some disks had a disk change line. Did that get reported to CP/M? Did CP/M do something else to detect a changed disk? How did it know if any of its buffers are no longer fresh?

Detection of diskette removal was left to the BIOS/hardware. CP/M 3 formalized that more, but even on CP/M 2.2 a BIOS could detect disk change (if hardware supported it) and then force a login and/or set R/O on the drive in BDOS. Most disk drives didn't provide a diskette change signal, though. At least in the earlier days of CP/M.

durgadas311
February 27th, 2018, 07:10 AM
It sounds like it isn't very tolerant of it, or at least it requires you to be mindful of it. Does CP/M have something it uses to know it isn't the same disk? How does it know to generate the BDOS error? Is there a disk SN or something? Does it read a block and verify it against what it had? Or perhaps it does nothing?


Removable drives on CP/M have a CSV (checksum vector) that creates a hash of the directory. When the drive is first accessed (after BDOS reset, e.g. ^C) the checksum is computed. Every subsequent access to the directory will compare the checksum and force R/O if it is different. But this was a bit haphazard as if two disks shared the same directory data at the beginning, and one was longer than the other, you could not detect the disk change. Also, the BDOS would silently set R/O for the drive, so you wouldn't even know until/unless you tried to write. You also would get confusing results for the DIR command, so if you were unaware it could be rather frustrating.

Chuck(G)
February 27th, 2018, 07:13 AM
Take a look at the "bible", the "CP/M Alteration Guide". Note the fields in the DPB that talk about "CKS" and the DPH has a pointer to a buffer area called "CSV". Quite simply, CP/M checksums the first CKS directory entries on a disk periodically (usually when a new extent is referenced). If the checksum computed at the time isn't the same as the last read one, the "R/O Error" message is displayed and the system terminates whatever was running.

It's crude, but it works fairly well, although not bulletproof by any means. Hard disks, you'll note have CKS set to 0.

I don't know that the "Disk Changed" status line would help any.

----
We used to keep an open file count and mode for our own OS. We'd detect disk changes by monitoring the (5.25") write-protect sensor every 250 msec or so (You can't change a disk in less than 0.25 second).
If the OS saw a disk change and a file was open for writing, we'd stop the program, sound the audible alarm and flash a message until the user re-inserted the disk.

Since CP/M 2.x doesn't track open files (indeed, you don't even need to issue an open call for file I/O--just build the FCB correctly and you're good), this isn't a viable scheme for CP/M.