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 2025-11-15, 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?

Never used that application. Can you explain the “transfer modes” section. I am not sure what to make out of it in the screenshot.

Also, i dont think such devices will make a difference for pre-y2k systems as cf-cards in some basic configuration saturate the controllers from that time, so strapping even faster hardware to the controllers will be meaningless.

The goal for my situation is to reduce stress on the system with fewer interrupt requests. The SSD screenshot showed that 16 sectors worth of data get transmitted per interrupt, whereas CF cards transfer only 1 sector worth of data per interrupt. The hope is that fringe stability situations become stable without adding wait states. It might, it might not. Can always revert to a magnetic HDD if it doesn't.

pshipkov wrote on 2025-11-16, 05:44:

Never used that application. Can you explain the “transfer modes” section. I am not sure what to make out of it in the screenshot.

Also, i dont think such devices will make a difference for pre-y2k systems as cf-cards in some basic configuration saturate the controllers from that time, so strapping even faster hardware to the controllers will be meaningless.

I created the report from HWinfo32 on an Nforce2 board running Windows 98 with the Kingston SSD on the secondary port. Looks like HW32 is reporting info from an ATA IDENTIFY DEVICE command (0xEC)

1Sectors PeSectors Per Interrupt:   Total: 16, Active: 16
2Max. PIO Transfer Mode:            4
3Multiword DMA Mode:                Total: 2, Active: –
4Singleword DMA Mode:               Total: –, Active: –
5Ultra-DMA Mode:  Total:            5 (ATA-100), Active: 5 (ATA-100)
6Native Command Queuing:            Not Supported
7TRIM Command:                      Supported (Indeterminate Read After TRIM)

I'm working on installing Win98 using the Kingston device on a 486 & XTIde Universal Bios r631. (I see that 632 came out last week)

I am using a promise 20230C based VLB controller. XUB identifies the device as block mode 16. Speedsys benchmarks it at ~9600KB/s. It all works well in real mode, but Win98 throws protection mode or stack faults when it tries to come up in protected mode after the first reboot during the install. I'll try a different motherboard.

EDIT: I'm having better luck with the SIS471 board https://theretroweb.com/motherboards/s/acer-vi15g (512KB Cache, 2.20 BIOS) than I was with the SIS495sx board https://theretroweb.com/motherboards/s/edom-wintech-mv008 (256KB Cache MR BIOS)

EDIT: more info about the device I'm using is here: Re: 3D print topic?

So my mistake earlier was that I tried to use HWInfo16 to look at ATA info. That doesn't work. I needed to use HWInfo 32 for Dos.

Here's the speedsys for the device in DOS. Transfer rates ~9600KB/s.

Here's the speedsys for the device under windows. Transfer rates ~6400KB/s. Looks like it dropped from PIO4 to PIO3.

And that's backed up by ATTO:

I wasn't able to find any tools yet that indicated if block mode was still enabled under windows.

Feipoa, right, you are trying to improve on your specific problem. I kind of forgot about that.

Douglar, while hwinfo16 didnt capture some ATA specifics, it provided the important info.
Looking at that info i am not sure if Block Transfer plays any role as the sysinfo metrics are kind intermediate. Clearly limited by the controller, regardless what the local storage device can do.
Now the only question is if any of this will resolve Feipoa’s problem. By the sound of it - this will take quite a bit of trial and error to find some potentially narrow config that works.
Edit: I guess the more important question is if optical drives handle BTs with such ide controllers. I think they are the actual culprit for Feipoa.

Douglar was using a SiS 471 at only 3x33 MHz. For that case, I think his DOS results are OK.

Does the Promise 20230C VLB controller support multiword DMA? The reduction in speed from DOS to Windows implies to me that it's not optimally configured in Windows. I would be interested to see if your SSD assembly works on the 8433UUD and what kind of results you get with the UMC v3.1 drivers (UM8673.SYS /D0:16 /F0 /MM0). For Windows, you'd need to use the jakethompson's.

With a magnetic drive (16 sectors transfers), I get about 14,000 KB/s in both DOS and Windows (33 MHz FSB). It would be nice if we could get 16-sector transfers out of some kind of SSD on a 486.

feipoa wrote on 2025-11-17, 08:17:

Douglar was using a SiS 471 at only 3x33 MHz. For that case, I think his DOS results are OK.

Does the Promise 20230C VLB controller support multiword DMA?

The 20230c does not do MWDMA. The only vlb controller from any vendor that sort of does MWDMA is the promise 20630 but there are 3 important caveats. 1) It can do MWDMA from the storage device to the controller, but from the controller to main memory it is not DMA, just faster PIO. 2) There are storage devices that do MWDMA on a PIIX but crash the 20630 driver, and 3) XTIde universal bios doesn’t enable faster transfer modes on the 20630 like it does with the 20230c.