Detecting floppy drive types and installed media is a far trickier topic than it should have been. In the ideal world, software could determine how many floppy drives are attached, what their capabilities are, and what media is installed in them, if any. In the real world, software can only accomplish some of those tasks.
Detecting whether a drive is present is the only easy part. If a (functioning) drive is present, the RECALIBRATE command will succeed. If no drive is present, recalibration will fail because the FDC will never detect the TRK0 (track 0) signal (typically after stepping 80 or so tracks). If drive presence is detected, the real fun starts.
It’s possible to detect an old 40-track drive. The method IBM’s PC/AT BIOS uses is to seek to track 48, then step back towards the outermost track and watch for the TRK0 signal. On an 80-track drive, TRK0 would go active after 48 steps. On a 40-track drive, it will activate sooner because the drive was in fact not able to step all the way to track 48 (the head cannot physically move that far). This method seems somewhat brutal but must have worked reliably enough for IBM to use it.
Beyond this, drive detection gets very sketchy. To software, a typical 1.2M 5¼” drive does not look any different than a 1.44M 3½” drive—especially when there’s no disk in it. For this reason, operating systems generally rely exclusively on CMOS information for detecting the type, if not presence, of floppy drives.
In some IBM machines built around 1990, drive detection was possible. First, a pin was added to distinguish between 720K and 1.44M 3½” drives. The mechanism was later enhanced with another pin to provide two bits of information and enable detection of 1.44M, 2.88M, and 1.2M drives.
Unfortunately this mechanism never became widespread. PCs generally relied on the user correctly identifying the drive type in BIOS setup.
Detecting the types of floppy media is both simpler and more complicated. Disks have notches or holes indicating density, but this information is typically not available to software. The physical density indicators exist only to prevent users from accidentally (or intentionally) formatting low-density media as extremely unreliable high-density disks. This is implemented internally within the drive.
For formatted disks, software simply needs to go through a short list of supported data rates (normally 500 Kbps and either 250 or 300 Kbps depending on drive type) and use the READ ID command to check whether the format is recognized. This takes less than 2 disk revolutions in the worst case (if the format is not recognized and command execution started just after the index hole passed by) and much less if the operation succeeds. However, waiting for the drive to spin up does take time (typically 500 ms minimum).
If the disk is unformatted, software obviously cannot check to what its format is. In a typical system, software cannot detect the media type either. IBM again designed drives with the capability to report the inserted media type. Floppies with unformatted capacity of 1MB, 2MB, or 4MB could be detected (corresponding to DD, HD, and ED media). And again the rest of the industry did not take this up.
Usually it’s the user’s responsibility to specify how the disk should be formatted. Based on the actual media, the formatting operation will succeed or not. In the IBM (and clone) BIOS, interrupt 13h service 17h (called “Set DASD Type for Format” by IBM) is used to specify the desired format. This is typically followed by calling the INT 13h/05h (“Format Track”) service to successively format all tracks of the diskette.
Evolved, not Designed
The PC floppy subsystem is a typical victim of slow evolution. In the early PCs, there was more or less only one floppy drive type available and detection was not necessary. In the PC/AT, it was possible to distinguish between low- and high-density drives by detecting the number of tracks. When 720K and 1.44M drives arrived, only half-hearted attempts were made to support drive detection.
The efforts to establish drive and floppy detection capabilities were doomed to failure when IBM no longer controlled the PC standard. The lowest common denominator (drives with no detection capability) made supporting drive and media detection impractical.
The situation was mitigated by the fact that the number of common drive types and media was very limited, the drives in a system were almost never changed, and users were generally capable of correctly identifying the drive type in the BIOS setup. The solution was far from elegant, but it was “good enough”.