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.

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

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.

Thanks. I didn't know XT-IDE was even able to enable faster transfer modes. Perhaps there will be some updates to XT-IDE in the future which enable these faster modes. But couldn't we just use the Promise DOS driver?

I wanted to share some new Am5x86 results at ~180 MHz. There are some socket 5/7 boards which have a "boost" jumper. This allowed the FSB to run a few MHz higher than stocks FSB frequencies. Adopting this principle, I have replaced the clock generator on an M919 with a variable frequency unit and was able to determine the fastest FSB for a given set of [minimal] memory wait states. The PLL hack just barely fits between the ISA slots (photo below). It is a very tight squeeze.

I have been able to create one or two 1024K cache modules for the M919 which allow 2-1-2 L2 waits with 0/0 ws EDO waits at 62 MHz FSB. The result is a stable Am5x86 at 186 MHz. I tried for some time to get it stable at 189 MHz, but the system wasn't stable enough for me with 2-1-2, 0/0 ws.

I spent a few hours with various software titles in Windows 95. The system appears stable, but this was only with benchtop testing - I have not put this hardware combination into a case.

0/0 ws w/EDO is not obtainable with VLB graphics on the M919. I am needing to use a PCI Matrox G200 graphics card. I have several 1024K modules that I've assembled. Only select modules with ISSI TSOP 8 ns IC's are able to do 2-1-2, 0/0 ws at 180 MHz. 10 or 15 ns Cypress SOJ IC's wouldn't cut it. Also needed was a 50 ns, 64 MB, TSOP EDO stick of memory.

Unfortunately, since I am insistent that my cased Am5x86-180 system uses VLB graphics, this fast combination of hardware won't likely make it into a case. I may go for 186 MHz at 1/0 ws, but I feel like I'm already testing my luck with VLB at 60 MHz.

The good news is that most PCI socket 3 systems use a PLL clock generator of the same pinout, so this clock hack, or 'boost', will work on a large selection of motherboards.

I am at 22.1 fps in DOS Quake v1.06, which is identical to the fastest stable result pshipkov achieved at 180 MHz w/VLB. I know it's not clock-for-clock the same result, but close. Mine is ~180 MHz in boost mode :)

feipoa wrote on 2026-01-21, 14:11:

Thanks. I didn't know XT-IDE was even able to enable faster transfer modes. Perhaps there will be some updates to XT-IDE in the future which enable these faster modes. But couldn't we just use the Promise DOS driver?

You can certainly use the DOS driver if you are using DOS, yes. XUB is nice because it simplifies things in some ways. The speed selected by XUB appears to be storage dependent. Here is my survey of speedsys benchmarks for 2 promise cards over 4 storage devices using BIOS, XUB, and different driver settings ...

/D0:D8 is the fastest PIO
/D0:DA is using IOCHRDY. Getting reliable IORDY in the VLB age isn't straightforward, and seems like it is necessary for reliable data transfers at the faster PIO modes.
/D0:M8 is the fastest 20630 "MWDMA to the controller" mode

Notes:

• I used the Promise VG4 v3.3 driver -- "VG4" is the code name for the 20630, but the driver seems to work fine with the "VG3", aka PDC 20230, aka "Turbo Chip C"
• Controller #1: https://theretroweb.com/expansioncards/s/promise-dc2300a
• Controller #2: https://theretroweb.com/expansioncards/s/siig … d-ide-master-vl (mistakenly marked as HLC-6000VL, but I did use the SIIG card)
• Motherboard: https://theretroweb.com/motherboards/s/edom-wintech-mv008 w/ AMD 486dx-133