Back in time I fought a lot with such things, trying to solve the problem from the HW side, as you noticed isn't that simple.

So I tried Uniata which has parameters to force/ignore what the cable connections tells, still no joy.

So I asked help to Alter (the author of uniata) which was very kind (I hope is going well, given he is ukrainian), he spotted a bug in his driver that affected exactly such parameters, at least on the controller I was using, and fixed it in no time.

The controller I was using wasn't a Promise, but support for Promise TX controller should be there, so give UniATA a try (look at the documentation about the parameters, as I don't remember the sintax, too much water passed under the bridges since then).

Thanks for your input. For this particular scenario, if a CF card won't boot (because the controller sets UDMA mode 5), there won't be a software opportunity later to adjust the UDMA mode.

Yes my problem was actually the opposite, the card didn't work as its best capability.

Whatever you can try what happens using something like this

https://www.amazon.com/40-Pin-Female-Drive-Ex … 698&sr=8-3&th=1

Technically a 40 wires cable should be enough to degrade from UDMA mode 5 to slower modes.

And anyway, having a cable makes easier to check various scenarios w/o doing anything definitive to the boards

What do you measure between ground and pin 34 in a power off state with the transcend card only installed into the adapter?

Based on symptoms it seems clear that the transcend is holding pin 34 to logic low. If you want to overcome that externally you'd want to know how strong the pull down is

Power-off, with the Transcend in a cable-less CF-IDE adaptor, it is open circuit between pin 34 and 5V, and open circuit between pin 34 and GND.

Power-on, using a cable-less CF-IDE adaptor, on Promise's Secondary port, the voltage between pin 34 and GND,

Transcend: 0.78 V, which becomes GND once Promise firmware is loaded

Sandisk: 0.89 V, which becomes GND once Promise firmware is loaded

Lexar: 1.34 V, which becomes GND once Promise firmware is loaded

Curiously, with the Laxar CF card connected to Promise's Secondary port, it decides that it is UDMA 5 now. Sandisk also UDMA 5. This controller cannot make up its mind. I tried a different controller card, but the results were the same.

Should I pull-up pin 34 to 5V on the CF adaptor with 10K, even though it appears that the Promise controller is pulling pin 34 low once the firmware loads? Or maybe becausethe controller senses a low logic level, it decides to then pulls pin 34 low.

Alternately, can we hardcode UDMA 2 in firmware somehow? Firmware attached.

That's certainly curious. I would be concerned about the "disk error" with the proper speed mode set more so than the flaky detection without a cable in the mix.

I'm not too concerned that the Promise Ultra 100 card cannot boot to my 8 GB Lexar CF card when set to UDMA mode 5. It seems like the Promise card is goofing up on auto selection of UDMA speeds and this is the likely culprit. I was hoping to find a way to set UDMA speeds manually rather than rely on auto detection. The detection is flakey even with a cable in the mix - Transcend stayed at UDMA 5 with a 40-pin cable used. Swapping IDE ports changes things further.

You're using the normal FW, right?

Maybe you can try to flash the RAID one (IIRC, just a single resistor needs to be added to make the upgrade possible).

The ATA mode detection is likely the same, but still worth a try, given the time required and the cost are next to zero

Yes, I'm using the standard Promise firmware. Can the Promise RAID card work in non-RAID mode, which I think is called JBOD.

Are you referring to using the Promise FastTrak 100 TX2 BIOS? That card contains a PDC20270 chip, while my card contains a PDC20268 chip. If you are referring to using the Promise FastTrak 100 model, that chips contains a PDC20267. Which RAID card uses the PDC20268 chip?

What if I flash the BIOS and the card becomes unresponsive? The EEPROM chips are soldered on.

I decided to test several different types of modern CF cards in a late P3 system (Asus TUSL2-C) with onboard UltraDMA 100 support (mode 5). Using a cable-less CF-IDE adaptor, all CF cards get set to UDMA mode 2 by the BIOS, which is expected since an 80-pin cable isn't present. So, something is off with the detection algorithm or hardware on Promise Ultra 100 TX2 cards when it comes to using these CF adaptors.

It's hard to a answer in 2026 enshittified internet, and my memory is not that invincible.

But yest according to one of the few survived links I found the ultra 66 is moddable (to fast trak66)

https://arstechnica.com/civis/threads/promise … -to-use.968793/

