Yeah, the statement came out poetic and everything ( :} ), but joking aside - after reading your comment i was a bit stupefied, because it really didn't cross my mind that i can just underclock one of the CPUs.
Not far ago a 386 motherboard (unknown brand, model 386-VC-H) build around the VIA VT82C495/VT82C481 chipset got my attention.
The used 486 class chipset itself was worth checking from close-up, but there was something else that i wanted to understand - a second 80MHz crystal oscillator placed next to the FPU socket. That was unusual. Most often reference clock oscillators are 14.something MHz, but 80 ?!
An asynchronous 386 FPU "hack" - does not sound plausible, but couldn't find any information online about this piece of hardware, so decided to spend my own time to examine it.
Great layout in great condition.
All jumpers are documented on the PCB.
Takes DLC upgrades - used 50MHz rated SXL2 CPU.
Up to 286Kb L2 cache - used 15ns UMC ones, because it didn't like 12ns ISSI.
Tested with 16Mb 50ns RAM, but it looks like it can go up to 64Mb, or even more.
STB Nitro ().
Examination started without FPU - wanted to see how far i can go on the overclock.
Easily reached 60MHz in DOS interactive graphics. Board does not light past that (I know the CPU can take 65Mhz).
At 60 only very few video cards complied. Ended up using this 2Mb STB Nitro (Cirrus Logic CL-GD5434).
All BIOS settings on max, except DRAM wait = 1 (up from 0) and CACHE WRITE WAIT = 1 (up from 0).
Windows starts and works just fine, can complete WinTune2 benchmarks.
So far so good.
Time to move onto more rigorous testing (which requires FPU).
None of the Cyrix FasMath FPUs i have worked at 60MHz, but 40MHz rated ULSI took it for the team.
This was the most interesting part of the examination of the mobo - what is the purpose of the second crystal oscillator ?
Initially i quickly played with different oscillators - from 60 to 120 MHz and managed to fool myself that the FPU works asynchronously.
I was wowed for a moment, but after the initial excitement passed i quickly realized that it was just my unstructured approach to testing.
While a bit disappointed and back in Earth's orbit i was still ok with eventually having a system running natively at 60MHz ...
... until i ran the 3D rendering tests.
While there were no crashes the results were all garbled pixels - which was a good indication that all is not well with the system.
Lowered the BIOS settings to their most inflated wait states, but nothing changed.
Had to step down to 55MHz to get the expected results from the test computations.
SpeedSys hangs with the SXL2 CPU, so sharing the performance metrics only.
As you can see this board is significantly clock-to-clock slower than the DTK Symphony one that i use as the highest 386 watermark indication.
Even at 55MHz VIA is slower than the 50MHz Symphony. Difference is smaller when running VIA at 60MHz, but is (border line) not fully stable.
FPU running at 55MHz helps the PC Player Benchmarks and 3D Studio offline rendering tests, which are FPU heavy. Interestingly enough - LightWave3D which is the difficult tests to pass and very FPU intensive, didn't care much about the faster FPU.
I didn't get async 386 FPU system (which i kind of expected), but the board is actually really great - fully stable at 60MHz for everything, but the most challenging tests - it does not really crash, just produces incorrect results.
It is not a clock-to-clock performance beast, but the extra MHz compensate for that.