I’m having a weird problem with one of my old buzzard computer’s floppy disk drives. This computer has both a 3.5" and 5.25" floppy drive. The 5.25" floppy drive seems to be working as normal. But the 3.5" floppy drive seems to think that the same disk is in the drive no matter how many different disks I try. This is a problem as I’m trying to install programs that have multiple floppy disks and require swapping them out, but the system doesn’t recognize the new disk.
The OS is MS-DOS 6.22, which I just installed with no problems. I had also tried an older version of DOS, MS-DOS 5.0, which also installed with no problems, but had the same problem post-install with it thinking the same disk is always in drive A. Both versions required swapping 3.5" disks during the installs.
The DIR command shows the contents of the first disk I insert, and then shows those same files on every subsequent disk I insert. I can swap disks no problem on the 5.25" drive (amazing that that thing still works, isn’t it?); DIR shows the files that are supposed to be on each one.
I already tried reseating the cables, and they seem firmly in place. DOS is smart enough to give a read error when I eject the disk and try to run DIR, but put any disk back in the drive and it thinks the same files are there that were on the first floppy disk it read after booting.
The system is an old Pentium 2 machine which I’m trying to rebuild just for fun. It didn’t come with DOS, but the manufacturer has DOS and Windows 3.1 drivers available on its website so I thought, “why not?”
Turn off the computer, turn it on again, and do a DIR on the “new” disk. This is just sanity checking: are you sure the contents of the disk are different from the first one?
Because the behaviour you’re describing is…weird. DIR shouldn’t be reading from some cache somewhere, it should be looking at the actual drive (and it sounds like it knows when there’s no disk there, which gives evidence that it does) every time.
If this problem doesn’t happen during install of some program, but does afterward, that’s a pretty smoking gun that the program you installed is trying to do weird things with a disk cache… Good luck getting a software patch for an MS-DOS 6.2-era program, though.
I’m sorry I don’t have a fix, other than to reboot. What you are describing is a common error. It arises due to a bug in the “disk change” signal, available on all floppy drives. Either it is not recognized by software (most likely) or is not properly set by hardware (less likely). I have seen this error for 30 years, and would love to know the reason, although, at this date, it’s only an academic question.
If I reboot and try a different disk, it reads the disk fine, but then thinks THAT disk is forever in the drive until next reboot. The only thing installed so far has been the MS-DOS operating system and a CD-ROM driver (oakcdrom.sys from a 5.25" floppy disk) Tried versions 5.0 and 6.22. Swapping floppies worked fine during the install of both. Both times, I reformatted the C: drive so it would be a clean slate. Both versions of MS-DOS think the first floppy it reads after boot is forever in the drive, unless the drive is empty, but I can put any other disk back in, and it thinks the first one is in there again.
Echoing musicat’s suggestion, though I think hardware problem with the drive is more likely because I’ve seen them die with that symptom in the past. You might try pressurized air in all the nooks and crannies of the drive. Even removing it and giving it a solid thump on the table isn’t a bad idea.
3.5" floppy drives have a “disk inserted” detection switch (a small plunger switch which is pushed down (closing circuit) when a floppy is inserted). Since the last mechanical action of inserting a floppy diskette into such a drive is for the diskette to be pushed down onto the drive spindle.
These are mechanical switches which can fail over time, either by mechanical wear (if heavily used) or accumulated dust and cruft. As far as I know, they’re not user-serviceable, unless you love taking apart amazingly fiddly and complex electromechanical things to expose the switch, find a replacement, and reassemble the complex electromechanical assembly in correct alignment.
I recommend buying a replacement floppy drive. You probably can’t get one new, but maybe gently used?
That’s exactly what I have experienced. It’s not a minor flaw, but a common problem.
gnoitall nailed it. The only reason I was discounting hardware as the error over software is that this particular indication was so common that it seemed unlikely to be hardware. OTOH, software, if poorly designed (Wee Willy, RU listening?) is often misled by errors in timing, and that’s all it would take to make this “error”.
If you can’t find a reasonably-priced 3.5" drive, PM me. I might have one I could mail you – <might>, as I have a box of ~30 internal, used floppy drive units somewhere in the basement (5" and 3.5"?) and I could send you one if I can find that box. But don’t count on it.
I don’t think reading the files is the OP’s problem, since the drive reads fine after a cold reboot. The problem is he needs a reboot to change floppies, then read them.
Thanks for the kind offer, but I already have some spare drives. I guess I’ll have to break down and try one after work. I was hoping to avoid changing the drive, just because this case doesn’t have a standard 3.5" drive bay for the floppy drive, so I have to remove the face plate and the plastic eject button to get it to fit.
It still doesn’t make sense that it works perfectly fine from MS-DOS setup, just not after it’s installed to the hard drive.
CoastalMaineiac, if you install another floppy drive, I’d be really interested in the results. Maybe you could help resolve the hardware/software bug debate.
Uh, the SmartDrv disk cache utility was typically started up in Autoexec.bat, right? If it appears there, can you try adding the A- parameter to disable all caching of drive A? Something like:
I’ll try fiddling around with the SMARTDRV command before swapping drives. That could explain why everything worked when booting from the install disk, but stopped working after install. I don’t think it’s loaded from the boot disk, but the installer does add it to AUTOEXEC.BAT on a fresh install.
Well, I found the problem. It ended up being a hardware problem after all, but not with the drive. I didn’t pull the ribbon cable out to look at it earlier; I just pulled the ends and plugged them back in to make sure it was properly plugged in, so of course I missed this:
I swapped out the cable for another one and it works perfectly. It also explains why the other floppy drive still worked fine, since the cut was after the B-drive connector.
Incidentally, just for giggles, I booted from the MS-DOS setup floppy disk with the cut cable still hooked up, and it actually did have the same problem at the command prompt. DIR showed whatever files were on the first floppy it read, no matter which disk was in the drive. The confounding thing is that the MS-DOS installer was able to proceed as normal, and recognized each disk in sequence as I installed MS-DOS to the hard drive, but the Windows installer could not. There must be a difference in the way the two installers try to find the files they’re copying over.
Vague recollection, with no cite: CP/M required the user to press a key combination to indicate that a disk had been swapped. In the early days of the development of MS-DOS, Microsoft wanted to avoid the keystroke requirement and someone (Gates himself?) spent some time trying to figure out how fast a human could swap diskettes to determine how often the directory had to be re-read. So they weren’t relying on the hardware change signal at that point. Of course, that meant that the drive’s head had to travel back to the directory track often.
Speculation: MS-DOS 5.22’s basic I/O still used that pessimistic approach, but once SMARTDRV was loaded, it assumed the drive’s change signal was functional and relied on it – which was the only way it could provide a useful cache on a diskette anyway. So, if you have a defective change signal, DOS works fine but SMARTDRV gets mixed up.
