Oh, I forgot to mention that I tried a variety of IDE cables (long, short, single drive connector, 40-wire, and 80-wire). No difference.

'Sintechi' SD->IDE bridges do not correctly do LBA48!

They silently report that they can, and show disk capacities larger than 127gb, but then SIMPLY FAIL with data corruption when reading or writing past that.

Please do not use cards larger than 127gb in these adapters!

(I am assuming you have either a DDO or an XTIDE present in the system, that you are using with the SD adapter. These will want to use LBA48. The adapters are liars. They cannot properly use large cards. Do not partition past 127gb on them, ever.)

Generally, they also do not tolerate sharing the channel in most configurations.

I should have mentioned that I'm using 8GB and 16GB SD cards in the adapter (I've tried smaller ones as well with no change in behavior). I don't feel that I need much more capacity than that on a 386/486. The SD card brand doesn't seem to make any difference.

I have XTIDE as the Option ROM right now. I've also tried a DTC Enhanced BIOS and a SIIG Enhanced BIOS. No difference in behavior.

I intend to use the adapter in a single drive configuration. I just tried multiple configurations to attempt to troubleshoot the issue.

Ok.

Here's the skinny with SD->IDE adapters, as best i've learned from using them.

'Sintechi' based ones are 90+% of what's out there.

They do not do lba48.

they do not like sharing the channel (cannot be jumpered as master/slave, and cause strange problems if you force the issue. They need to be on their own channel with nothing else)

They have iffy DMA mode support. Generally just MWDMA-2 tops.

If used with a dual channel ide controller, they work fine. They can live on the primary channel all by themselves, and spinny disks and optical drives can be on the secondary.

If there is only a single channel though, I strongly suggest a CF->IDE instead. Those are much better at sharing.

Thanks. I'm running a dual channel system already (Primary IDE on an ISA Super I/O card and Secondary IDE on a separate ISA card). I intend to only have the SD-to-IDE adapter on the Primary IDE channel by itself and an optical drive on the Secondary IDE channel by itself. These ISA cards to not support DMA modes to my knowledge.

I'm not opposed to CF cards, per se, but I really don't want to deal with the cost and time of trying to find the right sort of CF cards for my system. I much prefer the lower cost and availability of SD cards. So, I'd like to figure out a way to get the SD-to-IDE working on my 386 since that's what I've got.

I don't have this problem on my 486, although that has a VLB-based IDE adapter.

The idiosyncrasies of the Sentechi adapters also don't explain the same behavior occurring with my 80GB Western Digital EIDE hard drive (which should fully conform, internally, to LBA addressing).

I do wonder if the issue lies with the PIO mode that these devices can use. Obviously, my ISA adapters can't handle the data throughput of higher PIO modes (I figure the ISA cards can handle data throughput of PIO Mode 2 at most). I don't know the operating modes on the SD-to-IDE adapter, but my WD EIDE hard drive only specifies PIO Mode 4 in its datasheet. My Seagate 40GB EIDE drive specifies all PIO Modes (0-4). Just a hunch, but I don't know if there's any way to command a SD-to-IDE adapter to operate in a particular PIO mode.

Quick question, what's your ISA speed? The main difference between 386 and 486DLC is of course the L1 cache which might result in code being run from L1, and back-to-back ISA bus transactions on 486, where 386 would always need to fetch code (unless it's a REP type string instruction). If the ISA is overclocked, has weak/degraded drivers, or the mobo is just poorly routed, it might just be enough to make it work on 386 with longer breaks between ISA bus cycles but not on 486 with back-to-back ones.

Deunan wrote on 2026-02-08, 21:26:

Quick question, what's your ISA speed? The main difference between 386 and 486DLC is of course the L1 cache which might result in code being run from L1, and back-to-back ISA bus transactions on 486, where 386 would always need to fetch code (unless it's a REP type string instruction). If the ISA is overclocked, has weak/degraded drivers, or the mobo is just poorly routed, it might just be enough to make it work on 386 with longer breaks between ISA bus cycles but not on 486 with back-to-back ones.

I've tested the ISA bus using BIOS-based clock dividers at speeds for 7 MHz, 8 MHz, 10 MHz, and 13 MHz. The issue persists regardless of the speed, but seems to occur slightly less often at higher bus frequencies.

