What I/O ports does IDE really need?

[jrmymllr]

I bought some of these little SSD boards with a 44 pin IDE connector and want to use them on older systems. It plugs right into a thin client I have and works great there. However once I get it connected to an older motherboard (through all sorts of adapters) it causes weird problems. It will begin booting from it, so I know it's working, but causes the floppy controller to fail and won't boot all the way. The POST screen shows serial ports at 2E8, 2F8, 3E8, and 3F8 that only appear when the SSD is connected.

The IDE interface I'm using connects this thing directly to the ISA bus which is probably normal and why all this is occurring. But both /CS0 and /CS1 are driven by the chip on the I/O card, and the datasheet for the chip indicates one is for 1F0-1F7 and the other for 3F6 and 3F7. Maybe the SSD is ignoring the chip selects for some addresses?

I'm thinking about making an interface board that tri-states the IDE data bus unless it's being talked to and that seems like it would solve the problem. So that would be 0x1F0 to 0x1F7 for sure, and maybe I'd also include an option for secondary. Are there any others required for old school IDE? It appears there's other ranges for bus mastering, but I don't need that.

For 0x3F6 I found this at https://ceunican.github.io/aos/36.IO_Devices.pdf:

Address 0x3F6 = 0x80 (0000 1RE0): R=reset, E=0 means "enable interrupt”

0x3F6 is used by the floppy controller, so not sure what to make of this.

And the MSB of 0x3F7 is also used by the floppy controller, but does IDE still used this?

I'm guessing someone out there knows more about this!

 

[Chuck(G)]

3F7 with the original 5170 controller was used, AFAIK, only for floppies in the BIOS. The HD information on 3F7 isn't terribly useful and I suspect was included for diagnostic purposes. On an IDE device, 3F7 is of little to no use as it simply reflects the drive select/head (port 1F6) register. Port 3F6 is of some marginal use, as it's the alternate status register--same bits as the 1F7 status register with the difference that it does not result in an interrupt acknowledgement. That can be of marginal use, conceivably.

 

[jrmymllr]

3F7 with the original 5170 controller was used, AFAIK, only for floppies in the BIOS. The HD information on 3F7 isn't terribly useful and I suspect was included for diagnostic purposes. On an IDE device, 3F7 is of little to no use as it simply reflects the drive select/head (port 1F6) register. Port 3F6 is of some marginal use, as it's the alternate status register--same bits as the 1F7 status register with the difference that it does not result in an interrupt acknowledgement. That can be of marginal use, conceivably.

Well ok, I was going to mark this post for deletion/ignore and post a different one because of some new information. But we'll see where it goes.

Since posting this, I have learned more about it. For some reason I thought the IDE interface had the full address bus on it, but there isn't enough pins for that anyway! See there are two CS lines, for for each address range, and a 3-bit address bus for selecting the different registers. Then how in the world is my BIOS detecting four serial ports from this SSD? If I unplug the SSD, it finds none, because I have none enabled elsewhere.

I would assume the BIOS checks various addresses to test the presence of serial and parallel port, but that means something has to be at the address. How can this SSD present something in that I/O address space when it's seemingly impossible to do so?

 

[Chuck(G)]

I suspect your IDE adapter may employ some shortcuts in I/O port decoding, which might not matter to a real IDE drive, but causes the CF card to respond.

 

[jrmymllr]

I suspect your IDE adapter may employ some shortcuts in I/O port decoding, which might not matter to a real IDE drive, but causes the CF card to respond.

I suppose that's the only plausible explanation. Maybe I need to put my scope/logic analyzer on this.

 

[Eudimorphodon]

That is extremely goofy. Because yeah, as noted, the bulk of the decoding of the address bus isn't done by the device on the cable, it's the job of the IDE host adapter. For sanity's sake, have you tried other PATA devices (real hard disk, whatever) on this card? There shouldn't be anything special about those PATA->SD adapters to distinguish them from any other PATA device; technically they're based on a CF->SD chipset, so if they were living in a CF body they might support the additional address lines that CF cards have for operating in "memory" mode, but those aren't exposed when they're packaged in the 40/44 pin PATA packages.

The IDE interface I'm using connects this thing directly to the ISA bus which is probably normal and why all this is occurring. But both /CS0 and /CS1 are driven by the chip on the I/O card, and the datasheet for the chip indicates one is for 1F0-1F7 and the other for 3F6 and 3F7. Maybe the SSD is ignoring the chip selects for some addresses?

