Plucking certain IDE pins for better CF-IDE compatibility \ VOGONS

Plucking certain IDE pins for better CF-IDE compatibility

Topic actions

First post, by jakethompson1

Posted on 2025-07-31, 23:36

jakethompson1 Offline

Rank l33t

Rank: l33t
Posts: 2238
Joined: 2015-11-17, 04:16

It is well-known that the definitions of certain IDE pins have changed in different revisions of the ATA standard. CF-IDE adapters and CompactFlash cards themselves don't necessarily implement these changed pins in a backward compatible way when connected to a multi-I/O card that wires these directly to ISA.

Pin 27 is IOCHRDY (formerly reserved). On my QD-U386DX (UMC 481) board, having certain CF cards connected via CF-IDE causes a soft hang during boot (Ctrl-Alt-Del still works). In a conversation with another user, it was suggested that CF adapters should put a diode on this pin and many don't, and that this issue is well-known in the RiscPC community.

Pin 28 is Cable Select (formerly DALE). This pin is well known to cause mysterious issues involving VGA cards (Re: "Fixed" 386sx motherboard works but not with 16-bit VGA card). Another user reports POST beeps related to VGA card initialization, and parity errors when this was connected to a CF-IDE adapter.

Reviewing http://cd.textfiles.com/internetinfo/standard … 13/atbuscam.txt vs. https://en.wikipedia.org/wiki/Parallel_ATA these are the pins that changed meaning:

Pin 21 changed from reserved to DDRQ
Pin 27 changed from reserved to IOCHRDY
Pin 28 changed from DALE to Cable Select
Pin 29 changed from reserved to DDACK
Pin 32 changed from IOCS16# to NC
Pin 34 changed from PDIAG# to DMA66 Detect

If you pluck pin 27 on your CF-IDE adapter, it will break faster PIO modes that use this pin for flow control, so that adapter would have to be exclusively for ISA machines.
If you pluck pin 27 on your Multi-I/O card, it would theoretically break spinning hard drives that actually use this pin properly if they ever get put into such a faster PIO mode?

In contrast, is there any reason not to automatically pluck pin 28 on the IDE interface whenever you come across an ISA Multi-I/O card? Do any IDE drives ever have a legitimate need to connect to ALE?

The other pins seem innocuous, possibly with the exception of pin 34, is there any reason to remove it from the Multi-I/O card?

Reply 1 of 5, by mbalmer

Posted on 2025-08-01, 00:09

mbalmer Offline

Rank Newbie

Rank: Newbie
Posts: 91
Joined: 2021-05-16, 22:16

Just adding a quick note from personal experience here:

I had a 386 board that seemed particularly persnickety when it came to multi-IO cards and CF adapters, especially in combination with VGA cards. It would produce parity errors with CF cards over a certain size pretty reliably, and it would become especially egregious with multiple CF cards on the same IDE channel.

Pulling pin 27 seemingly cured the parity error problem, and allowed me to be able to boot to drives pretty reliably with a CGA card installed, but it would still throw POST code beeps claiming the video card was bad if I had a VGA or EGA card in the system.

As it turns out, the CF cards themselves weren't actually the problem when it came to that last bit. The adapter itself turned out to be the problem, because pin 28 (ALE) is just tied to the GND pins, which in my limited understanding is causing glitching on the rest of the ISA bus because it's loading the pin down, causing runt pulses instead of fully-driven signals.

After removing pins 27 and 28 both from the adapter, the cards now work fine and no more bleeping computer.

Reply 2 of 5, by jakethompson1

Posted on 2026-06-18, 05:03

jakethompson1 Offline

Rank l33t

Rank: l33t
Posts: 2238
Joined: 2015-11-17, 04:16

Following up on this, I believe at a minimum the JMicron SATA-IDE do not implement pin 32 (IOCS16#) and these are necessary for ISA Multi-I/O cards that forward this on to the chipset so that reads and writes to port 1f0h are recognized as 16-bit, while in later ATA revisions IOCS16# is implied as always on for port 1f0h and off for the others. When I test doing an ATA IDENTIFY in debug the top eight bits of each word are zeros.

Reply 3 of 5, by pshipkov

Posted on 2026-06-18, 07:00

pshipkov Offline

Rank l33t

Rank: l33t
Posts: 2293
Joined: 2018-10-11, 05:08

I have seen this pattern where 16-bit ISA IDE controller with attached to it CF card adapter hangs the system during POST with certain 16-bit ISA graphics cards.
Currently i have 2 IDE controllers of choice that can be switched around for that purpose. So far one of them always unblocks POST if the other one trips there.
This is 100% IDE controllers issue. Going through several different CF card adapters does not have an effect. Same ror different CF cards.

retro bits and bytes | DOS media library

Reply 4 of 5, by rasz_pl

Posted on 2026-06-18, 12:47

rasz_pl Offline

Rank l33t

Rank: l33t
Posts: 4680
Joined: 2017-06-04, 00:57

jakethompson1 wrote on 2026-06-18, 05:03:

Following up on this, I believe at a minimum the JMicron SATA-IDE do not implement pin 32 (IOCS16#) and these are necessary for ISA Multi-I/O cards that forward this on to the chipset so that reads and writes to port 1f0h are recognized as 16-bit, while in later ATA revisions IOCS16# is implied as always on for port 1f0h and off for the others. When I test doing an ATA IDENTIFY in debug the top eight bits of each word are zeros.

There is a fix! We had Re: SATA HARD Disk in 286/386 Mobo: Is it possible? where RayeR decided to dig deeper. Manages to identify the problem Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
one of my guesses is correct Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
RayeR confirms it and even finds other people from RISC community who discovered same thing earlier Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
and makes a hardware fix Re: SATA HARD Disk in 286/386 Mobo: Is it possible? tiny pcb with two TTL chips

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/Zenith_ZBIOS Zenith Z-386 MFM-300 ZBIOS disassembly

Reply 5 of 5, by jakethompson1

Posted on 2026-06-18, 16:29

jakethompson1 Offline

Rank l33t

Rank: l33t
Posts: 2238
Joined: 2015-11-17, 04:16

rasz_pl wrote on 2026-06-18, 12:47:
There is a fix! We had Re: SATA HARD Disk in 286/386 Mobo: Is it possible? where RayeR decided to dig deeper. Manages to identif […]
Show full quote

jakethompson1 wrote on 2026-06-18, 05:03:

Following up on this, I believe at a minimum the JMicron SATA-IDE do not implement pin 32 (IOCS16#) and these are necessary for ISA Multi-I/O cards that forward this on to the chipset so that reads and writes to port 1f0h are recognized as 16-bit, while in later ATA revisions IOCS16# is implied as always on for port 1f0h and off for the others. When I test doing an ATA IDENTIFY in debug the top eight bits of each word are zeros.

There is a fix! We had Re: SATA HARD Disk in 286/386 Mobo: Is it possible? where RayeR decided to dig deeper. Manages to identify the problem Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
one of my guesses is correct Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
RayeR confirms it and even finds other people from RISC community who discovered same thing earlier Re: SATA HARD Disk in 286/386 Mobo: Is it possible?
and makes a hardware fix Re: SATA HARD Disk in 286/386 Mobo: Is it possible? tiny pcb with two TTL chips

Thanks, I was digging around and saw some of that as well. I wonder whether IOCS16# is implied for all VLB and PCI IDE, or if there are some that still expect it to be generated by the drive like Multi-I/O cards. This could explain the flakiness of SATA-IDE with those IDEs as well.

Go to top of page Go to top of page

Back to General Old Hardware