@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

As I have troubles to get my FX-3000-mainboard working with any 486-CPU (see this thread: FX-3000 motherboard thread), I started in the last days a little 386-project with it.

The CPU and the FPU are the fastest ones non-overclocked versions of 386/387: AMD 386DX-40 and Cyrix FasMath 387-40.
The RAM is 32 MB (8x 4 MB SIMM-RAM 30pin) (60 ns).
The onboard-cache is 256 KB (15 ns).

I was lucky to find an ISA-VGA with 2 MB VRAM (a Diamond Speedstar64). This exemplar here is able to work at an ISA-frequency of CPUCLK/3 in Windows for Workgroups 3.11, and at CPUCKL/2 in DOS - still having a CPU-frequency of 40 MHz! Maybe this is due to its "newer" age - it was made in 1996, this is very late for an ISA-VGA.
The trick is to remove Jumper 8 on it (it's number is shown as 1 in some online-manuals for this VGA), so to DISABLE the WS of 0. With JP8 closed, no Windows-boot was possible even at CPUCLK/6, /7 or /8 (freezes at the loading of the Calmira-desktop in WfW 3.11, see below)

The VGA-performance is maybe very close to a TsengLabs ET4000 (I have too, but it's not able to do CPUCLK/4, /3 or /2).

Today the project is finished, and there is a really crazy DOOM-result (timedemo 3) of about 9,14 FPS (8163 realtics) @ CPUCKL/2!
Not sure, but is this maybe a record for a 386@40 MHz...?

Using Calmira for WfW 3.11, the working with this Windows-version is much more comfortable (it "seems to be" optically more or less a Win95), see screen-shots.

The system is absolutely stable until now, after about 5 hours of testing.

next pics

next pics

next pics

And the last one pic.

By the way, as it can be seen, the GPU is a Cyrrus Logic CL-GD5434, and the used HDD as a Quantum Bigfoot of 4 GB (so a Disk Manager has to be used to obtain the full capacity; the BIOS-information of 10 MB for the HDD is wrong - this is due to the BIOS-Overlay by the Ontrack Disk Manager).
The 2 MB of VRAM are enough to have True color @ 800x600 dpi in WfW 3.11.

Other results:
Quake I 320dpi: 1,8 FPS
3dbench 1.0: 17,2
3dbench 1.0c: 16,9
PCPbench (vgamode): 4,1

Next update - an internal Iomega Zip-drive was added to the system above, so now there is a "Floppydrive F" in the file-manager.
With this ZIP-drive attached and recognized, at CPUCLK/2 the DVD-drive can not be recognized anymore even in DOS (without the ZIP-drive it is present).
So all components as well as WfW 3.11 with Calmira are working only at CPUCLK/3 pretty fine.

In DOS-only-mode, for CPUCLK/2, I did some more benchmarks: Checkit3, Norton Utilities 5 System Info, Syscheck 4.5, Landmark 2.0 and Landmark 6.0.
Because of the very high ISA-frequency, in combination with the GD5434-chipset, the VGA has a killer-performance for a 386-system 😀

Next pics

And the last pic

Looks legitimate. Thanks for sharing.
You can run this board at 50MHz easily and squeeze more juice out of the good hardware you got.

pshipkov wrote on 2026-01-30, 00:33:

Looks legitimate. Thanks for sharing.
You can run this board at 50MHz easily and squeeze more juice out of the good hardware you got.

To be honest, I already tried to overclock a 386 - sadly no success until now 🙁

Apart from the FX-3000-mainboard above, I tried the overclock with 4 other boards , too (see pictures):
- FIC 4386-VC-HD
- FIC 386SC Rev. A3
- 2x Shuttle HOT-317 in different Revisions (I think so; both in bad conditions because of corrosion near the battery-place)

Meanwhile I have 128 KB onboard-cache @ 12 ns, 4 MB (4x 1 MB) SIMM-RAM 30pin @ 50 ns, and (maybe most important) some crystal-oscillators doing 86 MHz and 90 MHz (= 43 MHz and 45 MHz CPU-frequency).

Sadly, under no conditions (even in slowest/lowest BIOS-timings for cache, RAM etc.) with no one of those mainboards, I am able to get any system with a 386DX-40 CPU booting at 43/45 MHz. No chance!
The onboard-cache and the RAM-sticks work pretty fine at 40 MHz CPU-frequency onto the same mainboards, so they are functional.
Also, I used some different 386DX-CPUs with both FIC-mainboards - again, no booting at 43/45 MHz....

So I ask myself, maybe the crystals are defective? Are they maybe any ideas how to test them before using? Do they maybe need another (a different one) voltage than 5 V to work properly?

Remove the FPU, this should get you to a better place. I remember this board didn't go past 45MHz with the FPU inserted.

pshipkov wrote on 2026-01-30, 17:59:

Remove the FPU, this should get you to a better place. I remember this board didn't go past 45MHz with the FPU inserted.

I already removed anything not necessary for booting for all the tests (no FPU, only VGA inserted, different 86/90 MHz oscillators from the same type I have here, different cache (12 or 15 ns) etc.).
No success.
So I wonder what's going wrong here...

Another thing I found out is about a VGA (maybe this is the wrong thread here, but anyway...) - a S3 P86C801 (V7 MIRAGE) ISA, having 1 MB VRAM onboard, with empty RAM-banks for another 1 MB (so having 2 MB in total). So I equipped this VGA to 2 MB and let it run under Win 95 in another (more modern) PC, and found out, that there is not possible to adjust 800x600dpi at True color. Only 800x600 dpi in High Color, or 1024x768 dpi in 16 color is possible. So in fact this VGA does not "benefit" from the second 1 MB installed - it acts like having only 1 MB in total.
In Speedsys 4.78, a total of 2 MB is shown, and the jumper for 2 MB is set correctly, too.
In the next step I found a Datasheet of the RAMDAC (it's one made by AT&T) - there is shown only True Color for 640x480 dpi (= 1 MB of VRAM).
Having a look at the inf-file in the VGA-driver for this VGA, there is nothing shown about 800x600x32 (but only for 800x600x16), so I really believe this VGA does not benefit from 2 MB VRAM in generally.
So I would ask if anyone else can confirm (or not) this particular problem, thanks.

Just for instance, this is the S3-801-VGA from my last reply. In those pictures, the second (extended) 1 MB VRAM is already removed, as it was not working / not active (even it was recognized by Speedsys 4.78).
Attached are the excerpts of the INF-file for the V7-MIRAGE and the Datasheet of the RAMDAC ATT20C491-11 (Link to the Datasheet: https://theretroweb.com/chip/documentation/at … 26592165716.pdf).
This VGA was initially intended for use with the 386-system from above, and finally replaced by the Diamond Speedstar64 because of the "really working" 2 MB VRAM of the Diamond.

It is puzzling indeed why you cannot get past 40mhz reliably. This generation UMC chipsets and the based on them motherboards dont overclock well, but 45 is just fine on them, so it may be a really unfortunate cpu.

Second megabyte of vram improves performance in Windows, does not add more video resolutions.

pshipkov wrote on 2026-01-31, 17:52:

It is puzzling indeed why you cannot get past 40mhz reliably. This generation UMC chipsets and the based on them motherboards dont overclock well, but 45 is just fine on them, so it may be a really unfortunate cpu.

Meanwhile I do not think, the tested CPUs are the problem - but the oscillators. So I wonder, if and how the oscillators themselfs can be tested (outside/apart from a mainboard).

pshipkov wrote on 2026-01-31, 17:52:

Second megabyte of vram improves performance in Windows, does not add more video resolutions.

Not more resolution is absolutely correct - but it adds more Colors (e.g. 800x600x16bit for 1 MB vs. 800x600x32bit for 2 MB). And this is the problem I meant: missing additional color-options for 2 MB compared to 1 MB.

Lots of oscillators passed through here. They all appear equal.
The only exception to the rule was a 386 motherboard pushed way beyond reasonable limits - running at 55MHz (110MHz oscillator), tightest wait states, 2x CPU multiplier. There i saw how from the several 110MHz oscillators only 1 or 2 enabled the system to operate stably. But that was an extreme-extreme case.
For what you are doing i will remotely-guarantee that you don't have an oscillator problem.
Probably the motherboard aged badly.