Deunan wrote on 2023-02-18, 22:19:

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).

I tried another drive and it does the same thing. However, it seems to be because the head didn't move when simply performing a "dir". If I read a file off the disk and the head moves, then the disk change line immediately changes back to high. So that seems normal.

eesz34 wrote on 2023-02-19, 15:38:

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 […]
Show full quote

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.

EDIT: pulling the disk change line to ground doesn't change the state of the register per debug.

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

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.

EDIT: pulling the disk change line to ground doesn't change the state of the register per debug.

eesz34 wrote on 2023-02-19, 17:54:

EDIT: pulling the disk change line to ground doesn't change the state of the register per debug.

Curious.
Now I would wonder if you force a pullup on pin34 to see if there is a change.
For a pullup you would want to connect pin 34 through a 10k resistor and maybe a diode to 5v.

It might seem a bit weird but from my own messing around with a floppy drive and breadboard, I've noticed that 3.5 floppies give their signal lines much less current compared to the 5.25 and goteks. There isn't enough current to light an led and even a cheap multimeter has too much impedance and cannot measure the signals at all, some floppy drives are worse than others. I'd be curious if it's a case of the super io chip is just being really insensitive or something.

Assuming you've already checked that it's not a physical issue with the superio chip not getting the signal in the first place and you don't have a gotek handy since that would do too.

Now this is just my own thinking, I wouldn't think an insensitive super io chip is very likely. Though depending what you're measuring the signals with, it might be worth putting a Schmitt trigger between the floppy drives and the instruments.

CalamityLime wrote on 2023-02-19, 18:43:

Curious. Now I would wonder if you force a pullup on pin34 to see if there is a change. For a pullup you would want to connect […]
Show full quote

eesz34 wrote on 2023-02-19, 17:54:

EDIT: pulling the disk change line to ground doesn't change the state of the register per debug.

Curious.
Now I would wonder if you force a pullup on pin34 to see if there is a change.
For a pullup you would want to connect pin 34 through a 10k resistor and maybe a diode to 5v.

It might seem a bit weird but from my own messing around with a floppy drive and breadboard, I've noticed that 3.5 floppies give their signal lines much less current compared to the 5.25 and goteks. There isn't enough current to light an led and even a cheap multimeter has too much impedance and cannot measure the signals at all, some floppy drives are worse than others. I'd be curious if it's a case of the super io chip is just being really insensitive or something.

Assuming you've already checked that it's not a physical issue with the superio chip not getting the signal in the first place and you don't have a gotek handy since that would do too.

Now this is just my own thinking, I wouldn't think an insensitive super io chip is very likely. Though depending what you're measuring the signals with, it might be worth putting a Schmitt trigger between the floppy drives and the instruments.

I believe I have those possibilities eliminated. I have measured the voltage right at pin 57 of the Super I/O which is /DSKCHNG, referenced to power supply ground. It changes between close to 5V and under 0.2V, so well within the logic high and low levels. This is with a pretty good meter. The pullup on the controller is 150 ohms so it's quite stiff, and from looking at a floppy drive schematic the disk change line is an open collector, so given the pull-up, I wouldn't expect it to be able to source anything.

I do have a Gotek, but it's in a different computer. Anyway I have tried a 1.44MB drive and a 1.2MB, and they both cause the same behavior. However in both cases the disk change line is going low when the drive is accessed, and it's not moving the heads unless I clear the directory cache with CTRL-C.

As this MB had some sort of custom non-bootable BIOS when I got it, I had to replace the BIOS. I thought that may have something to do with it, but I tried a totally different BIOS and the problem still exists. The BIOS I'm using now is AMI, and I tried a C&T BIOS. They are both for the correct chipset, and both have this floppy problem (or not, depending if DOS is reading the floppy controller directly or not). The MB has absolutely no integrated I/O.

For what it's worth, I just tried reading port 0x3F7 on another computer and it always reads 0x40, regardless of if I changed the disk or not, and regardless of whether I have a disk in the drive. So not sure if this is a good method to use.

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

As this MB had some sort of custom non-bootable BIOS when I got it, I had to replace the BIOS. I thought that may have something to do with it, but I tried a totally different BIOS and the problem still exists. The BIOS I'm using now is AMI, and I tried a C&T BIOS. They are both for the correct chipset, and both have this floppy problem (or not, depending if DOS is reading the floppy controller directly or not). The MB has absolutely no integrated I/O.

For what it's worth, I just tried reading port 0x3F7 on another computer and it always reads 0x40, regardless of if I changed the disk or not, and regardless of whether I have a disk in the drive. So not sure if this is a good method to use.

