Here is the result of the UMC Testing. Curiously, the UM82C871F with the manual timing settings got the fastest scores, even though it's older. I just did benchmarks, I didn't do any long term reliability tests to see if I could run at the selected speeds without corrupting the data.
The attachment Untitled.png is no longer available
Winbond W83759AF Config Utility with Source Code -- Anytime there is source code, it gets interesting
Looking in the source code I see only W83757AF mentioned. Not W83759AF. As far as I know those chips are not compatible so the source code will probably not work on a W83759AF.
Looking in the source code I see only W83757AF mentioned. Not W83759AF. As far as I know those chips are not compatible so the source code will probably not work on a W83759AF.
I saw a number of failures in my last set of benchmarks when I tried to push the IDE timing to the limit. I started researching what & why is going on when VLB IDE transfers go wrong and I found things I didn't expect.
I had always assumed that faster PIO modes were just faster PIO modes. It seems that it was pretty much true for PIO0-->PIO1-->PIO2 but beginning with PIO3 and definitely with PIO4, things changed. The ATA2 PIO modes have complicating factors.
Here's what I learned-- Please let me know if I'm off base here--
The timing for PIO3 on VLB is tight and for PIO4 it is very tight. Some VLB chips have internal strobes to generate their own PATA clocks. Some VLB chips have internal buffers. Chips with internal strobes & buffers tend to be more reliable as the timing gets tighter.
Sometimes faster 486 computers ( > 66Mhz ) have increased difficulty with faster PIO modes compared to slower 486 chips (<=66Mhz ) because the slower CPUs ran the driver code more slowly, and introduce extra waits that help when signals from an IDE device arrive little slow. When > 100 Mhz chips came out in 1994, not all systems that were validated at 33Mhz continued to work, because the CPU started sampling before the controller had the data ready.
A properly implemented IORDY (IOCHRDY) signal allows the faster CPUs to be reliable because it allows the IDE device to tell the controller that the data will be arriving a few ns late, but not all vendors implemented IORDY the same way.
Some VLB IDE controllers don't provide IORDY in a way that slower 486 CPUs can handle with 100% reliability, and in this edge case, the slower CPU's were less reliable. Perhaps this is why so many cards provide a way to disable IORDY.
The actual performance of PIO4 operation is very often only marginally better than PIO3 because the IDE device asserts a lot of IORDY waits or the driver is slower because of how IORDY was implemented.
As far as I know, all solid state storage expects a functioning IORDY, even though they are usually able to handle PIO3 without it. I guess there is a chance that cheap PATA-SATA bridges could fumble the IORDY signal.
Now trying to figure out which chip did what is harder, because there's not a lot of documentation.
Interesting stuff, I was always wondering why PIO mode 2 drives seem to behave nicer than "better" PIO mode 2 and 4 drives on high clocked VLB controllers.
Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.
douglarwrote on 2026-01-02, 13:58:Here is the result of the UMC Testing. Curiously, the UM82C871F with the manual timing settings got the fastest scores, even th […] Show full quote
Here is the result of the UMC Testing. Curiously, the UM82C871F with the manual timing settings got the fastest scores, even though it's older. I just did benchmarks, I didn't do any long term reliability tests to see if I could run at the selected speeds without corrupting the data.
The attachment Untitled.png is no longer available
Edit -- Looking through that source code, I see that author assumed that Speed 11 = PIO4. Didn't match my testing. Speed 11 matched PIO2 in my testing and according to the driver, speed 11 uses the smallest possible values in the timing registers: 1 / 1 / 0
I saw hints that there was a modded driver that allows PIO4. Not sure how to get there unless the dos driver I'm using has different values in it's speed table. Something to check out later today.
There's a couple of distributions that get referenced here and there. Let's call them VG4 and EIDE2300 (the filename of your actual download may differ). I took a closer look.
VG4\README.TXT is 14KB, lists a date of 1995/6/14 and says:
1 +================================================================+ 2 | EIDE2300plus Windows 95 MiniPort ATAPI Driver (Testing Only) | 3 +================================================================+ 4 5 This driver is a BETA version for Windows 95 PRE-RELEASE Final, not a final 6 release version. Promise Technology will release the final version 7 as soon as Microsoft releases Windows 95 Final version.
On the other hand:
EIDE2300\README.TXT file is 15KB, does not list a date, and says:
EIDE2300\WIN95\README.TXT from EIDE2300 is 6KB, has some more detail on installing the driver, and the caveat about being a BETA version is gone.
VG4\WIN95\PTIVGAPI.INF file names the device "Promise EIDE2300+ ATAPI IDE MiniPort Adapter PTIVGAPI", while
EIDE2300\WIN95\PTIVGAPI.INF names the device "Promise EIDE2300+ Enhance IDE Adapter"
Both .INF files have the same version number: "InfVersion=0.9". The actual driver file PTIVGAPI.MPD is identical between VG4 and EIDE2300.
Ok, so it looks like the BETA ended up becoming the final version. Nothing new, I think that was established earlier.
Then I was Waybacking around the Promise website and found some old filenames and defunct links, which led to a file called EIDEW95B.ZIP (attached).
EIDEW95B \PTIVGAPI.INF names the device "Promise EIDE2300+ Enhance IDE Adapter" just like EIDE2300, but:
EIDEW95B\PTIVGAPI.INF: InfVersion=1.0
EIDEW95B\PTIVGAPI.MPD is a hefty 42KB instead of the 23KB file from VG4 and EIDE2300.
The EIDEW95B\README.95 is 7KB and has some additions to the EIDE2300\WIN95\README.TXT, including this choice bit:
1 PROMISE EIDE2300plus Disk Controller Win95 Driver Readme file 2 3 Changes made - 4 1. Supports DMA mode transfers 5 2. Fixed bug where a CD-ROM disk change was not recognized 6 7 Notes on this driver - 8 9 1. The driver will automatically detect the drive(s) attached 10 to the controller and set up the respective speed setting 11 (for drives on the primary VESA channel only). There are no 12 manual speed settings for this driver. 13 14 2. Software eject and Autoplay does not work for CD-ROMs. (If you 15 wish to use these features, then use the Standard IDE/ESDI driver 16 for the controller that the CD-ROM is attached to).
I'm gonna play around with this one on my TMC PCI54PV Pentium VLB board.
It's been problematic with the VG4/EIDE2300 version of the Win95 driver, which seems limited to PIO 2 mode and led me to search around in the first place.
Anybody have experience with the 1.0 version of the driver? Is it any different/faster on regular 486 VLB systems?
The newer driver shows a noticeable improvement in Windows 98SE disk performance on this Pentium VLB system.
For lack of any installed proper Windows I/O benchmark I'm just using Speedsys here in a Win98 command prompt window.
As you can see in the pictures the score for the same 8GB Transcend Industrial CF card went up from 1853KB/s to 3368KB/s.
While that isn't as good as its DOS + EIDE2300.SYS /M0:8 score of about 7309KB/s, it's still well into VLB controller territory.
More importantly though, this driver has so far not shredded my C: drive.
Which is something the VG4 Win95 driver reliably does on this VLB motherboard after I installed a Pentium 200MMX.
The older driver did work fine with a Pentium 100, although it only got up to 2062KB/s.
It's hard to say what EIDE mode the Windows driver picks as it is automatic and no control is provided.
Amusingly, after this one warm boot it looks like the Windows settings stuck and the DOS driver would not override it (and JP4 was actually set to SPD 2 here).
That was just the once though, usually the DOS driver will set /M0:8 fine.
Beerfloatwrote on 2026-02-26, 04:59:The newer driver shows a noticeable improvement in Windows 98SE disk performance on this Pentium VLB system.
For lack of any ins […] Show full quote
The newer driver shows a noticeable improvement in Windows 98SE disk performance on this Pentium VLB system.
For lack of any installed proper Windows I/O benchmark I'm just using Speedsys here in a Win98 command prompt window.
As you can see in the pictures the score for the same 8GB Transcend Industrial CF card went up from 1853KB/s to 3368KB/s.
While that isn't as good as its DOS + EIDE2300.SYS /M0:8 score of about 7309KB/s, it's still well into VLB controller territory.
More importantly though, this driver has so far not shredded my C: drive.
Which is something the VG4 Win95 driver reliably does on this VLB motherboard after I installed a Pentium 200MMX.
The older driver did work fine with a Pentium 100, although it only got up to 2062KB/s.
It's hard to say what EIDE mode the Windows driver picks as it is automatic and no control is provided.
Amusingly, after this one warm boot it looks like the Windows settings stuck and the DOS driver would not override it (and JP4 was actually set to SPD 2 here).
That was just the once though, usually the DOS driver will set /M0:8 fine.
Digging through some old pages on archive.org, I learned that:
For the drivers, my understanding was that the VG4 driver was for OEM 20630 cards, while the EIDE 2300 driver was for Promise's own 20630 cards.
If you check out the links, you can see that:
20230C looks similar to the 20630 from a programming standpoint
The speed numbers 1-8 look like they are fed directly into the chip, they are not a reference to a lookup table used for software based timing.
On a lot of Win drivers from that period accepted the same parameters as the DOS driver. Have you tried looking for the driver in system.ini and adding parameters after the driver?
For the drivers, my understanding was that the VG4 driver was for OEM 20630 cards, while the EIDE 2300 driver was for Promise's own 20630 cards.
If you check out the links, you can see that:
20230C looks similar to the 20630 from a programming standpoint
The speed numbers 1-8 look like they are fed directly into the chip, they are not a reference to a lookup table used for software based timing.
On a lot of Win drivers from that period accepted the same parameters as the DOS driver. Have you tried looking for the driver in system.ini and adding parameters after the driver?
Interesting find, that. I don't believe I have any 20230 adapters but would be interested to see if b and c behave differently between these drivers.
But this being specifically about the Win95 driver, neither of them touch the system.ini (or win.ini) files at all. I don't think a manual entry works for .MPD drivers.
Meanwhile, now on the Spring Circle SF586 Socket 5 board instead of the TMC, a newly installed K6-III is taking the Promise VLB adapter with EIDEW95B driver to new heights.. (screenshot with Samsung SSD but the previously tested CF card is also fast)
But then at the same time the DOS driver on this config takes it up to more than 12000KB/s buffered and linear (using M0:8 or the highest speed mode with DMA for sure).
Beerfloatwrote on 2026-02-28, 10:16:Interesting find, that. I don't believe I have any 20230 adapters but would be interested to see if b and c behave differently b […] Show full quote
For the drivers, my understanding was that the VG4 driver was for OEM 20630 cards, while the EIDE 2300 driver was for Promise's own 20630 cards.
If you check out the links, you can see that:
20230C looks similar to the 20630 from a programming standpoint
The speed numbers 1-8 look like they are fed directly into the chip, they are not a reference to a lookup table used for software based timing.
On a lot of Win drivers from that period accepted the same parameters as the DOS driver. Have you tried looking for the driver in system.ini and adding parameters after the driver?
Interesting find, that. I don't believe I have any 20230 adapters but would be interested to see if b and c behave differently between these drivers.
But this being specifically about the Win95 driver, neither of them touch the system.ini (or win.ini) files at all. I don't think a manual entry works for .MPD drivers.
Meanwhile, now on the Spring Circle SF586 Socket 5 board instead of the TMC, a newly installed K6-III is taking the Promise VLB adapter with EIDEW95B driver to new heights.. (screenshot with Samsung SSD but the previously tested CF card is also fast)
But then at the same time the DOS driver on this config takes it up to more than 12000KB/s buffered and linear (using M0:8 or the highest speed mode with DMA for sure).
Ha! Is it stock or modified BIOS with K6-3 support?
Need help? Begin with photo and model of your hardware 😉
Ha! Is it stock or modified BIOS with K6-3 support?
It is stock, or really, the BIOS Jan modded for you with Y2K and HDD size fixes, and then a K6-halting instruction removed.
Runs like a bat out of hell like that and then gets faster still with the help of the K6INIT.
