detect a disk change (floppy)

[earlz]

when you change disks is there an interrupt or someway to automatically detect it, I know theres a port read you can do but just I'd rather have it in an interrupt

[Tolga]

When a floppy process is performing, you can understand this. But when no operation, you can't. For this, you must control it.

[Kemp]

This thread may be useful.

[earlz]

what?
you using a translator or something?

[Kemp]

Assuming you mean Tolga, I think he/she/it was saying that when you're doing something with the floppy in your code then it'll do what you want, but if something other than your code happens (for instance if the user hits eject and inserts a new disk) then it won't go out its way to tell you.

[Cjmovie]

IIRC, Windows has IHC and a random set of letters in a part of the bootsector of every floppy. When it does a new sequence of reads, it checks this first to see if it's changed. If it has, the floppy has changed, if not, it's the same floppy (hopefuly!).

[octavio]

when you change disks is there an interrupt or someway to automatically detect it, I know theres a port read you can do but just I'd rather have it in an interrupt

A status bit is set when disk changes, set motor on to read this bit, and read one fd sector to reset.

[Candy]

That bit has been implemented wrongly once, on some IBM systems. Old types I recall, but still in use at some places. They worked the opposite way around, when the bit is set no disk change occured, when it's clear one (or more) did occur.

Microsoft had that in their OS as a flaw that would only occur on those machines, hence the code on each floppy that was written on filesystem creation that indicated the time of creation and some pseudorandom number. No two floppies would have the same number so you would always detect the difference. Unless you diskcopy a disk.

[blip]

I think it shouldn't be too difficult to determine what bit state means what. The disk change bit means a disk wasn't present since last floppy read/write operation so if there is no floppy in the drive the bit will indicate a disk change until a disk is inserted and you do something with it. So when your OS boots, check the bit, do something with the drive that is short enough so the user can't interfere quickly enough, and test again.

Cases:
1) Disk change is initially set but then resets: A disk was inserted and the bit works as expected.
2) Disk change is initially reset but then sets: A disk was inserted and the bit does the IBM thing.
3) Disk change bit stays set: The drive is empty and the bit behaves as expected, or the drive doesn't exist or the line is unimplemented in the drive (it's an active-low signal). I suppose you could passively monitor the BPBs of the floppies used to determine which one it is while initially assuming it is unimplemented.
4) Disk change bit stays reset: The drive contains a disk and the bit works as expected, or the drive is empty and the bit works like on the IBM FDC (determine by command completion status). Another possibility is the FDC doesn't implement it and never reports disk change (I don't know how common this is). Do the passive monitoring here if you want.

Of course ignoring disk change and assuming that it always could change is always easy but slow for the user. Resetting the bit is probably a bit better done by READ ID command since it doesn't DMA anything into memory and returns only a handful of bytes. Reading a sector would require waiting for the sector's header to come up under the head, on average a half revolution, while READ ID completes on the next sector ID found if there is one, about half of a sector on average.

[Candy]

But if you're a commercial company and DOS 3.0 is giving errors on user computers, what is the quickest way to solve it?

Exactly.