I'll be doing some 5.25" floppy drive cleaning and testing this week, I can also test the 0x3F7 port (I'll try to test ISA card FDC and a mobo with integrated controllers).
As for the BIOS, it could have something to do with it. Perhaps there is some config register in that SuperIO chip that controls the behaviour of the disk change bit, and the BIOS is not setting it up correctly? Just a guess.

eesz34 wrote on 2023-02-18, 19:40:

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.

and: As this MB had some sort of custom non-bootable BIOS when I got it, I had to replace the BIOS. I thought that may have something to do with it, but I tried a totally different BIOS and the problem still exists.

This tells me: It is your 286 motherboard, not the controller or floppy drive. Very few 286 motherboards had onboard floppy controllers (compared to the total w/o one)...
What model 286 board is it ?

Horun wrote on 2023-02-19, 23:35:

eesz34 wrote on 2023-02-18, 19:40:

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.

and: As this MB had some sort of custom non-bootable BIOS when I got it, I had to replace the BIOS. I thought that may have something to do with it, but I tried a totally different BIOS and the problem still exists.

This tells me: It is your 286 motherboard, not the controller or floppy drive. Very few 286 motherboards had onboard floppy controllers (compared to the total w/o one)...
What model 286 board is it ?

It's this one: https://theretroweb.com/motherboards/s/jc-inf … ration-jcs286-s

But does the motherboard have anything to do with this since it has no onboard I/O and has to rely on an add-in controller? I wondered about this too, but can't come up with a way for the MB to interfere, at least to the extent of my knowledge. Unless the BIOS is doing something.

Just tried a FreeDOS boot disk. Same problem! Not surprising I suppose.

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.

(also posted on VCFED)

which CF card are you using?

CalamityLime wrote on 2023-02-20, 20:59:

which CF card are you using?

It's a 256MB Kingston I bought almost 20 years ago for a digital camera. Apparently I'm reinventing the wheel because afterwards, I found these:

A solution to compact flash IDE (CF-IDE) floppy drive problems

Floppy drive stops working with Compact Flash to IDE adapter

I never thought about the possibility of the CF card causing problems. I thought it was completely disabled except for when the floppy address was accessed. Apparently these things can still respond even when the primary floppy address isn't asserted.

HDC and FDC share address space, it's a pretty bad setup but usually it works if the controller (card or on-board) knows to de-mux the individual ports. Otherwise you need an IDE device (HDD or CF card, or other adapter) that is smart enough not to respond to I/O that is not meant for it. I guess some adapters and CF cards are not doing this properly.

Just FYI, I had a go at one of the floppy drives today so I had a chance to test the 0x3F7 port. It's not explained anywhere but apparently the drive motor must be running, and the drive itself must be selected, for the bit to indicate disk change. Selection is obvious but motor on is not. To select, and turn motor on in debug:
- for A: drive - o 3F2 1C
- for B: drive - o 3F2 2D
- to turn motor(s) off: - o 3F2 0C

Once drive is selected AND motor is running, doing - i 3F7 should return correct value of DCD in bit 7.

Deunan wrote on 2023-02-20, 22:10:

HDC and FDC share address space, it's a pretty bad setup but usually it works if the controller (card or on-board) knows to de-m […]
Show full quote

HDC and FDC share address space, it's a pretty bad setup but usually it works if the controller (card or on-board) knows to de-mux the individual ports. Otherwise you need an IDE device (HDD or CF card, or other adapter) that is smart enough not to respond to I/O that is not meant for it. I guess some adapters and CF cards are not doing this properly.

Just FYI, I had a go at one of the floppy drives today so I had a chance to test the 0x3F7 port. It's not explained anywhere but apparently the drive motor must be running, and the drive itself must be selected, for the bit to indicate disk change. Selection is obvious but motor on is not. To select, and turn motor on in debug:
- for A: drive - o 3F2 1C
- for B: drive - o 3F2 2D
- to turn motor(s) off: - o 3F2 0C

Once drive is selected AND motor is running, doing - i 3F7 should return correct value of DCD in bit 7.

I did find information about the disk change line to be difficult to find. But I knew the line was changing by measuring the voltage on it, and the pull-up on the controller and the fact both drives use the same line suggested only one was driving it
at a time, and an open collector output at that because they are sharing.

My CF adapter doesn't do much of anything from looking at it. It has no chips on it, and it appears most are the same way. I'd imagine if a set of bidirectional transceivers were used to keep the CF card off the data bus, that might fix it. That is assuming hard drive access should only occur when asserting ox1F0.

I have to say ever since I started using DOS back when it was current, I never used debug until yesterday. Me being a hardware nut it's cool to be able to read and write these ports so easily.

Problem solved. This is somewhat overkill, but they are convenient little adapter boards for these SSDs and I also added a sound transducer to roughly mimic HDD sounds.

The SSDs have a TBW of 8PB. No worries here about wear out.