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 Media
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”.
IBM had realized the problems with the floppy disk interface and solved many of them with the DemiDiskette. There was functionality to spin up the drive when the disk was inserted; a specialized 16-byte (!) unique identifier; format type identifier (only between 256 byte and planned 512 byte sectors but the Diskette ID field seems able to handle different track and sector counts if IBM continued the design); and automatic reallocation of bad sectors. Truly an impressive design if one can get past its very limited capacity of 234 KB per disk. The controller chip was probably a custom IBM design as well but I can’t find any supporting documents.
I believe IBM wasn’t a member of the 3.5″ standardization groups. IBM kept the concepts to themselves until after the industry had chosen a simper method. IBM’s much later efforts to improve the floppy often required specialized models that were very expensive. I doubt even IBM ever had the pull to get most factories rebuilt to meet IBM’s realization of a better floppy drive. The disadvantage of choosing off the shelf hardware is getting stuck with the decisions made by others.
I had never heard about the DemiDiskette, which I guess says a lot about how successful it was 🙂 BitSavers has a drive manual… which talks about a 16-byte disk ID and a 16-bit disk ID. I’m not sure which is a typo. The 234-255K formatted capacity does sound like a big problem at a time when 360K media were common. But bad sector relocation would have been great.
In the late 1980s, IBM might have been able to change things, but I agree they probably did not have the power. I consider the late 1980s to the mid-1990s to be the “lawless” era of PCs when IBM no longer controlled the PC standard and Microsoft did not yet control it.
Amstrad PCWs distinguish between 3.0″ and 3.5″ drives like this:
– Start the drive motor.
– Recalibrate.
– Sense drive status.
– Assuming the “track 0″ bit is set, turn off the drive motor (and wait for it to stop). Then sense drive status again. On a 3.0” drive the “track 0″ bit will still be set, but on a 3.5” drive it won’t.
– If the “track 0″ bit isn’t set, then the drive probably doesn’t exist. But since all PCWs have at least one drive, the code assumes drive 0 exists even in this case, and records it as 3.0” if the “read only” bit is set, else 3.5″.
3,0″ floppies? From the past (1989/90) I remember of a notebook called Zenith MiniSport with an integrated 2″ floppy drive and 2 MB RAM. The Zenith OEM-version of DOS was booted from ROM.
I’m curious. Was this DR-DOS? AFAIK Microsoft didn’t have ROMable DOS at that point yet, that was only in DOS 5.0 (though IBM had ROMable DOS 4.0 in the PS/1).
The Toshiba T1000 boots MSDOS 2.11 from ROM. The ROM behaves like a 256k SSD; presumably the Zenith does something similar.
MSDOS 2.11 wound up being very common in ROM with some models of the Tandy 1000 and the HP Portable and Portable Plus (HP-110 and 110+) in addition to the various laptops previously mentioned. The July 1986 HP Journal devotes a bunch of pages to the HP Portable and explains how the DOS in ROM works starting on page 23. HP has those archives in PDF format for perusal. http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/hpjindex.html
The methods used by companies other than HP to store DOS in ROM may be different. I have not seen documentation on how those companies did it.
One of my first “real” jobs was working on an embedded system for gas analysis and the computer used a EEPROM card (amusingly it was almost as big as one of the relay cards) with MS-DOS 3.3 flashed on to it along with the controller program(s) (written in a combination of MASM and QuickBasic) which stored its data on an external drive. I was involved in the upgrade to MS-DOS 5 and remember the controller program had grown such that it became something of a squeeze getting it all on there. I remember flashing the EEPROM took a very long time as well considering its relatively small size.
I understand that 3.5″ high density drives sense the disk HD hole to prevent formatting low density disks in HD format. But I never understood why HD disks couldn’t be formatted in low density format in HD drives.
I had a “museum” system with a 720Kb disk drive, but in the late 90s it was almost impossible to find such disks. I had to buy 1.44Mb media which I couldn’t format at 720Kb on any other system.
This page http://oldcomputers.net/zenith-minisport.html says it was “MS-DOS 3.30 Plus”, likely significantly customized by Zenith.
I don’t think it was intentional… the drive simply prevented “wrong” formatting (or any other read or write access I believe). Back in the 1980s, no one probably thought that 10 years later you might want to format a HD medium as DD simply because no one sold DD media anymore 🙂
Anyway, taping over or filling the HD hole usually does the trick. Instant DD media.
The T1000 ROM drive is accessed by writing to port 0C8h. Write 0 to page the drive out, 80h to page in the first 64k, 81h for the second 64k and so on. The selected memory range gets paged in at A000:0000.
https://groups.google.com/forum/?hl=en#!topic/comp.sys.laptops/KZyW8yUIkNE describes how to construct a custom ROM drive. I suspect the unknown bytes 3-8 in the header are two sets of head,cylinder,sector giving the locations of CONFIG.SYS and AUTOEXEC.BAT.
Depending on bytes 0 and 2 of the header, the ROM BIOS may patch the result of one particular sector read with MOV AX,4C00h followed by INT 21h. The odd thing is that in the ROM I’m looking at, that sector seems to be in a hidden file called DUM that’s there to occupy unused space (plus the nonexistent part of the filesystem between 256k and 720k).
I covered the HD hole with a hard paper, but I sometimes had trouble to get the disk out of the drive.
Zenith DOS 3.30 plus it just like Compaq DOS 3.31: it supports partitions >= 32Mb being a < 4 DOS version. No idea if it supports booting from ROM or not. But, if the ROM-drive is organized as an INT 13h drive (which I don't know if it is the case) not much customization would be needed. Reading CONFIG.SYS from another drive (like suggested on previous post) would be enough, IMHO. The PS/1 (whose ROM-drive was not an INT 13h drive) stored the drive for CONFIG.SYS and AUTOEXEC.BAT on CMOS.
“I consider the late 1980s to the mid-1990s to be the “lawless” era of PCs when IBM no longer controlled the PC standard and Microsoft did not yet control it.”
Reminds me of the >1024 cylinders mess.
AFAIK the biggest reason for drive detection ends up being that the old PC/AT and PS/2 systems had to boot to a reference disk to configure the CMOS.
IMHO, the RECALIBRATE command for the Intel 8272A chip, which was used in lots of AT compatible systems, will fail if the head is located beyond cylinder 77 originally. Therefore, at least two consecutive failed RECALIBRATEs may be needed to be sure that no floppy drive is present.
Yes, that is true. The old uPD765 clones did have the 77-cylinder limitation, and BIOSes would issue a second RECALIBRATE if the first one failed. All of the “newer” FDCs removed this limitation, although many BIOSes keep issuing up to two RECALIBRATE commands anyway.
Pingback: FPGAmstrad on Nexys4 – dsk doc ressources | MameVHDL