I can confirm the poor memory throughput.

Got that same board running a 486DX2-50 with 4x4mb RAM.

I also just upgraded from 128kb to 256kb cache.

Just been running some quick tests so far, but here's an output of cachechk with cache enabled.

I will repeat the test tomorrow with cache disabled. Let's see if I can confirm that behavior.

maxxis486 wrote on 2023-04-01, 23:07:

I can confirm the poor memory throughput.

I know VIA had its hits and misses on socket 7, 370, and slot 1, but I wasn't expecting such a poor showing on a basic 486. This is why I picked up this board though - I wanted to see how VIA compares. I also like the look of it, with the blue overdrive-ready socket. It's one that (physically) embodies what as 486 platform was, besides the oddly low memory bandwidth. Seems it may not be worthy of a PODP5V83.

I repeated cachechk with different cache BIOS settings.

Here are the results:

With L1 and L2 cache enabled:

With L2 cache disabled in BIOS:

With L1 and L2 cache disabled im BIOS:

I found this from a few years ago Re: More 486 L2 cache troubles - timing sometimes so slow that cache isn't worth it?

Yeah, it just seems that this board/BIOS won't be the best for performance. Even the Pentium Overdrive doesn't do the best here.

Disabling auto-config in the advanced bios settings helps a little, but it still has abysmal memory performance when L2 is enabled. Nothing else in the settings has any positive impact on performance. There are a few disabled/hidden BIOS settings available in AMISETUP, but they don't appear to have an impact when changed.

I agree that the FIC/VIA 486 motherboards are quite the lookers. It's too bad they're usually steaming piles.
Maybe polishing a turd was part of the marketing strategy.

What a weird company.
I once heard that there was a strong Christian influence in the company philosophy, but when you see stuff like "VIA GRAphics" it makes you wonder.

Well, I guess it's not so bad then that I used that board for my very first attempt on modding that infamous Dallas module.
It sure ain't pretty now, since I chose to do it with the module still on board, haha 😀

Im having a very similar problem with this board: https://theretroweb.com/motherboards/s/asus-i … -486sv2-rev-3-1

The 486-66 runs like a poorly tuned 33mhz cpu and it all seems to be related to memory performance. The board is based on a SiS 85C461 chipset. All the jumpers look good.

Two strange thing stands out :
1) the L2 cache on my board is a mix of 20ns and 25ns chips.
2) the main memory is a mixed bank of simms.

Which is the most likely culprit?

douglar wrote on 2024-01-26, 18:21:

Which is the most likely culprit?

First I would check the turbo switch header. In ASUS boards you usually need to short those in order to run at full speed.

Otherwise I would probably blame the AMI BIOS. By analyzing the BIOS of several SiS471 based boards I found that it does not program the chipset registers correctly for setting memory/cache timings. I'm still not sure if it was done on purpose, but for example I managed to fix it on one of my boards by patching the BIOS.

In your case it's probably the same cause, considering the core for the SiS471 chipset is heavily based on its predecessors, the SiS460 and SiS461. Later on I'll try to post a link to the thread where I documented these findings.

I seem to remember a thread here on Vogons about cache mod where adding ?bigger TAG ram? to store some ?dirty? bit fixed bad main ram speed with L2 enabled? Maybe someone will know what Im babbling about 😀

rasz_pl wrote on 2024-01-26, 22:24:

I seem to remember a thread here on Vogons about cache mod where adding ?bigger TAG ram? to store some ?dirty? bit fixed bad main ram speed with L2 enabled? Maybe someone will know what Im babbling about 😀

This makes sense to me. Several 486 boards/chipsets had cacheable area problems. Often increasing the cache/decreasing ram fixed the drop in ram throughput when L2 was present. Back in the day many referred to it as a bug. ACC Micro chipsets in Packard Bells often had this problem.

kingcake wrote on 2024-01-26, 23:48:

rasz_pl wrote on 2024-01-26, 22:24:

I seem to remember a thread here on Vogons about cache mod where adding ?bigger TAG ram? to store some ?dirty? bit fixed bad main ram speed with L2 enabled? Maybe someone will know what Im babbling about 😀

This makes sense to me. Several 486 boards/chipsets had cacheable area problems. Often increasing the cache/decreasing ram fixed the drop in ram throughput when L2 was present. Back in the day many referred to it as a bug. ACC Micro chipsets in Packard Bells often had this problem.

Worth a try. I have rows of tested-good IS61C1024 chips now days to use in motherboards. And a few dozen bad ones.

A proper 486 has 256KB of L2 imo, but increasing it is a good test.

16MB of RAM isn't a lot for my own testing of the FIC board though.

TheMobRules wrote on 2024-01-26, 22:13:

First I would check the turbo switch header. In ASUS boards you usually need to short those in order to run at full speed. […]
Show full quote

douglar wrote on 2024-01-26, 18:21:

