• Please review our updated Terms and Rules here

DOS will not recognize disk change

J

jrmymllr

Experienced Member
Joined
Jun 18, 2012
Messages
62
Location
MN USA
I posted this over on Vogons a few days ago, for those of you who frequent both forums. Different username, yes. I didn't give that much forethought.

I have one of those 286 boards from eBay that has a custom non-bootable BIOS and no onboard I/O. I put a different BIOS on the board for the correct chipset, put in a super I/O card (ebay 144836018597), and everything seems to work. There are a few different versions of AMI, and one made by C&T. The C&T BIOS won't boot from the hard drive, a CF card in my case. But it boots from floppy. I ended up using the newest AMI BIOS I could find, and it works great except for one problem.

The CF card already had DOS 6.22 installed on it. It all started when I tried installing something from multiple floppies. When I got to the 2nd disk, it wouldn't take it. After much frustration I realized DOS wasn't recognizing that the disk was changed.

For a point of reference, this occurs even when starting from the HDD and using F8 to bypass everything, or when booting DOS from floppy. Occasionally it will recognize a disk change, but 99% of the time not. I have monitored pin 57 on the super I/O chip, a Holtek HT6550A, which is the disk change line, and it is toggling when it should, i.e., when accessing the drive, the disk was changed, and the heads haven't moved since. The voltage on that pin changes between around 5V or under 0.2V, referenced to power ground, so well within normal logic levels. This occurs on two different floppy cables, and two different floppy drives. I have tried a regular Panasonic 1.44 and a Chinon 1.2MB. I have no issues at all with floppy access other than this.

If I press CTRL-C at the command line, that forces it to re-read the disk and that fixes it temporarily, until the next disk change. I understand I can use DRIVPARM to disable this caching, but doesn't really get at the root of the problem.

I'm out of ideas. I don't know if DOS goes through BIOS for this, but I did try the C&T BIOS and that has the same problem. I have two of these super I/O cards and they both do it in this MB. The other card is in a 486 and that doesn't seem to have any problem. I've even tried reading port 0x3F7 with "debug" since that contains the disk change bit, but that bit stays low. But it's the same on another computer with a correctly operating floppy drive so not sure how useful that is.

This should just work, right?!
 
Does it prompt you to install the next floppy? If so I would expect it to work as it would know the floppy is being changed. I guess it would have to have a way to verify the disk has changed. Maybe the volume name? This is just my opinion though. I do not know how this worked back then.
 
tradde said:
Does it prompt you to install the next floppy? If so I would expect it to work as it would know the floppy is being changed. I guess it would have to have a way to verify the disk has changed. Maybe the volume name? This is just my opinion though. I do not know how this worked back then.
Click to expand...
It doesn't. It runs the drive like it's reading the disk, but the head doesn't move and simply displays the same listing.

The way it's supposed to work is the act of ejecting the disk activates a switch or some other sensor in the drive, then the drive pulls the disk change line low when it's accessed. The next time the head is moved, the disk change line doesn't go low provided the disk wasn't ejected. That part works. The part that doesn't is somewhere between DOS and the floppy controller.

Just tried it with a FreeDOS boot disk and does the same thing.
 
Last edited:
Chuck(G) said:
Does the drive in question have a "disk changed" status on pin 34?
Click to expand...
It certainly does. As I described in my original post, I have monitored the disk change line from the drive all the way to the chip on the controller card, and it changes when it should. This occurs on both drives I've tried which are common high density drives.
 
i have a similar situaton on a 386sx C&T motherboard (well 2 identical boards). I gave up trying all kinds of reg floppy/ide controllers, and threw in a caching controller with floppy. All problems went away. Not sure whats up with these chipsets and cheap ide/floppy cards. Maybe some of them were bundled with a controller?

Cards off top of my head that didnt work, were a Goldstar prime2, some H&M, and a few different Winbond controller. Once I switch to a controller with onboard bios, it works fine.
 
It would seem that the status isn't getting through the hardware--assuming that 3F7 isn't being used by another piece of hardware. Note that the bit is reset every time a seek is executed--and the status isn't valid unless the drive in question is selected. There might be a workaround, depending on how closely the PCs BIOS follows IBM conventions. Byte 40:8Fh uses bits 4 and 0 to indicate drives with change line support. Clearing those bits might cause the PC to detect disk changes the old way (no change line). Haven't tried it, but it might be worth a go.

Do the datasheets for the FDCs on your controller specify that disk change is supported?
 
twolazy said:
i have a similar situaton on a 386sx C&T motherboard (well 2 identical boards). I gave up trying all kinds of reg floppy/ide controllers, and threw in a caching controller with floppy. All problems went away. Not sure whats up with these chipsets and cheap ide/floppy cards. Maybe some of them were bundled with a controller?

Cards off top of my head that didnt work, were a Goldstar prime2, some H&M, and a few different Winbond controller. Once I switch to a controller with onboard bios, it works fine.
Click to expand...
Well that's interesting.

Makes me want to pull the Monster Floppy controller currently in another system and try it in the 286, but also try it with Sergey's floppy BIOS that I gave up getting to work on a P5. It might just work in this.

