Detecting an empty drive with a NEC uPD765A or compatible FDC is theoretically easy using the ‘drive ready’ signal. In practice, the drive ready mechanism is completely unusable on IBM PCs and compatibles due to the way the FDC is wired.
AT-style controllers and drives support the disk change line signal which more or less replicates the drive ready functionality. To recap, the change line signal is controlled by the drive (the FDC merely selects which drive should be reporting it) and it goes active when the drive door is open. To deactivate the change line signal, there must be a medium inserted in the drive and the drive must receive a step pulse.
In the absence of a change line signal, software often implements a pessimistic/optimistic algorithm. If the drive has been idle for a while (typically two seconds), the medium is considered changed. As long as the drive is working, the medium is thought not to have changed. This algorithm works well in practice: It is very difficult to swap a disk in less than two seconds, and any attempt to remove the medium while the drive is busy will be detected as an error.
The OS/2 floppy driver (IBM1FLPY.ADD) uses both of these approaches. If there is no change line support, the logic is approximated. When the change line is available, more straightforward media change reporting is implemented.
A minor fly in the ointment is that some floppy controllers (notably PS/2 Model 30) use inverted change line levels. OS/2 detects normal or inverted change line logic by deselecting all drives and checking the DSKCHG bit in the Digital Input Register (DIR).
The IBM1FLPY.ADD driver also accepts command line parameters to override change line support detection. This can be used to trigger an interesting error in some OS/2 system applications, notably the installer.
The OS/2 installer likes to ask the user to remove any floppy from the boot drive before exiting. The idea that the system needs to be rebooted (either by the user or by the installer itself), hence no floppy should be left in the boot drive.
When the floppy driver is not using change line support, the OS/2 installer gets confused, refuses to quit and keeps asking the user to remove the disk from the drive even if no disk is inserted.
This is a subtle bug in the installer. The code attempts a floppy access operation and examines the return code. It is only satisfied by an IOERR_MEDIA_NOT_PRESENT error. Unfortunately, without change line support, the best the floppy driver can do is an IOERR_MEDIA_CHANGED error—as explained above, without the change line the floppy driver simply has no chance to distinguish an empty drive from an unreadable disk.
Relying on specific error codes which are not guaranteed to occur is a fairly common programming mistake. That said, it could be argued that in this case it is incorrect design, because detecting an empty floppy drive requires specific hardware support which may not be present. If the OS/2 floppy driver does not require change line support, the OS/2 installer shouldn’t either. In practice, this is very unlikely to happen on real hardware because finding a system which has no change line support and can run 32-bit OS/2 would be quite difficult.
A number of IBM APARs were produced suggesting how to change IBM?FLPY to avoid issues of having the floppy drive lock up. The strangest one was to replace IBM2FLPY (the PS/2 specific version) with IBM1FLPY /MCA. Clearly multiple people hit problems with OS/2’s default floppy support.
This seems specific to certain drives: early ones built before the change line was introduced; ones where a jumper was set to ignore the change line; and drives like the 2.88 MB floppy used in some Thinkpads which had an erratic change line. The controller supported the change line and OS/2 spotted that fact; OS/2 couldn’t tell that the drive would not support change line.
The OS/2 floppy driver relies on the BIOS to report whether change line is supported or not, which probably isn’t 100% reliable, especially if the user can install a broken/misconfigured drive. The OS/2 driver then tries to figure out the polarity of the signal, which also isn’t quite reliable. Of course the driver has to work whether a floppy is initially in the drive or not, so reliably verifying the change line behavior is difficult.
It’s not like IBM has anyone but itself to blame for stuff like inverted change line polarity… I can’t fathom why the IBM PC/AT and PS/2 behave one way and the dreaded Model 30 flips the logic. The newer integrated FDCs like Intel 82077 support AT, PS/2, and Model 30 behavior which is an open invitation for board designers to configure things incorrectly.
In general I have to say that the floppy subsystem is one of the worst understood and worst documented components of the classic PC architecture. The original NEC datasheets are misleading (not wrong!) due to the way IBM wired things, and the documentation for newer FDCs is even worse. IBM at least provided logic diagrams for the PC and PC/AT, so engineers could figure out how things really work. With the newer parts it’s just guesswork and important details are left unsaid.
Studying the OS/2 floppy driver source is quite amusing, too… with comments like “The Yamato lab [ThinkPad folks] seems to be able to design dskt controllers that fool the automatic changeline polarity detection in the driver” or “We need to [disable IBM Model L40SX FDC power management] since the genius who designed the dskt controller set auto powerdown interval to 500ms so the controller powers down during the motor spin-up interval!”.
Makes me wonder about the changeline behavior on the Model 30-286. If I had to guess, it is the PC/AT behavior.
“The newer integrated FDCs like Intel 82077 support AT, PS/2, and Model 30 behavior which is an open invitation for board designers to configure things incorrectly.”
Well, the port 3F6h sharing with the ATA interface pretty much forces the AT mode. Which reminds of the PS/2 Lacuna planar where ATA was added. They had to create a way to switch the purpose of port 3F6h to resolve the conflict with PS/2 mode, which they patented.
“Studying the OS/2 floppy driver source is quite amusing, too… with comments like ”
And imagine if MS took the OS/2 2.x path. In fact, I wonder if the PS/2 model 35SX was partly a ploy to create some 386 processor IBM ISA bus hardware IBM OS/2 2.0 would support.
If I recall correctly, the drive ready signal is one of the issues which makes adapting modern disk drives a problem on Commodore Amigas. Inversely, those drives which could be made to work with the Amiga via a jumper are likely to have properly working drive ready signal.
I imagine the drive ID would be another issue, since all PC drives are configured to use ID 1 (‘drive B’) and a cable twist is used for drive A.
It seems that Microsoft stumbled upon similar problems when developing Windows 95, so they decided to just drop the support for diskette change detection:
http://blogs.msdn.com/b/oldnewthing/archive/2009/04/02/9528175.aspx
There is no way to detect whether a floppy is in the drive or not on an AT or PS/2 style FDC, and never has been. The change line only provides the ability to query whether the disk a) has not changed, or b) may have changed since the last check. That is a pretty significant distinction.
If the post is talking about the change line, it’s really sloppily written. If it’s talking about something else, I wonder what it is (it doesn’t sound like the media IDs supported by some latter-day controllers).
Anyway, if the motivation for Win95 was to avoid spinning up the drive when bringing up the Explorer or whatever and checking whether a disk is in the drive, then the change line just doesn’t work too well for that and I’m not surprised they dropped the idea. If there is a disk in the drive and has not been touched, then the spin-up can be avoided (change line says “no change”). But the motor has to be spun up and the head stepped to clear the change line, so if the change line says “disk may have changed”, the spin-up and rattling cannot be avoided. And as long as the drive is empty, this has to be done every time. Perhaps poor hardware design for not providing the feature, or perhaps poor software design for not taking hardware (dis)abilities into account.
At any rate, IBM seems to have been cleverer than Microsoft with their trick to deselect all drives and check the change line. In my experience the OS/2 floppy handling worked quite well, though it’s not surprising that it wasn’t 100% bulletproof.
“And imagine if MS took the OS/2 2.x path. In fact, I wonder if the PS/2 model 35SX was partly a ploy to create some 386 processor IBM ISA bus hardware IBM OS/2 2.0 would support.”
Not that it is much of a reason for MS not to.
Does the motor really need to be spun up to move the head to detect the change line?
AFAIK Amiga just steps the head back and forth on a drive with no disk in it, to detect if a disk is inserted. This is of course annoying so there are “no click” programs that you can run that patches this. I haven’t investigated how they patch it but I guess perhaps they try to step to “track -1” or maybe do one step in each direction so fast that the drive cannot actually move the head, or something alike.
Re drive ID’s on Amiga: All “home usage” models only have place for one drive in the case, and uses ID 0 and the regular motor signal. The motherboard port for this single drive, and each separate drive connected to the external drive port, has their own latch to be able to turn the motors of independently of each drive.
I don’t remember how it’s done in the desktop Amigas which support two internal drives. Maybe they spin both motors at the same time, or more likely there is a twist on the cable (but probably not the same as on PC). Maybe it even differs between the models. Anywall all Amigas that support two internal drives have a jumper where you select if you have a second internal drive or not. All external drives identify themself as a drive but that identification, together with the motor latch, is on a small separate board to be able to use otherwise mostly standard floppy hardware. The OS always assumes the first drive to be present and being an 80 track drive, thus that drive doesn’t have any identification hardware IIRC.
Does the motor really need to be spun up? Yes and no. As far as the drive is concerned, the change line signal goes inactive when a disk is inserted and “a STEP command is received when the DRIVE SELECT command is TRUE” (from Teac FD-235HF datasheet). I don’t know how safe it is to move the head when the disk is not spinning, but in a PC, the drive select signal is gated by the motor enable signal, which means you really must have the motor on in order to move the head to detect that a new disk has been inserted.
Is that stupid? Of course it is. I think IBM was only interested in detecting that the disk has been (potentially) changed, because they only worried about data corruption. They didn’t consider the case where the system might want to know that a new disk has been inserted. Which to be fair was not much of a concern back in 1984.
Oh, so in theory on a PC you could activate the motor signal and step the head and detect a disc change even without letting the motor spin up completely 🙂
I guess that it wouldn’t do any harm to move the heads one track without the drive spinning. Although the heads are mostly supposed to withstand the force from a rotating disc, they are not as fragile as for example the rotating heads on a VCR (or DAT, or…) which breaks easy if you apply force in the wrong direction. (B.t.w. That’s why you should keep your cleaning thing steady and rotate the drum with the heads while cleaning the heads on a VCR (or DAT e.t.c.), and only move around the cleaning thing if you want to clean the oudside of the fixed part of the drum and then make sure you aren’t near any head).
Also as Amiga first made the choice to move the heads without spinning up the motor, and as there were no reports of any issues with it, we could probably be sure that atleast the drives that Commodore Amiga used themself were specified to withstand that, and as many diferent brands of external drives never afaik had any problems with that we could probably also be sure that in practise other manufacturers drives did also withstand it.
Regarding the media it would at maximum happend only once everytime you insert a diskette. I don’t know exactly how it did work but it seemed like the OS didn’t have to step the head to be able to detect the removal of media, only the insertion. Therefore an empty drive did “click” but a drive with a disk in didn’t “click”.
Re 1984. At the time IBM constructed the PC/AT FDC adaptor they probably didn’t know what Apple were up to, but the Mac was AFAIK released the same year as the AT.
Any second version of the FDC on AT; and of course all PS/2 and newer machines, should have had a correctly functioning disk change detect mechanism.
P.S. as a sidenote, on the old Commodore 8-bit computers diskdrives (atleast the 1541 which was by far the most common, the one designed for C64) the write protect detector were afaik used to detect disk change. Both a protected and an unprotected diskette will make detector flip state once or twice when a disk is removed or inserted. The drives also had another way to detect disk change. In the headers of each track there were a disk ID stored and if that didn’t match what the drive expected it would consider the diskette changed. (There were more detections in the headers, for example the track number were written in the header and if that didn’t match the drive would do a seek to track 0 and back to where it were going to read/write. That was a painful thing on a 1541 as Commodore decided that a track 0 detector were something you could omit to cut costs, so therefore the drive did a “bump”, i.e. stepped the stepper outwards an mount equal to 35 tracks even if the head were already at track 0. That made quite a noise and if the drive had been turned on for a long time the internal linear power supply would have heated up the mechanism enough to make that “bump” strong enough for the step motor axle to slip a bit so you would have to recalibrate the head positon… Compared to that the PC floppy subsystem is really excelent 🙂 )
As I mentioned, having a disk insertion detection mechanism wasn’t a requirement for IBM in 1984, and not in 1987 either. The software at the time didn’t need or use it. Disk removal was always detected immediately, without doing anything else.
I remember hearing much about floppy drive recalibration with the C64. I didn’t know it was because of intentional head bumping.
Interesting – I know it’s an old post but it reminds me of “MSBACKUP” (and the Windows equivalent “MWBACKUP”) from MS-DOS 6.0. As far as I remember, the first time one uses it does run some sort of check to see if it can detect disk change. It worked on my machine back then (an IBM). And it really would detect disk change… so during the backup process it would ask you to insert the next disk and you would simply eject the old one as normal and insert the next, and the program automatically proceeded. However, it felt quite scary to me because the light on the drive was lit when you were to replace floppies and usually you weren’t supposed to remove the disk when that was the case. I think perhaps the floppy was even spinning. I don’t know if it could damage the drive to remove the disk in this state, but seemingly that’s how Microsoft designed this backup program.
Removing the disk from a drive when it’s spinning won’t physically damage anything, but might corrupt data on the disk if it’s being written to. That is why users were taught to wait for the light to go off before removing disks.
The backup program behavior is caused by the PC drive design. The drive change line goes active when a disk is removed, but inserting a disk isn’t enough to deactivate it; the drive head has to be stepped first (I believe this was done so that the user couldn’t replace the floppy while the system was inactive without the software noticing). The upshot is that the change line is useful to detect that a disk had been removed (or really ensure that it hadn’t), but it is not at all useful for detecting when a new disk was inserted.
AFAIK some software uses the READ ID command which has rather interesting behavior in that it will not terminate before it sees two index pulses (to ensure that the entire track was seen). If there is no disk, there are no index pulses and the command never completes… until a disk is inserted and starts spinning, and then the software very quickly finds out that the drive is no longer empty. I am pretty sure that this mechanism will require the drive light to be on, because it is only possible to “watch” one specific drive this way. Which of course is fine for a backup program.