@feipoa

Very cool. I guess you are officially opening the next chapter of retro-junk overclocking - FSB freq inbetweening.

As we touched on it before - this motherboard is the nicest space for ~180MHz but only if paired with 1024Kb L2 cache module that can handle the tight wait states. Remind me - how many chips you had to experiment with to get it 212 WS?

Totally understand your preference for VLB graphics card.

Any word on IDE controller - onboard or extension card?

Which pins are connected between the custom oscillator and the clockgen chip below?

What is the DOOM framerate?

---

@douglar

Thanks for the table and notes.

Why the XT-IDE BIOS results are inverted between the two controllers? What is the explanation?
Also, how exactly it simplifies things? It is not exactly clear from your notes.

@ douglar

From your table, it looks like the XT-IDE BIOS was able to bring the 20230C up to nearly the same speed as using a DOS driver. The XT-IDE BIOS slows the 20630C down by a hair. Is anyone still working on XT-IDE support for the 20630c (EIDE2300 plus)? Do we know the version of XT-IDE that started to have support for 230/630 controllers?

You mentioned using the VG4 driver version 3.3. Is there any benefit of this variant over the latest promise EIDE2300 version, that is, v3.31?

@pshipkov

pshipkov wrote on 2026-01-21, 23:05:

As we touched on it before - this motherboard is the nicest space for ~180MHz but only if paired with 1024Kb L2 cache module that can handle the tight wait states. Remind me - how many chips you had to experiment with to get it 212 WS?

I have 14 M919 cache modules currently assembled, with a plan to offer some to other VOGONs members when I'm finished with them. I still have a few more to assemble, but I'm out of resistor packs and 0603 100nF caps.

2-1-2, 0/0 ws doesn't just need a good SRAM module, but a well matched EDO stick. TSOPs all around work best. TSOP's at 50 ns, or often even at 60 ns, will prevail over 40 ns SOJ chips. So far, two SRAM sticks seem OK at 186 MHz, 2-1-2, 0/0 ws. I have another two sticks which can do only 180 MHz 2-1-2 0/0. I might test them for 183 MHz. Most of the sticks are pretty good. I have one module in my "3rd class" bin, for which I've written 160M 2-1-2 0/0, 180M, 3-2-3 0/0, 180M 2-2-2 0/0. It was odd that this 3rd class stick couldn't do 180M 3-1-3 0/0.

The May 1996 BIOS is best because it doesn't have that performance hit when a 64 MB module is installed.

For my "2nd class" bin, I didn't write the qualifications on the sticks and I forget what exactly they could do, but they are all SOJ 10-12 ns sticks. If I recall right, sticks which didn't do VLB 2-1-2 1/0 were put into "2nd class", meaning for VLB, they needed 2-1-2 1/0 (or was it 2/0? I forgot). There is no correlation between sticks which can do VLB 2-1-2 1/0 and those which can do PCI 2-1-2 0/0. I only have one magic stick which can do, both, 2-1-2 0/0 PCI and 2-1-2 1/0 VLB. Unfortunately, its one with tin contacts.

pshipkov wrote on 2026-01-21, 23:05:

Any word on IDE controller - onboard or extension card?

I am using the onboard IDE controller w/UMD8886BF driver v3.1. I'm using two 8 GB CF cards, connected on a single IDE-CF card reader (master/slave).

pshipkov wrote on 2026-01-21, 23:05:

Which pins are connected between the custom oscillator and the clockgen chip below?

Just 4 pins. Actually, one pin can be N/C, but you should solder it for structural support. The 4 pins just line up. However, you must cut off the FSB clock output pin from the original UM9515, isolate the stub, and ensure the custom clock gen pin can extend all the way down. Best to look at these photos: Re: Branch Prediction on the Cyrix 5x86 S1R3

pshipkov wrote on 2026-01-21, 23:05:

What is the DOOM framerate?

When the framerate gets over 50 fps, I tend to loose interest in the benchmarks. But, I ran them just now.
Doom timedemo 3, fullscreen w/health bar = 59.37 fps. Fullscreen w/out health bar = 55.53 fps. This is far lower than your results and is a symptom of running the PCI bus at only 31 MHz. For me, doing the FSB flip after POST was never an attractive option. I could get around this by using VLB, but then need to add a EDO read wait-state. As the frame rate is already very high in DOOM, this approach isn't very enticing to me. Quake scores, being much lower, are more interesting to optimise.

EDIT:
By contrast, using VLB with 2-1-2, 1/0 ws, at 180 MHz, we see DOOM at 75.1 fps (fullscreen without health bar) and 77.4 fps (fullscreen w/health bar). I bet if I ran a VLB at 186 MHz, it would be the top 486 performer in Quake.

