OSDev.org

As in topic. How can I check if there is floppy in FDD? Second question - Is it possible to tell based only on FDC registers (no disk reading) if user took out disk and put in another one?

I seem to remember (could be wrong) that's there's no way to check

You just have to try to read the disk and see if it fails (and put up with the noise).

As for finding a disk change, look at http://www.koders.com/c/fid051291340B94EC7F5D1A38EF6843466C0B07627B.aspx, function fdc_disk_changed (that's what Google found, anyway). As it does motor_on(), I suppose that'll make some noise too.

I think the problem is that the FDD is really stupid and doesn't notice when you eject a floppy disk until it tries to read from it.

hello....

You can check whether media(floppy) is changed i.e if user have inserted another floppy. During this CHAN (MSB)bit of Data Input Register (0x3F7 i guess) will be set.

you can have a function like:

I think the problem is that the FDD is really stupid and doesn't notice when you eject a floppy disk until it tries to read from it.

hey please dont say it stupid dear.. many of us are relying on it. Ofcourse you can find it out without reading...

Ah, OK. I'm sure I read it somewhere...

Anyway, I had a look on google and found this: Google Groups link, which says that the motor has to be on first. Hopefully that won't make all the clunky noises

[edit by candy] don't make that long links without text, it kind of screws up the page layout [/edit]

Well I did as you said but the problem is that I don't know how to reset this bit after reading it. I've tried to reset whole FDC but it didnt work. Any sugestions?
[edit]
I know that reading from floppy will reset this bit but I was wondering if there is any other method

hi..
i dont understand why you want to reset that bit. Its on Data Input Register which is read only.. The bit will only indicate that the floppy disk has been changed since last operation.. you can use it when u r having buffering in ur driver. So first check if floppy has been changed, if not then read from the buffer or else flush the buffer and read from newly inserted floppy...

I don't know much about the PC FDD controller. But Amigas used basically identical hardware. AFAIK, the OS attempted a track change every three seconds or so, and if that failed, it figured that no floppy was inserted.

The track change generated an audible "click", which could however be easily patched - I don't know what the patch actually did, though. The media detection still worked.

Bottom line, it can be done with stock FDD hardware without audible clicking, I just don't know if the PC controller is capable of it.

PC floppy controller is virtually capable of nothing! that's just a motor you can spin up or down with a magnetic head on a stepper which will seek for a given position and decode 1s and 0s ... period.

I'm not even sure that the controller (i mean on the floppy, not in the chipset) is capable of buffering bytes if you don't eat them fast enough

it would be easier to turn it into a rolling robot than trying to detect if media is inserted/ejected/replaced etc.

My approach would be "don't bother. If user want to use old media such as PC floppy, let him tell what he does with mounts/umounts etc". Don't forget it may require you to retry 3 times before you can conclude there's no disk! there's nothing more annoying under Win9x than a program freezing for 5-10 seconds because it tries to "sense" a file on a non-present floppy...

Keep media change detection for CDs, USB devices (including floppy drives, why not ) where it is meaningful.

here's nothing more annoying under Win9x than a program freezing for 5-10 seconds because it tries to "sense" a file on a non-present floppy...

exept for windoze Xp whitch my teacher says she has gotting to sit and spin for 20min, i have only seen myself a 10min wait before did windows actually put there non-timed out floppy driver in non-preemptible space?

I meant the controller on the chipset, not the one in the drive. The hardware of Amiga and PC floppy disk drives is very nearly identical. (HD drives were a bit trickier, but DD drives were interchangeable unless I'm mistaken.) Which proves how very braindead the PC chipset controller actually is - because I've never had a PC-style waiting-on-floppy lockdown on an Amiga.

As for "let the user cope with it"... well, in the end there is nothing that stops a user ejecting a disk drive without unmounting it first. (Unless you're using an old Mac.) The system should be smart enough to handle it in a stable way:

• write data buffers immediately to minimize the time window for eject-with-unwritten-buffers;
• when trying to write buffers, check it's still the same media as originally intended (i.e., on fopen()), and tell the user to reinsert the original media if it has been changed.

If the user can hard-eject the media, don't rely on the user remembering to use mount / umount in the correct places, but do your best to cater for errors.

If I'm not mistaken the FAT filesystem (used by dos & windows)
for floppy's includes a volume serial number. It was put there
to detect if the user changed floppies (and didn't just insert
the same one again).

Of course they may also do a quick check if a floppy is inserted
at all, no idea if they do/can.

Rob wrote: If I'm not mistaken the FAT filesystem (used by dos & windows)
for floppy's includes a volume serial number. It was put there
to detect if the user changed floppies (and didn't just insert
the same one again).

you're not mistaken ... and "format" is expected to give different serial numbers to all the floppies it sees, yet nothing guarantees the uniqueness of a floppy's serial.
That's another pathetic (imvho) hack around poor hardware to try to improve its reliability.

E.g. all the GRUB disks created from the "grub image" on clicker's repository will have the very same serial number, so if you modify their content and swap one for the other, the OS will happily go on with writing.

am i nasty ? oh yeah! you have no idea ...

Compare that to macintosh systems where the computer only can eject the disk. If it's not done with it, it won't release it. If you ask for ejection while computer is busy writing a large file, it will let you do it, do your business with another disk and _then_ prompt you for feeding back the disk it was copying file XXX on so that the copy is completed.

Oh, yes, and you had to drag the floppy over the trash to have it ejected. you like it or not.

A policy that fails pitifully the very moment the first time MacOS runs on a hardware that doesn't support this OS-driven eject - dooming Apple to provide expensive Apple-only floppy drives till the end of (floppy) days or break their metaphor.

And then there's the emergency eject that's available on all drives, even if you disable the eject button (e.g. on a ZIP drive). Have you been so sure of your "soft eject" that you missed that possibility, perhaps happily overwriting data on the new media because you didn't sense the media change?

And I don't have to tell you what "dragging the icon into the trashcan" is, from a intuitivity standpoint.

In one of the spec for the NEC floppy controller (dont have name of link for it at the moment) there was a bit that was mentioned that changes when a disk is ejected.

Pype: it definitely isn't foolproof. But it was probably a good
idea at the time. It's "nice" that the Mac won't throw out the
floppy until it's done, but it already fails now with an USB stick,
for example. I can just yank that out whenever I want.