P.S. possibly isn't even protected and no pull-up / pull-down resistor is needed

For the details I'm afraid you have to dig in archive.org

What if I flash the BIOS and the card becomes unresponsive? The EEPROM chips are soldered on.

Assuming you have the correct bios there are two options

1)the card is a recent revision, then requires the electrical mod, in that case, no mod=no flash.

2)the card is not protected, then you can flash at your liking, and the card will work

Perhaps it isn't a PC, it's a card.
Under windows the card works even w/o any bios at all, the bios extension is needed to be bootable and to configure boot order and raid configuration.

The pin detection is not the only thing that determines what speed is set. The pin detect is a quick pass/fail which determines whether speeds above 33 are allowed, but the targets still negotiate the maximum speed with the controller.

That is to say, if the card is negotiating UDMA 5, it should work at UDMA 5. And the flaky pin detect behavior of the card is probably not the only problem here

maxtherabbit wrote on 2026-09-29, 13:00:

That is to say, if the card is negotiating UDMA 5, it should work at UDMA 5. And the flaky pin detect behavior of the card is probably not the only problem here

The right DMA speed/protocol plagued the Win95/win98 days.

Just open hdc.inf of any 2000+ windows to get the idea of how many corner cases are contemplated/blacklisted/tailored for a single specific device

And I guess the Linux kernel has a similar list, even if I never dug in that part of the kernel

Those blacklists/whitelists are the reason why the headaches of w9x days are mostly gone

The Solutor wrote on 2026-09-29, 15:03:

The right DMA speed/protocol plagued the Win95/win98 days. […]
Show full quote

maxtherabbit wrote on 2026-09-29, 13:00:

That is to say, if the card is negotiating UDMA 5, it should work at UDMA 5. And the flaky pin detect behavior of the card is probably not the only problem here

The right DMA speed/protocol plagued the Win95/win98 days.

Just open hdc.inf of any 2000+ windows to get the idea of how many corner cases are contemplated/blacklisted/tailored for a single specific device

And I guess the Linux kernel has a similar list, even if I never dug in that part of the kernel

Those blacklists/whitelists are the reason why the headaches of w9x days are mostly gone

Whether or not the storage driver for the OS behaves properly is a totally different issue from failing to even load the boot sector

maxtherabbit wrote on 2026-09-29, 15:07:

Whether or not the storage driver for the OS behaves properly is a totally different issue from failing to even load the boot sector

It's very likely the same issue, in the current case you just face it earlier

In light of the diagram I attached earlier, I decided to add a 10K resistor between 5V and IDE pin 34. The CF card was detected as UDMA 2, as hoped, but the output on pin 34 was still higher than desired (4.6 V). It looks like the PDC20268 chip on the Promise card runs at 3 V, so I was hoping to get pin 34's voltage closer to 3 V. Swapping the 10K resistor for a 33K resistor, brought the pin 34 voltage down to 3.2 V. This would imply that the resister to ground on the Promise card was around 66K.

Note that I am branching resistor off of a Schottky diode, which measured at 4.84 V (5.12 V - 0.28 V).

Now, any CF card I plug into the CF-IDE adaptor gets detected as UDMA 2, even the pesky Transcend Industrial card which kept running at UDMA 5, even with a 40-pin cable. So far, everything works fine with this resistor in place. I have not tested this in a dual-CF Master/Slave IDE adaptor because I wasn't sure if the CF cards have any communication on pin 34 in this configuration in Master/Slave config.

Benchmarks on the Transcend Industrial with UDMA 5 were identical to that when set to UDMA 2, that is, about 30,000 Kbyte/sec.

Here you can find the whole story (search the document for PDIAG- to find the relevant parts)

http://www.t13.org/Documents/UploadedDocument … ATA-ATAPI-6.pdf

feipoa wrote on 2026-09-30, 13:45:

Benchmarks on the Transcend Industrial with UDMA 5 were identical to that when set to UDMA 2, that is, about 30,000 Kbyte/sec.

That seems pretty close to the theoretical max for UDMA2. You probably are not going to get much better than that with UDMA2.

I got speeds a little faster out of my CF170 at UDMA5 on an NForce2, but it was only a 4GB device, so likely had different flash chips and maybe different limitations.

Re: Small capacity SSD PATA/SATA benchmarks