I'm unable to give up DOS CD-ROM access. It's too inconvenient for those later games with disc checking.

To be clear, I'm not overclocking the UMC IDE controller. I am running it at 33 MHz. If it's run at even 40 MHz, the UMC DOS driver won't load w/Cyrix 5x86.

It would be interesting to see if CF cards supporting block mode, or multi-sector transfers, suffer the same fate on the UMC IDE controller. So far, I haven't run across such a CF card, but Mouser sells them for around $300 for an 8 GB card. Other than seek, late era mechanical HDDs, usually from about 2006 or later, offer similar or slightly better throughput to CF cards. There are USB 3.0 to IDE adaptors available now which would make cloning more convenient. I'm using a USB 2.0 to IDE adaptor now and its way too slow for cloning with dd.

I picked up a handful of 8gb innodisk iCF 4000’s on the cheap that support max block transfer size of 2. Enabling block transfer modes showed no real improvement in ISA or VLB for them . As a warning, the CF’s are so slow on PIO work loads that they are unpleasant to use. They had locked copies of Win XP imbedded installed on them with some sort of industrial app so the look like they are legit. With UDMA, they can rise to the level of “slightly disappointing”.

douglar wrote on 2025-11-13, 00:07:

I picked up a handful of 8gb innodisk iCF 4000’s on the cheap that support max block transfer size of 2. Enabling block transfer modes showed no real improvement in ISA or VLB for them . As a warning, the CF’s are so slow on PIO work loads that they are unpleasant to use. They had locked copies of Win XP imbedded installed on them with some sort of industrial app so the look like they are legit. With UDMA, they can rise to the level of “slightly disappointing”.

Do we have any idea how the Innodisk iCF 4000's compares to the Innodisk iCF 1SE3 series? e.g. https://www.mouser.ca/ProductDetail/Innodisk/ … eKIw4x4vw%3D%3D

The spec sheet for the 1SE3 leaves much to be desired in terms of specifics, but it does list "max channels: 2", which I assume is the block size. If each sector is 512 bytes, then its only transferring 2x512 byte per interrupt. Typical harddrives do 16 or 32 sectors per I/O, and later models have 8+ MB of cache onboard.

For the case of the UUD w/onboard IDE and CF at 33 MHz, wouldn't the interrupt need to be triggered more often compared to a modern HDD with block mode? The selective crashing with DRAM at 1 ws is likely due to the memory controller and I/O subsystem not being able to cope with the frequency of interrupt requests, rather than the IDE being faulty, that is, since switching to 2 ws is flawless. .. or using 1 ws with DiamondMax 10 IDE, which is flawless.

I also never saw perf difference with multi-sector transfers or without it.
The way i see it, the CF card is vastly faster than what these old IDE controllers can handle, so they (the controllers) get saturated much earlier with single sector transfers, before other features (such as multi-sector transfers) become a factor.
With later (S)ATA controllers such features are on by default, so single/multi sector transfers cannot be tested individually.
Maybe there are later-enough generation of controllers/drivers where the hardware is fast enough to be able to show the difference and the driver allows selecting the feature.
Do you know such controllers?

Block transfer certainly lowers the frequency of individual calls, as data from multiple sectors get aggregated and moved around at once (single interrupt) instead of an interrupt per sector.
The fact that you have to increase DRAM wait states to 2, suggests that the system is not able to cope with the controller "stressing" the system ram with frequent reads/writes. At the same time if you are able to keep it at lower WSs without CD-ROM in the loop, then you have some specific condition that exposes the instability. Potentially optical device going bananas with per-sector transfers or other timing getting exceeded. I don't know - mostly speculating here.

Yes, the UMC 8881/8886 controllers cannot handle the timing stress at 1 ws w/frequent CF card single-sector interrupts and simultaneous CD-ROM access. I was hoping different CD-ROM drives might mitigate this issue some, but they did not. The primary take away message is that if anyone runs into similar issues, they may want to consider using late generation magnetic platter IDE drives rather than CF. You loose some random access timing on loads such as searches, e.g. scandisk, but can gain a DRAM wait state back.

A preferable solution may be to use a PCI IDE/CF controller card on, say, a Promise Ultra100 TX2, but keep the CD-ROM on the UM8886's IDE port (for DOS CD-ROM access). I'm tempted to try this combination if curiosity keeps gnawing at me. I run some Pentium era systems with this combination.

Anyone know if using a SATA SSD or SATA mechanical HDD connected to a SATA-to-IDE adaptor would allow for block mode?

feipoa wrote on 2025-11-14, 03:14:

Anyone know if using a SATA SSD or SATA mechanical HDD connected to a SATA-to-IDE adaptor would allow for block mode?

I think yes but ...

• Sata drives have many different firmware versions
• Sata-Pata bridges have different silicon and different build qualities
• PATA IDE controllers have an even larger spectrum of history

But my favorite tool for validating block mode, HWINFO16, isn't giving me any ATA info about drives behind bridges, which is frustrating. I tried marvell and jmicro bridges.

Any suggestions for which tool could give me that info for sata devices behind bridges?

Ya, the SATA-to-PATA bridges are all different. Maybe somebody here has bought a handful of brands and ran some comparisons for use with onboard 486 hardware. There's a few threads on here on this subject, but I decided to give up on this endeavour. I think the threads were mainly for newer systems, so might not align. This is only practical if you are using the onboard IDE, or a non-PCI motherboard. If you are using a PCI motherboard, you just as well use a PCI SATA card.

I have several JM20330 based bridges, which I normally use for turning a SATA CD-ROM drive into a PATA one. They work well. The JM20330 datasheet states that the adaptors work with HDDs. I performed a quick dd clone of an 8 GB CF card that I use on 486's. I cloned the CF to a Samsung 870 EVO SATA drive. Plugged it into the MB-8433UUD + bridge. The BIOS auto-detects drive geometry up to the 8 GB just fine. Tried to boot and got a bunch of garbage on the screen at POST. I don't recall if I tried it without block mode, but with block mode, there's some low level garbage on the screen. Gave up after this. Back to my magnetic drives + XT-IDE.

feipoa wrote on Yesterday, 04:48:

Ya, the SATA-to-PATA bridges are all different. Maybe somebody here has bought a handful of brands and ran some comparisons for use with onboard 486 hardware.

I made a bunch of these a couple years ago when someone sold me a sack full of 16GB Kingston SSD's for $20.

I paired them with a $2 M2-->Sata adapters and $3 Jmicron Sata-->Pata bridges and made some 3d printed chassis to hold it all together with 3.5" mounting holes.

I also tested a marvell bridge with a liteon NGFF SSD and it showed 16 sectors per interrupt.

Not all sata devices present block mode transfers > 1. My Samsung Evo840 didn't.

I'll put together a chart later--

That looks pretty slick. Did you try it on any 486 motherboard IDE controllers? Are you using the JM20330 SATA-to-PATA adaptor?