For clarity on this when you say "directly to the IDE bus": it's considered good form/not really optional for IDE host adapters to have a set of buffers (usually 74LS/HCT/ALS/whatever/245s) between the ISA data pins and the data pins running to the PATA port. These buffers should be tri-stated if the IDE port isn't selected. I guess it's possible if your card omits them (which, again, isn't really cool) the device hanging off of it might be pulling the data lines on the bus to a state that the BIOS device detection routine doesn't expect. (For instance, maybe the motherboard has pull-ups on all the data lines and the BIOS expects any unoccupied port/mem address to return all ones when read, but this device sitting on the end of a cable and a maze of adapters is dragging one of those ones down to a nebulous state.) If your adapter card doesn't have buffers I'd recommend a better one.

 

[maxtherabbit]

There was a thread recently on vogons about certain CF cards decoding errant addresses. Vague I know but that's all I remember offhand

 

[jrmymllr]

That is extremely goofy. Because yeah, as noted, the bulk of the decoding of the address bus isn't done by the device on the cable, it's the job of the IDE host adapter. For sanity's sake, have you tried other PATA devices (real hard disk, whatever) on this card? There shouldn't be anything special about those PATA->SD adapters to distinguish them from any other PATA device; technically they're based on a CF->SD chipset, so if they were living in a CF body they might support the additional address lines that CF cards have for operating in "memory" mode, but those aren't exposed when they're packaged in the 40/44 pin PATA packages.

I haven't tried a real HD yet. But for the record, I have been using a CF card with a as-simple-as-it-gets adapter and while I have some floppy-IDE conflicts, it doesn't cause phantom serial ports to be detected.

Also this isn't an SD adapter. It's an actual mini PATA SSD with a Silicon Motion controller. But for the sake of discussion it's probably equivalent.

For clarity on this when you say "directly to the IDE bus": it's considered good form/not really optional for IDE host adapters to have a set of buffers (usually 74LS/HCT/ALS/whatever/245s) between the ISA data pins and the data pins running to the PATA port. These buffers should be tri-stated if the IDE port isn't selected. I guess it's possible if your card omits them (which, again, isn't really cool) the device hanging off of it might be pulling the data lines on the bus to a state that the BIOS device detection routine doesn't expect. (For instance, maybe the motherboard has pull-ups on all the data lines and the BIOS expects any unoccupied port/mem address to return all ones when read, but this device sitting on the end of a cable and a maze of adapters is dragging one of those ones down to a nebulous state.) If your adapter card doesn't have buffers I'd recommend a better one.

Ok good point. There are 3 chips on this I/O board, and none are standard logic. The design appears to be mostly lifted from the main IC's datasheet application circuit at https://datasheetspdf.com/pdf-file/1463203/HoltekMicroelectronics/HT6550A/1
Or, a pic of the board: https://i.ebayimg.com/images/g/1EcAAOSwMyRjfnYk/s-l1600.png

All the connected IDE pins do indeed route directly to ISA except for the few driven by the super I/O chip like CS and reset. So apparently this is a super cheap board. I liked the idea because they were NOS. I do see though how the shortcut the I/O board's design took could cause some uncertainty on the logic levels of signals on the bus.

You got me thinking, so I connected the SSD and the same floppy to a P5 board with integrated I/O and it doesn't do any of this funny stuff. No phantom ports, boots from the SSD and the floppy fully functions. So since the SSD is a 44 pin interface and I want to connect to 40 pin, I might just design a custom interface board with buffers on it to solve this problem after verifying it with a prototype first.

So much for the idea that any commercialized board is properly designed!

 

[jrmymllr]

There was a thread recently on vogons about certain CF cards decoding errant addresses. Vague I know but that's all I remember offhand

Yeah one was probably mine I posted about that recently. My IDE interface seems to be inferior and appears to be causing all sorts of issues.

 

[maxtherabbit]

Proper buffered IDE interface cards are cheap and abundant on ebay. Designing a new one would really be a colossal waste of time, but to each his own I suppose

 

[jrmymllr]

Proper buffered IDE interface cards are cheap and abundant on ebay. Designing a new one would really be a colossal waste of time, but to each his own I suppose

It depends on what you mean by cheap. I have two of these NOS super I/O cards that otherwise seem fine, and I also need an interface between the SSD and 40 pin IDE interface. Nearly all 40 to 44 pin adapters have a female 44 pin connector, but so does the SSD. The buffering would go on the adapter board as it seems that's all that's required. The I/O decoding can still occur on the I/O card. So this would be a relatively simple design, and I can then customize this to plug directly into the IDE connector, for example.

I am also itching to build something and this is an excuse.