I just thought of another note. On the UUD, the system will not crash in dos when you increment/decrement the FSB by 1 MHz. On the M919, the system will crash after you increment/decrement the FSB. In which case, you just reboot and the system will be using your incremented FSB. Use chkcpu to verify.

feipoa wrote on 2026-01-22, 06:05:

@ douglar
From your table, it looks like the XT-IDE BIOS was able to bring the 20230C up to nearly the same speed as using a DOS driver. The XT-IDE BIOS slows the 20630C down by a hair. Is anyone still working on XT-IDE support for the 20630c (EIDE2300 plus)? Do we know the version of XT-IDE that started to have support for 230/630 controllers?
You mentioned using the VG4 driver version 3.3. Is there any benefit of this variant over the latest promise EIDE2300 version, that is, v3.31?

I don’t know why XTide didn’t initialize Promise support for me on my 20630 card. I think it should have.

Looks like Version 587 was the first XUB with Promise support--
https://www.xtideuniversalbios.org/browser/xt … x30.asm?rev=587

Adding support for more controllers is something that I’d like to work on. Unfortunately, I haven’t written much x86 ASM since 1993, and that was all inline stuff in TurboC to make INT calls and screen writes. I was pretty close to fluent in 6502 ASM back in the '80's but that was a long time ago. I have successfully done a XUB "make" from the current source, so I’m making progress. That first step is often the hardest.

Pretty sure the v3.31& v3.3 promise driver bundles contain the same v3.3 DOS driver. I think the difference is whether the bundle was named after the Windows driver version or the DOS driver version. When I put stuff on Vogonsdrivers, I usually named things after the DOS version.

pshipkov wrote on 2026-01-21, 23:05:

@douglar Thanks for the table and notes. Why the XT-IDE BIOS results are inverted between the two controllers? What is the expla […]
Show full quote

@douglar
Thanks for the table and notes.
Why the XT-IDE BIOS results are inverted between the two controllers? What is the explanation?
Also, how exactly it simplifies things? It is not exactly clear from your notes.

I think things are simpler with XTide because I don’t have to worry about adding drivers to each build or worry about LBA support, that kind of thing.
Here’s my analysis of the chart—

Assumptions:

• “PIO” modes manifest themselves as rough performance ranges with speeds that vary based on the optimization of the INT13h code, features supported by the storage device, clock speeds used on the IDE cable, the number of Active & Recovery waits used by the controller, and the "if & how" of IORDY.
• “PIO0” is roughly 1.5-2.5 MB/s, assuming that INT13h is shadowed
• “PIO1” is 2.5-5 MB/s
• “PIO2” is 4-8 MB/s
• “PIO3” is 5.5-10 MB/s and should use IORDY to avoid data corruption
• “PIO4” is 5.5-12 MB/s and must use IORDY to avoid data corruption
• IORDY functionality depends on coordination between the storage device, the controller card, and the driver/BIOS
• Promise controllers support IORDY in hardware which is great, unlike some other controllers that rely on the driver to do IORDY through software, which is a mess. e.g. Works at 33 & 66, but fails at 133mhz because the driver expected certain 486 instructions to take a certain about of time, that kind of thing.
• IORDY makes things slower than the expected performance range if the storage device asserts IORDY often for long periods, but you can make a guess at the IDE cable frequency based on changes in latency.
• 20230 always fails on MWDMA modes because it doesn’t support them
• 20630 always fails on MWDMA mode with a jmicron bridge because the jmicron bridge doesn’t support it
• Promise controllers have their own strobe and don't use the VLB clock for ATA timing, which is a big improvement in reliability compared to many other controllers of the time.

Conclusions:

• My 20630 was not initialized by XUB. I should redo this test with different 20630 cards to see if it works with others.
• “PIO1” really isn’t used here. We are seeing PIO0, PIO2,and when there’s a latency drop, PIO3 & PIO4 and those two modes are pretty much indistinguishable using these controllers, devices & benchmarks
• The MRBios int13h code is slightly better optimized for this system than XUB
• The 20230 defaults to a slightly faster PIO0 than the 20630. Could be clock speed. Could that it uses different Active/Recovery waits
• /D0:DA jumps to higher frequencies (aka PIO mode) with the Xceed CF because it likes the IORDY signal, but it doesn’t improve transfer speeds because Xceed CF asserts IORDY in a way that results in lower throughput.
• XUB likes the fast consistent response times from the MSATA device
• The 20630 likes the MWDMA modes presented by CF devices and really likes MWDMA presented by the Sinitechi SD bridge
• Did I make a cut and paste error for the M8 CF tests? All of these values usually fluctuate by up to 5% from run to run so getting three identical values for two different storage devices is suspicious.
• The lower times with the /D0:DA switch on the 20230C deserves some investigation

Note-- Made some edits, added more assumptions and conclusions