Calamitylime has been working on something for this. Let me tag him.

His work is focused around more than two floppy drives

I think there is also a way to make dos refresh
The directory using driver.sys even if you don’t have more than one or two drives. But others know more about this and can fill you in.you may have to use older dos versions.

I don't know much, I was just tinkering with a very similar topic recently.

But as far as I know dos talks to the drive based on the bios settings, which is how some recovery/backup software lets you set the type of floppy disk yourself and ignore what the bios says.
You could use CRTL+C to force clear the dir cache instead of restarting.

I mean an obvious test would be to swap the cards just in case there's something up with the super io chip

eesz34 wrote on 2023-02-18, 02:39:

I'm using a 286 motherboard with no built in I/O, so it has a super I/O card (this one https://i.ebayimg.com/images/g/1EcAAOSwM […]
Show full quote

I'm using a 286 motherboard with no built in I/O, so it has a super I/O card (this one https://i.ebayimg.com/images/g/1EcAAOSwMyRjfnYk/s-l1600.png).

I found out that when I change disks, it gives me the same directory listing. I changed the cable, then the drive, and it still does this. When I reboot it then gives the correct listing.

I actually have another of these I/O cards and they were NOS, and this doesn't occur in the other computer. I haven't swapped cards yet, but I checked the soldering and trace for floppy pin 34 and it looks good. I'm using DOS 6.22, and still have the problem when I skip config.sys and autoexec.bat with F8.

Is there a utility I can use that will tell me if the disk change signal is toggling? I have not yet got my logic probe out to test pin 34, but I find it unlikely two cables and two drives have the same problem. Is this a BIOS function, or does DOS read the floppy controller directly?

worse case you can use the DRIVPARM directive in your CONFIG.SYS to tell DOS to ignore the disk changed line and assume disk always changed

eesz34 wrote on 2023-02-18, 02:39:

I found out that when I change disks, it gives me the same directory listing. I changed the cable, then the drive, and it still does this. When I reboot it then gives the correct listing.

What drive is that? 5.25"? 3.5"? Something else? What density? What is set in the BIOS?

Deunan wrote on 2023-02-18, 18:24:

What drive is that? 5.25"? 3.5"? Something else? What density? What is set in the BIOS?

It's now a 3.5" 1.44MB, and it's set to that in the BIOS. Interestingly, it sometimes works, but most of the time not. I booted from a DOS 6.22 disk, swapped disks and that worked. But then I tried it again and it didn't work so it's intermittent. If I use CTRL-C, it will read the new disk correctly.

For what it's worth, I swapped the I/O card with the one in my 486 and it's definitely not the card. I'm now looking at the disk change line. My logic probe says it's logic high, and ejecting and inserting a disk doesn't change the state, not even momentarily. What is this line supposed to do? Does it go low as long as a disk is inserted, or does it change state only when that drive is accessed? There's only one disk change line per cable so I don't know if the controller simply doesn't know what drive had a change if the pin on the drive is the equivalent of a switch to ground. My I/O card has a 150 ohm pull up to +5 which seems pretty stiff to me, but anyway this tells me the drive should pull it down through a switch or an open collector/drain.

EDIT: according to page 16 of the PDF at http://bitsavers.trailing-edge.com/components … eet/TC8602F.pdf, the disk change line only comes to life when the drive is selected. Makes sense.

maxtherabbit wrote on 2023-02-18, 14:18:

worse case you can use the DRIVPARM directive in your CONFIG.SYS to tell DOS to ignore the disk changed line and assume disk always changed

Good to know. I didn't know about this.

Ok, so on top of knowing it's not the card as I've swapped it with another, the disk change line is going low when that drive is selected. Less than 0.2V so that's easily a logic low.

The interesting thing is if I reboot and leave a disk in (i.e., boot from the floppy), each time I access the drive the disk change line stays high. As soon as I eject it and put another in, or the same disk, then the disk change line goes low every time I access the drive, even though I changed the disk only once. This might be normal but doesn't quite make sense to me. Nonetheless it seems it the change line is dropping low on access when it should, and possibly more than it should.

So why then does DOS keep using the cached copy?

i once had a similar problem with a usb floppy drive, not recognizing a new disk;
turned out to be the microswitches inside the drive all needed some contactcleaner.
If i recall correctly, in the usb floppy drive there were 3 switches, no idea why 3, one for ro/rw one for dd/hd and one for ? disk change perhaps.

eesz34 wrote on 2023-02-18, 21:50:

the disk change line goes low every time I access the drive, even though I changed the disk only once

Since the drive doesn't know what the OS expects, the signal is kept low on each access until the next head seek. If the head moves yet the drive still outputs low then it must be a problem with the drive. Either it is not properly detecting disk presence (a high-resistance switch might be interpreted both ways) or there's something wrong with the chips (or really bad noise on power due to dead capacitors).

weedeewee wrote on 2023-02-18, 21:57:

If i recall correctly, in the usb floppy drive there were 3 switches, no idea why 3, one for ro/rw one for dd/hd and one for ? disk change perhaps.