It is a very strange problem especially after reading someone else with a C&T MB with the same issue. I've thought about connecting my logic analyzer to this to catch it reading that port off the card. Beyond monitoring the address lines and data lines, I'd have to determine what other signals are asserted when this is done. Getting a good place to make these connections is a lot of work though.
 
Chuck(G) said:
It would seem that the status isn't getting through the hardware--assuming that 3F7 isn't being used by another piece of hardware. Note that the bit is reset every time a seek is executed--and the status isn't valid unless the drive in question is selected. There might be a workaround, depending on how closely the PCs BIOS follows IBM conventions. Byte 40:8Fh uses bits 4 and 0 to indicate drives with change line support. Clearing those bits might cause the PC to detect disk changes the old way (no change line). Haven't tried it, but it might be worth a go.

Do the datasheets for the FDCs on your controller specify that disk change is supported?
Click to expand...

What is this byte 40:8fh you refer to? What sets it, the BIOS?

All that's in this MB right now is an ET4000 video card and this super I/O card. The MB has no built-in I/O, so I can't fathom what conflicts there would be. There's always some possibility however, I agree.

The datasheet does indicate disk change is supported, sort of. It has a pin for it, and the application circuit shows it connected. Unfortunately for some stupid reason it doesn't list these type of registers and instead only says "Fully uPD765b and IBM–BIOS compatible floppy disk controller". I have the same card in a 486 with no integrated I/O, also running DOS 6.22, and it works great in that.
 
40:8F (absolute location 48F) is set by the BIOS during POST. So it seems that the card works in other systems, as you noted. The problem must be in the MB BIOS. I don't know if it's possible to change it out.
 
I have found the problem, sort of.

Get this: it appears to be the CF card I have attached. I have tried different combinations of a totally different floppy controller, and Sergey's floppy BIOS. None of that made the problem go away. The only two things that did are 1. pull the CF card, or 2. disable the IDE controller on the super I/O.

In these situations, the hard drive was even disabled in BIOS, so I was booting from floppy during these tests. This is really weird, but now that I think about it, there was a clue. I am currently using AMI BIOS, but there exists a C&T BIOS that wouldn't even boot from the CF card.

But but but.....the hard drive isn't even configured in the BIOS! What is this thing doing? Does it check the IDE port anyway, then goes haywire because it's too fast? And it affects the floppy disk change function? I don't get it.

Up on the to-do list is a real IDE hard drive. Bet it works.
 
You're using a simple CF-to-IDE adapter, not some mongrel like the XT-CF? Sounds like a port usage conflict, as I suspected initially. Take a look at the top of PDF page 40 here. It seems that this card decodes 3F6 and 3F7.
 
Chuck(G) said:
You're using a simple CF-to-IDE adapter, not some mongrel like the XT-CF? Sounds like a port usage conflict, as I suspected initially. Take a look at the top of PDF page 40 here. It seems that this card decodes 3F6 and 3F7.
Click to expand...

Yes, no logic on the adapter at all. Wow, I never even thought about the possibility of the CF card decoding the same address. I had been assuming it only comes alive when the primary IDE port address is accessed, thus enabling the CF. Isn't that what occurs?

Aha! Just found this. https://www.vogons.org/viewtopic.php?t=50434

Haven't read it yet in its entirety but I'm not the only one who's had this problem.
 
Wow great thread on vogons! I was indeed trying to use CF to IDE adapters as well, so this is the same exact problem.
 
Chuck(G) said:
You're using a simple CF-to-IDE adapter, not some mongrel like the XT-CF? Sounds like a port usage conflict, as I suspected initially. Take a look at the top of PDF page 40 here. It seems that this card decodes 3F6 and 3F7.
Click to expand...

Now wait, this guy http://oldcomputer.info/hacks/4hdd/index.htm

claims 0x3F6 and 0x3F7 are part of the I/O address space for the HDD primary controller. This is some random website, yes, but if this is true, how are there not conflicts with all IDE devices?
 
jrmymllr said:
Now wait, this guy http://oldcomputer.info/hacks/4hdd/index.htm

claims 0x3F6 and 0x3F7 are part of the I/O address space for the HDD primary controller. This is some random website, yes, but if this is true, how are there not conflicts with all IDE devices?
Click to expand...
Go back to the original source--the IBM PC AT technical reference for the fixed disk and diskette adapter here. Go to PDF page 16. Note that port 3f7h is shared between the floppy change line and the hard disk (bit 7 for floppy; 6-0 for hard disk). See the Note that describes the register:
Screenshot_2023-02-20_16-18-31.png

Now, a "correct" IDE CF adapter would tristate 3F7 bit 7, but apparently few do this.
Honestly, you'd think that after 40 or so years, people would have this right.
 
I was going to mention that some drives use that wire for drive ready, instead of disk change but it looks like you are past that.
Dwight
 
It's one of the reasons that "360K" drive support was deprecated. No change line and DOS isn't smart enough to monitor the "drive ready" line.
On our old x85 platform, we'd simply sample the "protected" notch sensor every 250 msec or so and note any change in status. Happened so fast, you didn't even see the drive-select light blink.
 
You must log in or register to reply here.
Back
Top