Which is the most likely culprit?

First I would check the turbo switch header. In ASUS boards you usually need to short those in order to run at full speed.

Otherwise I would probably blame the AMI BIOS. By analyzing the BIOS of several SiS471 based boards I found that it does not program the chipset registers correctly for setting memory/cache timings. I'm still not sure if it was done on purpose, but for example I managed to fix it on one of my boards by patching the BIOS.

In your case it's probably the same cause, considering the core for the SiS471 chipset is heavily based on its predecessors, the SiS460 and SiS461. Later on I'll try to post a link to the thread where I documented these findings.

I tried disabling the L2 cache and that slowed it down even more, so I think this is a different issue than the OP in this thread.

I'll check the turbo switch in the morning. I tried setting the board to 40Mhz FSB and that improved things so that it ran with the performance of a 33Mhz CPU. The fact that I got it to run at all at that speed with a 5v DX2-66 CPU makes me think that it could be running at a reduced clock speed, so you might be onto something with the turbo switch

kingcake wrote on 2024-01-26, 23:48:

rasz_pl wrote on 2024-01-26, 22:24:

I seem to remember a thread here on Vogons about cache mod where adding ?bigger TAG ram? to store some ?dirty? bit fixed bad main ram speed with L2 enabled? Maybe someone will know what Im babbling about 😀

This makes sense to me. Several 486 boards/chipsets had cacheable area problems. Often increasing the cache/decreasing ram fixed the drop in ram throughput when L2 was present.

no that one, let me search .. there it is: More 486 L2 cache troubles - timing sometimes so slow that cache isn't worth it?

jakethompson1 wrote on 2020-07-19, 21:51:

With L2 disabled, CACHECHK reports 16 us/KB up to 8 KB (L1) cache, and 22 us/KB for all bigger sizes.
With L2 enabled, CACHECHK reports 16 us/KB up to 8KB, 20 us/KB from 16 to 256 KB, and 37 us/KB on anything bigger. So I'd be trading 10% faster for things in the cache for an added 68% miss penalty on anything not in the cache. Ouch!

sounds pretty similar!

and as always fantastic @mkarcher comes to the rescue with explanation:

mkarcher wrote on 2020-07-20, 05:38:

The abysmal RAM read performance with cache enabled sounds like your board operates L2 in write-back with an "always dirty" strategy. This strategy is known to be worse than write-through in most situations. A L2 cache in write-back mode can have contents that are not yet in RAM. On cache miss, the RAM needs to be updated if the L2 cache line that gets ejected has data that is not yet in RAM. This takes some time. Usually, the chipset has a single bit per cache line indicating the clean/dirty state of the cache line. Old chipsets required a separate dirty tag chip to store the dirty bit, whereas newer chipsets can (optionally) use one of the 8 data bits from the tag chip as dirty bit. You can run in write-back mode without a dirty bit, but in that case, the chipset has to assume the data is dirty on every cache miss, and needs to have the processor wait for data during the often unnecessary write-back process.

Look for an option called "tag bits: 7+1"/"tag bits: 8" or "combine tag+dirty" in AMISETUP and set it to 7+1 (7 actual tag bits, 1 dirty bit) or combine:enabled. If you don't have an option like that, try to set the L2 cache in write-through mode. Read performance of main RAM with L2 disabled should not be considerably faster than with L2 enabled and a cache miss.

saga continues in 486 cache/ram speed issue with write-back with successful bios mod enabling L2 WT mode and WB with 7+1 reclaiming lost ram speed
How to set Asus VL/I-486SV2GX4 (SiS471) into L2:Write-through mode? another one with bios mod for L2 WT
I still cant find the thread where someone whipped out his soldering iron and soldered additional TAG SRAM chip to the chipset legs.

It was the asus turbo switch . My problem went away once I jumpered the turbo switch.

douglar wrote on 2024-01-27, 02:56:

It was the asus turbo switch . My problem went away once I jumpered the turbo switch.

😀 I think in 486 generation Turbo periodically flushes L1 cache, this is way worse than just disabling L1 cache because CPU is busy writing that 8KB back to ram all the time.
"Turbo in a retro PC - explanation and repair." - Necroware https://www.youtube.com/watch?v=i9DTA81xUN0

rasz_pl wrote on 2024-01-27, 03:43:

douglar wrote on 2024-01-27, 02:56:

It was the asus turbo switch . My problem went away once I jumpered the turbo switch.

😀 I think in 486 generation Turbo periodically flushes L1 cache, this is way worse than just disabling L1 cache because CPU is busy writing that 8KB back to ram all the time.
"Turbo in a retro PC - explanation and repair." - Necroware https://www.youtube.com/watch?v=i9DTA81xUN0

Could be. There was funky divot that consistantly showed at the 7KB spoton the l1 step of the cache memory graph while the turbo switch wasn’t jumpered.