I've also changed system wait states (both higher and lower) as well. Wait states seem to make no difference.

I also tested with the original 386 (no on-board L1 cache) on the motherboard, and it behaves the same. Same behavior when I disabled the cache (256k) on the motherboard. I don't think cache is the issue either.

I also don't understand why a fairly dumb IDE CD-ROM interface card (Future Domain IDE-16011) seems to function better with the SD-to-IDE than the more sophisticated Winbond or Acer IDE interfaces regardless of the ISA bus settings in the BIOS. They really should work about the same. I'm stumped.

There is a known incompatiblity between early IDE BIOSes (both the original IBM BIOS that was intended to target the WD1003 controller, which is emulated be IDE drives, and the AMI BIOS with B/W setup), which causes read timeouts if the drive responds too fast. The easiest workaround is to use a replacement IDE BIOS, for example the XT-IDE Universal IDE BIOS (XUB), installed on a ISA ROM card or in a boot rom socket on an IDE network card. The fact that you are facing the issue with anything but contemporary hard drives is a strong hint that you might experience this incompatibility/bug.

See my youtube comment https://www.youtube.com/watch?v=KHhEdgd7shk&l … tdwj976HOeF4qAL for the theory on what's happening here. You might also like to watch the video, as it is basically about your issue.

fosterwj03 wrote on 2026-02-08, 21:47:

also tested with the original 386 (no on-board L1 cache) on the motherboard, and it behaves the same.

Sorry, I've misunderstood. I though this problem was only affecting the 486DLC CPU. Could be an issue with XTIDE, what version/variant are you running? Try with shadowing disabled in case it's some sort of UMB corruption issue, this will obviously have a performance impact but for testing it should not matter much.

I think I found a solution to the problem I described above, but it doesn’t fully explain the root cause. The post above about “Sintechi” adapters (“Sintech” clones) got me thinking about how the modern SD-to-IDE adapters actually communicate over IDE vs the older Sintech design. That sent me down a bit of a rabbit hole, but I found a workable method to use SD cards with my 486DLC computer.

I eventually found a review of SD-to-CF adapters (2014) from a blogger: https://goughlui.com/2014/07/31/tested-two-se … sh-cf-adapters/

It looked like the reviewer might have had a working example of the “Sintech” CF card adapter. I decided to look around for an old, used SD-to-CF adapter in the hope of finding a “Sintech” model. Unfortunately, google searches tend to turn up brand new adapters that likely use the “Sintechi” design. I eventually found and bought this used SD-to-CF card adapter for $18 US (well loved, but unfortunately unbranded) to test some theories based on my research.

The SD-to-CF adapter I bought (I tested via a 44-pin CF-to-IDE adapter and a 44-pin-to-40 Pin IDE adapter) reports itself simply as a “Memory Card Adapter” during IDE initialization at boot (I think this means it uses the “Sintech” design). While the adapter’s label only lists SD and MMC cards, I did confirm it also correctly addresses SDHC cards (I don’t have any SDXC cards to test at the moment).

Unlike my newer hard drives and the “Sintechi” adapter, I can complete large copy batches (approximately 80 MB across over 2000 files) successfully using the SD-to-CF adapter on the Primary IDE channel in my 486DLC computer without read or write errors (it’s just slow on the ISA bus). Speedsys also has no issues completing HD tests using the adapter with a variety of SD cards. Oddly, Speedsys reports random access times ranging from 1ms to 12ms depending on the SD card (I even saw quite a bit of variance among SD cards from the same multi-card package). Regardless of the access time, the SD-to-CF cards all handled data on the 486DLC without issue (so far).

I don’t have a logic analyzer, so I can’t compare the signal difference between the “Sintechi” device I have and the SD-to-CF adapter I bought. I suspect there is some difference that explains the failures I experienced.

If anyone else has this issue, you might want to look out for very old SD-to-CF adapters. This seems to have worked for me. I specifically avoided any SD-to-CF adapter that listed Ultra DMA support because I think they might contain the “Sintechi” design, but I suspect finding the right sort of adapter might be like finding a needle in a haystack. I guess I got lucky.

Now I just need to figure out why OS/2 Warp and Win NT 3.1 (but not NT 3.51 or 4.0) randomly crash on this computer…