OSDev.org

I have noticed that floppy drive detection code (from http://osdever.net/tutorials/detecting_ ... drives.php) does not work properly on my laptop.
I have a Dell Inspiron B130. I have checked the BIOS options and they make no mention of a floppy drive. But the detection code always says that there is a 3.5" 1.44MB floppy drive present when in fact, there is not one. My OS loads with GRUB from the local hard drive (I think that might be significant). If I am forgetting to mention anything, please let me know.

What does the BDA say?

Do you have a USB device or CDROM inserted that could be emulating a floppy drive?

Does it have one of those, CD that can be take out and replaced with a floppy ?.

Hi,

uglyoldbob wrote:I have noticed that floppy drive detection code (from http://osdever.net/tutorials/detecting_ ... drives.php) does not work properly on my laptop.
I have a Dell Inspiron B130. I have checked the BIOS options and they make no mention of a floppy drive. But the detection code always says that there is a 3.5" 1.44MB floppy drive present when in fact, there is not one.

I'm not sure about model B130, but other Dell Inspiron models have optional external floppy drives connected via. USB. I would assume that in this case the BIOS's disk services (Int 0x13) pretends a normally floppy drive is present for backwards compatability (e.g. for DOS), and modern OSs (Linux, Windows) detect the optional/external floppy when they scan USB.

For my old floppy driver, after detecting that the floppy drive controller is present and resetting it I sent a "recalibrate" command to each device and assumed that the device wasn't present if it failed to recalibrate (the recalibrate command doesn't work if there is no floppy drive, but does work if there is a floppy drive, even if there's no disk in the drive).

AFAIK it's impossible to properly detect the floppy drive type (3.5 inch or 5.25 inch, and maximum capacity) using manual probing. I've never really trusted the BIOS, as the BIOS can't detect what sort of disk drive is present either - usually it just reports whatever the user felt like telling the BIOS (and it will never mention devices connected to a second, third or fourth floppy driver controller).

There's also a related problem - detecting what sort of media is in a disk drive. For example, if you know the floppy drive is a 3.5 inch that supports 1.44 MB floppies, the you stilll don't know if the actual disk is a 720 KB disk, a 1440 KB disk or a 1680 KB disk (or any other non-standard format). One way around this problem is to rely on the "BIOS Parameter Block" that DOS/Windows use, but IMHO the BPB is a hack (it isn't necessarily present and can't represent unusual disk formats).

To get around both of these problems, my driver didn't care what sort of disk drive is present and did it's own probing to autodetect the media (without relying on the BPB).

Not really knowing what sort of disk drive is present didn't really matter much. If the user is formatting a new disk, then they need to specify which format the disk should be formatted as. For example, if the device driver knew it was a 1.44 MB drive it still wouldn't know if the user wants to format the disk as a 720 KB disk, a 1440 KB disk or a 1680 KB disk. If the user tries to format a disk that the hardware couldn't support (e.g. trying to use the 1440 KB format with a 5.25 inch 1.2 MB drive) then it'd probably fail to format correctly, but that's not my problem..

So, the only question left is how to detect what sort of disk media is present without caring what sort of disk drive is present. This is actually easier than it sounds...

The first thing to do is try to guess the data rate. To do this, first recalibrate the drive, then use the "read ID" command (with "head = 0") and try 500 Kbps, then 300 Kbps, then 250 Kbps. If the command is successful you'll know the data rate is correct. If none of the data rates work then you can assume there's no disk in the drive.

Next, for some disk controllers/drives bit 3 in status register 3 can be used to determine if the disk is double sided (bit set) or single-sided (bit clear). If the disk controller/drive doesn't support this then the bit will be set regardless, so if the bit is set you'd try a "read ID" command with "head = 1" and then compare sector ID information returned in the results phase to make sure. If the command fails it's a single sided disk and if the information returned says "head 0" it's a single sided disk, otherwise you've confirmed that it is a double-sided disk. Note: status register 3 also contains the "write-protected" status flag so it's good to grab that too.

Now you can use the information you've obtained as a filter in a "disk format database". The disk format database is sorted in order from largest capacity to lowest capacity. The database might go something like this:
Starting from the first entry, you'd attempt to read from the last possible sector (e.g. try cylinder 79, head 1, sector 18 for the 1440 KB format) while skipping impossible formats (e.g. if you know the disk uses the 500 Kbps data rate and is double sided, you can skip most of the formats). As soon as you can successfully read the test sector you know the disk format.

The interesting thing is that you'd support unusual combinations accidentally. For example, you'd support the 1200 KB format in 3.5 inch disk drives and the 720K format in a 5.25 inch drive. This might (potentially) cause problems with gap lengths, but in practice there's lots of built-in tolerance in these formats (except the 1680 KB format, which takes advantage of this built-in tolerance).


Cheers,

Brendan

Is it possible that the code detects floppy drive CONTROLLERS instead of actual drives? The documents for floppy drives seem to suggest that there can be two floppy drive controllers and 4 floppy drives, but drives 3/4 aren't widely supported.

These days, most modern systems don't support more then 1 floppy drive.. It's very unfortunate

Hi,

Brynet-Inc wrote:These days, most modern systems don't support more then 1 floppy drive.. It's very unfortunate

I've never seen a desktop computer that doesn't support 2 floppy drives (one floppy controller built into the motherboard), even though they might have a floppy drive cable without the second connector, and even though the case itself might only have one small drive bay (you can get mounting brackets to install a floppy drive in a larger mounting bay though).

You can also have additional floppy controllers on multi-I/O expansion cards (I've got a few of them here - usually they come with a HDC, a FDC, two serial ports and a parallel port, with jumpers to select which I/O ports, DMA channels, IRQs, etc). AFAIK the only real limit is the number of slots on the motherboard and the number of DMA channels - 3 floppy controllers with 6 floppy drives is entirely possible, and 4 floppy controllers may or may not work (I think you run out of ISA DMA channels).

uglyoldbob wrote:Is it possible that the code detects floppy drive CONTROLLERS instead of actual drives?

The CMOS values are meant to refer to drives, not controllers. I'd assume this may include emulated floppy drives (e.g. connected via. non-standard controllers and/or USB), and AFAIK it may be 2 normal floppy controllers with one drive each. It can also be entirely wrong (e.g. the user used the wrong BIOS settings) and it may not correspond to the disk drive numbers the BIOS uses for Int 0x13 (e.g. if the BIOS has a "swap floppy drives" option).

uglyoldbob wrote:The documents for floppy drives seem to suggest that there can be two floppy drive controllers and 4 floppy drives, but drives 3/4 aren't widely supported.

For ISA floppy drive controllers, the first FDC uses very standard resources (I/O ports, DMA channels, IRQs, etc), the second FDC uses "sort of standard" resources, and the third (and fourth?) use whatever resources didn't conflict with other things.

It's a little like serial ports, where standards mention up to 4 serial ports but the only practical limit is resources (e.g. avoiding I/O port and IRQ conflicts). The "standards" themselves typically come from the original IBM specifications for the XT, AT or PS/2 and don't reflect practical limits.

In addition there's software limits - just because the hardware can handle the devices doesn't mean that software does. For example, whoever wrote DOS decided that floppy drives would have names starting from "A:" and hard drive partitions would have names starting with "C:", which doesn't leave room for a third floppy drive between "B:" and "C:". IMHO this sort of software limitation was fairly stupid back when people used DOS, but for modern computers it's not so bad (not many people use floppies now anyway, and computers with more than one floppy drive are getting rare).


Cheers,

Brendan

Apologies, I remember reading somewhere that modern floppy controllers were unable to handle more then a single floppy drive.

I can't find where, so ignore my comment for now...

Brendan wrote:You can also have additional floppy controllers on multi-I/O expansion cards

I have a few early ISA cards as well... but do PCI cards exist? I suspect they would require drivers.

Hi,

Brynet-Inc wrote:

Brendan wrote:You can also have additional floppy controllers on multi-I/O expansion cards

I have a few early ISA cards as well... but do PCI cards exist? I suspect they would require drivers.

I don't think PCI cards can use the ISA DMA controllers, so a floppy controller on a PCI card couldn't be compatible with the ISA floppy drive controllers we're used to, and would require it's own special drivers.

I don't think any PCI card manufacturers would actually bother putting a non-standard floppy controller on a PCI card though - it makes more sense to use USB and rely on the USB specification for storage devices.


Cheers,

Brendan