The video is from October: https://www.youtube.com/watch?v=jlQXS1VrFUQ

Not sure you quite appreciate just how much data feipoa has already produced in his own comparisons: The Ultimate 486 Benchmark Comparison 😀

I think the main reason the 3D Bench score is higher is because the graphics card is running at 40MHz. If you do tests that depend more on integer performance, the 133 will still pull ahead.

Anonymous Coward wrote:

I think the main reason the 3D Bench score is higher is because the graphics card is running at 40MHz. If you do tests that depend more on integer performance, the 133 will still pull ahead.

Good point! thanks!!

firage wrote:

The video is from October: https://www.youtube.com/watch?v=jlQXS1VrFUQ
Not sure you quite appreciate just how much data feipoa has already produced in his own comparisons: The Ultimate 486 Benchmark Comparison 😀

Oh yeah! I Totally went nuts like fruit flies on banana skins when I saw the Feipoa's post you mentioned! Indeed, in that very post he says he is sad of not having had the possibility of running tests at certain frequencies, that, if I recall, are exactly some of the frequencies that were run in the pages I linked, that's why I mentioned Feipoa! He'll be happy to crunch this new data too!
Thanks anyway for the link!

A 50mhz PCI bus is of course a limiting factor and you have to use a Matrox cards to get it working properly(NVidia ones can also handle it).
Also the cache has to be selected quite "thoughtfully". I have all 486s running in a 150@50 config and its the sweet spot when it comes to optimal 486 performance.

I tried 60mhz but there's no way getting it running optimally without using a custom cache solution.

amadeus777999 wrote:

A 50mhz PCI bus is of course a limiting factor and you have to use a Matrox cards to get it working properly(NVidia ones can also handle it).
Also the cache has to be selected quite "thoughtfully". I have all 486s running in a 150@50 config and its the sweet spot when it comes to optimal 486 performance.
I tried 60mhz but there's no way getting it running optimally without using a custom cache solution.

Wow! You sound very knowledgeable cache-wise!
What do you mean with "selected quite thoughtfully"?
And what do you mean with "custom cache solution"?

Thanks!

Just trial and error.

The problem with the cache is that they vary in quality even if labeled the same speed. So to have the cache working reliably at 50mhz, with the tightest timings, you have to find a good 15ns batch.

Above 50mhz the air is getting thin fast and I was not able to run the cache successfully even if I inserted all 12ns srams. The only thing left is using an SO28 to SDIP28 converter board and soldering on srams in SOJ format which are electrically compatible and available at faster speeds - 12 and 10ns. There are even 8ns ones if one searches long enough.

amadeus777999 wrote:

Just trial and error.

The problem with the cache is that they vary in quality even if labeled the same speed. So to have the cache working reliably at 50mhz, with the tightest timings, you have to find a good 15ns batch.

Above 50mhz the air is getting thin fast and I was not able to run the cache successfully even if I inserted all 12ns srams. The only thing left is using an SO28 to SDIP28 converter board and soldering on srams in SOJ format which are electrically compatible and available at faster speeds - 12 and 10ns. There are even 8ns ones if one searches long enough.

Wow man, I told you you were more knowledgeable about cache 🤣!
Thanks!

with the tightest timings

That's pretty much is the problem. "Tightest" timings for 486 is way out of 10-15ns SRAM specs, which work at 50-75mhz on a Pentium systems just fine. Same thing with EDO/FPM RAM.

That's a little bit of a mystery to me, actually. Seems like in theory SRAM rated for a 15 ns read/write cycle should work at 66 MHz with no wait states.

I guess the chipset might work them in some more complicated manner, because the SiS 471 chipset manual even provides a table of recommended cache latencies going down to 12 ns and that's not yet on the fastest 50 MHz settings available.

Before the first access the chipset has to check the tag RAM to see if the requested data actually exists in the cache. So that at least accounts for some of the additional latency.

I never could get the L2 to work reliably at 3-1-1-1 at 40MHz on my boards. But it worked at 3-2-2-2 at 60MHz, which would be the same number of total CPU cycles (18 cycles at either 40x3 or 60x2)

Considering that cache SRAMs apparently cost enough to make it worth producing boards with fake chips... I wonder why nobody made a board with dual-channel memory instead of L2 cache. Pentium boards used 72-pin SIMMs in pairs. A 486 board could have had two banks of DRAM with access alternating between them for a quicker burst timing.

I wonder why nobody made a board with dual-channel memory instead of L2 cache.

Uh...they did. It was called "memory interleaving". Not many of the PCI boards had it though, because it was expensive to implement, and by the time PCI came around 486 boards were for budget systems. I think the Intel Saturn chipset *may* have supported it, but don't quote me on that.

More importantly, during the PCI 486 era, the L2 caching schemes advanced to the point where they provided better performance than memory interleving. So it was both cheaper and faster.