Yup. 3.5" drives will have 3rd switch because of how write protect and density detection works on these. Some very late (EOL) 3.5" models lack the density detection and accept only HD floppies, these will have only 2 switches.

Here's a question: is there an easy way to read an I/O register from DOS, using some utility or whatnot? Apparently the most significant bit of 0x3F7 is the flag for if the disk changed. If I can see what this is, it will at least tell me if the status bit is working.

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to describe the specifics, but I believe you run debug.exe, then you type (inside the utility) "i <port number>" to read one byte from the port. My reference books are still packed (in a massive pile of boxes) from a recent house move.

In your case, that would be

1debug
2i 0x3f7

debs3759 wrote on 2023-02-18, 22:59:

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to descri […]
Show full quote

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to describe the specifics, but I believe you run debug.exe, then you type (inside the utility) "i <port number>" to read one byte from the port. My reference books are still packed (in a massive pile of boxes) from a recent house move.

In your case, that would be

Copy code to clipboard

1debug
2i 0x3f7

Thank you for this information. However in the meantime I found a slick DOS utility called IOVIEW that displays all I/O ports in real time. However, the value I'm seeing doesn't make much sense 🙁

eesz34 wrote on 2023-02-19, 00:03:

debs3759 wrote on 2023-02-18, 22:59:

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to descri […]
Show full quote

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to describe the specifics, but I believe you run debug.exe, then you type (inside the utility) "i <port number>" to read one byte from the port. My reference books are still packed (in a massive pile of boxes) from a recent house move.

In your case, that would be

Copy code to clipboard

1debug
2i 0x3f7

Thank you for this information. However in the meantime I found a slick DOS utility called IOVIEW that displays all I/O ports in real time. However, the value I'm seeing doesn't make much sense 🙁

If you full DOS installed go ahead and run Debug and compare to IOview. Yes that is the correct Debug to display one byte from a Port....

Horun wrote on 2023-02-19, 00:50:

eesz34 wrote on 2023-02-19, 00:03:

debs3759 wrote on 2023-02-18, 22:59:

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to descri […]
Show full quote

Read up on the debug utility that ships with DOS. That can do it. It's been too long since I used it for me to be able to describe the specifics, but I believe you run debug.exe, then you type (inside the utility) "i <port number>" to read one byte from the port. My reference books are still packed (in a massive pile of boxes) from a recent house move.

In your case, that would be

Copy code to clipboard

1debug
2i 0x3f7

Thank you for this information. However in the meantime I found a slick DOS utility called IOVIEW that displays all I/O ports in real time. However, the value I'm seeing doesn't make much sense 🙁

If you full DOS installed go ahead and run Debug and compare to IOview. Yes that is the correct Debug to display one byte from a Port....

Hmm, debug gives me 1A, and IOVIEW gives 26. Neither value seems normal.

1A will be the hex value of the decimal number 26, so it's probably just displaying it in different bases

eesz34 wrote on 2023-02-19, 03:20:

Hmm, debug gives me 1A, and IOVIEW gives 26. Neither value seems normal.

DOS debug always prints hex values. As for it being (not) normal - looks OK to me? Only bit 7 is defined, the rest can be connected to whatever (some drives can output detected density). b7=0 in your case which means no disk change was detected - this bit should be 1 if the drive has /DC=0, and as I've explained drive should go back to /DC=1 after you step the head at least once.

If you are sure the cable is passing the signal properly to mobo/controller then look for a cut trace, cracked via, bad solder, etc on the controller side. Or even something as simple as bad contact between cable and the pins.

debs3759 wrote on 2023-02-19, 03:41:

1A will be the hex value of the decimal number 26, so it's probably just displaying it in different bases

That is an interesting coincidence, but IOVIEW is displaying in all hex., and I have seen both 1A and 26 when using debug. Still not sure why I never see the upper bit set.

Deunan wrote on 2023-02-19, 11:08:

eesz34 wrote on 2023-02-19, 03:20:

Hmm, debug gives me 1A, and IOVIEW gives 26. Neither value seems normal.

DOS debug always prints hex values. As for it being (not) normal - looks OK to me? Only bit 7 is defined, the rest can be connected to whatever (some drives can output detected density). b7=0 in your case which means no disk change was detected - this bit should be 1 if the drive has /DC=0, and as I've explained drive should go back to /DC=1 after you step the head at least once.

If you are sure the cable is passing the signal properly to mobo/controller then look for a cut trace, cracked via, bad solder, etc on the controller side. Or even something as simple as bad contact between cable and the pins.

You're right, the bits set with both values are likely not an issue. I wish I could determine what those other bits mean but it may be irrelevant. Interestingly the datasheet for that Holtek chip doesn't give this information.

I'm monitoring the disk change signal from another connector on that floppy cable and it changes just as it should. I do need to probe that pin on the super I/O chip though. I've inspected it under a microscope and it looks good, and both boards have this same issue although it seems to work on another motherboard. I need to do further investigation on that front however as I'm not 100% positive about the functionality on that system.

I do wonder though if it's not possible to see this register value indicate a disk change unless the utility checking it is the one turning on that drive. Perhaps I can short the disk change line to ground and then use debug to check it, if it's a real time indication of that pin state.