Not sure if the TAG RAM will be accepted by the chipset the way you populated it.
You should try with a 64K chip instead.

What you did is supposed to work. You shouldn't need to get an 8K tag chip, the 32K chip should do just fine, if you make sure A13 and A14 are held at a constant level, either VDD or GND. That's what the two jumpers are for. Put them into the 1-2 position for 128KB cache and put them into the 2-3 position for 512KB cache. Pin 31 at the data sockets is supposed to be HA18, so the two jumpers are forwarding HA17 and HA18 (front side bus address bits) to the tag RAM in case of 512KB cache, and degrade the tag RAM to 8K x 8 in case of 128KB cache.

If the BIOS displays 128KB cache enabled only if cache is installed, the cache is supposed to work in DOS. Make sure you have "External cache: Enabled" in the Advanced BIOS Setup, but most BIOSes don't even display the cache size if you disable the L2 cache. If you don't have an option to disable or enable the L2 cache and "128KB cache" is also displayed if no cache is installed, you have a BIOS that fakes cache presence. To not make the consumer notice that the cache is missing, those kind of BIOS vesions have the L2 enable option hidden and fixed to "disabled", but they report a fake cache size anyway.

mkarcher wrote on 2022-10-01, 16:09:

What you did is supposed to work. You shouldn't need to get an 8K tag chip, the 32K chip should do just fine, if you make sure A13 and A14 are held at a constant level, either VDD or GND. That's what the two jumpers are for. Put them into the 1-2 position for 128KB cache and put them into the 2-3 position for 512KB cache. Pin 31 at the data sockets is supposed to be HA18, so the two jumpers are forwarding HA17 and HA18 (front side bus address bits) to the tag RAM in case of 512KB cache, and degrade the tag RAM to 8K x 8 in case of 128KB cache.

If the BIOS displays 128KB cache enabled only if cache is installed, the cache is supposed to work in DOS. Make sure you have "External cache: Enabled" in the Advanced BIOS Setup, but most BIOSes don't even display the cache size if you disable the L2 cache. If you don't have an option to disable or enable the L2 cache and "128KB cache" is also displayed if no cache is installed, you have a BIOS that fakes cache presence. To not make the consumer notice that the cache is missing, those kind of BIOS vesions have the L2 enable option hidden and fixed to "disabled", but they report a fake cache size anyway.

I see, that's a great info! Yes, on the BIOS setting, I can clearly see this "External Cache: Enable/Disable" option inside.
If I disable it, as usual it's saying "Disabled" in the System Configurations box provided.
If I enable it, it says "128K".
Without the chips installed and enabling it, it says "None".
On a wrong jumper setting, especially when I move the TAG SRAM jumper to another position like 2-3, it'll freeze on the System Configurations box, cursor staying at the Cache Memory section. I suspect the firmware checks for the cache memory to see if it's okay or not.

Unfortunately, even when I enable this External Cache setting, the L2 cache is still not detected in the CacheChk, and the other Dosbench apps are showing very low benchmark values (I'm not going to even try Quake for now until this is fixed). The turbo switch is also on throughout the benchmarks.

UncleYong wrote on 2022-10-02, 02:22:

I see, that's a great info! Yes, on the BIOS setting, I can clearly see this "External Cache: Enable/Disable" option inside. If […]
Show full quote

I see, that's a great info! Yes, on the BIOS setting, I can clearly see this "External Cache: Enable/Disable" option inside.
If I disable it, as usual it's saying "Disabled" in the System Configurations box provided.
If I enable it, it says "128K".
Without the chips installed and enabling it, it says "None".

This clearly shows that the BIOS recognizes the cache and it is at least basically working as it should.

UncleYong wrote on 2022-10-02, 02:22:

On a wrong jumper setting, especially when I move the TAG SRAM jumper to another position like 2-3, it'll freeze on the System Configurations box, cursor staying at the Cache Memory section.

That's again a good sign and sounds like L2 cache is getting used at that point. I guess it's coincidence the crash happens at the cache memory label. Standard 486 BIOSes enable L2 cache when the POST is complete, that is when the BIOS is about to write the system configuration box. If you only have 128KB cache, but the BIOS programmed the chipset for 512KB cache, or the tag RAM is not completely initialized (only 8K initialized, but more address lines connected), a crash soon after the cache has been enabled is expected.

UncleYong wrote on 2022-10-02, 02:22:

The turbo switch is also on throughout the benchmarks.

That's actually a very good point! Some 486 boards implement "turbo off" by forcefully disabling L2 cache ("always miss mode"). It's also not standardized whether Turbo pins closed means "turbo" or "de-turbo". In case of the SiS 496/7 chipset, though, deturbo is implemented by blocking the frontside bus 25% or 50% of the time, not by blocking the L2 cache, so we can scrap this idea.

So we observe that the cache seems to be theoretically working, but the board fails to recognize hits in practice. If you had a problem with the data chips, the cache would either not be recognized or the system would crash due to bad data. Constant misses can be caused by issues with the tag chip, or the traces connecting the tag chip to the chipset. There are traces connecting the data bits 0 to 7 of the TAG RAM to pins TA0..TA7 on the SiS 496. The easiest way to test these traces is to remove the tag RAM chip, put a meter on "diode check", red wire to tag GND (pin 14), and probe the data pins (11-13, 15-19) with the black wire. This will probe the clamping diodes in the SiS 496 chips through the traces on the board. If a trace is damage, you will get "open circuit" on the meter. If the traces are OK, you will get something between 0.5 and 0.8 V.

Hi mkarcher, once again, thanks for the input! 😁

So we observe that the cache seems to be theoretically working, but the board fails to recognize hits in practice. If you had a problem with the data chips, the cache would either not be recognized or the system would crash due to bad data. Constant misses can be caused by issues with the tag chip, or the traces connecting the tag chip to the chipset. There are traces connecting the data bits 0 to 7 of the TAG RAM to pins TA0..TA7 on the SiS 496. The easiest way to test these traces is to remove the tag RAM chip, put a meter on "diode check", red wire to tag GND (pin 14), and probe the data pins (11-13, 15-19) with the black wire. This will probe the clamping diodes in the SiS 496 chips through the traces on the board. If a trace is damage, you will get "open circuit" on the meter. If the traces are OK, you will get something between 0.5 and 0.8 V.

I vacated the Tag socket and "diode-checked" as you mentioned on these pins and they are all 0.71V. On continuity check they are actually connected to the SIS '496 chipset.

With the tag, I also intentionally switched one of the jumper to 2-3 near the cache SRAM that couples it to the vacant pin 31 at the cache SRAM chips - the system gets past through it, but it just would crash in the Speedsys (random numbers with invalid opcode and big block 8x8 letters), or crashes in Doom with also invalid opcodes. It is suspected that the cache is being used there as it tries to access the empty area.

When I took out the Tag and left it empty there, the benchmark results are identical. The system still could get past the boot stage and the SRAM is reported correctly. I'm suspecting the Tag SRAM isn't working on it and I swapped every each SRAMs (all of them are UMC UM61256FK-15) and it made no difference.

I'm not sure if the Tag needs to be a different brand or maybe a lower value (12ns?) is needed. Meanwhile I will try to get a couple of different ones and get the 128 kilobytes SRAMs to have a total of 512K here.

UncleYong wrote on 2022-10-02, 13:33:

When I took out the Tag and left it empty there, the benchmark results are identical. The system still could get past the boot stage and the SRAM is reported correctly. I'm suspecting the Tag SRAM isn't working on it and I swapped every each SRAMs (all of them are UMC UM61256FK-15) and it made no difference.

So we can be quite sure that the Tag SRAM chip is OK. The Tag SRAM interface might well be broken, though. It seems the chipset has a "cache size detection mode" that works independent of the Tag SRAM, which is confirmed by the data sheet: The chipset has an "always hit" mode that is recommended for cache sizing.

Hardware troubleshooting: You should be able to find continuity from tag address pins to data address pins for all tag address bits (unless interrupted by the cache size jumpers, as you already found out). /WE of the tag RAM needs to be connected to pin 136 of the SiS496, /CE and /OE of the tag RAM likely are permanently grounded.

Software troubleshooting: Check the BIOS settings that you did not accidentally enable a non-cachable area over the whole memory.

So we can be quite sure that the Tag SRAM chip is OK. The Tag SRAM interface might well be broken, though. It seems the chipset has a "cache size detection mode" that works independent of the Tag SRAM, which is confirmed by the data sheet: The chipset has an "always hit" mode that is recommended for cache sizing.

Yes, I might be suspecting other problems, like the chipset not functioning well, or possibly the firmware does not try to initialize it correctly.

Hardware troubleshooting: You should be able to find continuity from tag address pins to data address pins for all tag address bits (unless interrupted by the cache size jumpers, as you already found out). /WE of the tag RAM needs to be connected to pin 136 of the SiS496, /CE and /OE of the tag RAM likely are permanently grounded.

The continuities are checked - these Tag addresses are all connected to the chipset, and these /WE are connected too. /CE and /OE are grounded too. I am double (and triple) checking this again later.

Software troubleshooting: Check the BIOS settings that you did not accidentally enable a non-cachable area over the whole memory.

I tried searching for that "non-cacheable" option - the BIOS features and Chipset features setup is not showing these options, or I might have overlooked something:

I'll keep probing around the board if I have more time on it. 😁

UncleYong wrote on 2022-10-02, 15:32:

I tried searching for that "non-cacheable" option - the BIOS features and Chipset features setup is not showing these options, or I might have overlooked something:

You are right, no "non-cachable areas" are enterable in your setup. Possibly those are hidden options that can still be affected by "Load power-on defaults" and "Load BIOS defaults". "Power-on defaults" are very safe values that are used to get the POST up and running and allow proper configuration later. "BIOS defaults" are reasonably performant settings that will work on typical system configurations. You might want to load "BIOS defaults" and then reconfigure the most important settings.

Another point to notice: If the displayed values for the "auto-configuration" are what the BIOS actually does, having "LBD sample point" at T2 actively hurts ISA bus performance. I recommend you to turn off auto-configuration even if just for this setting (the other value will be T1). You risk compatibility issues with VL cards at high FSB speeds when you switch to T1, but after looking at your board photo, I'm quite confident you are not going to install VL cards into that board 😉

"BIOS defaults" are reasonably performant settings that will work on typical system configurations. You might want to load "BIOS defaults" and then reconfigure the most important settings.

I had used that "Load BIOS defaults", then re-enabled the IDE and some minor stuff. Here's that BIOS defaults:

Unfortunately, it still worked the same - that L2 cache still failed to be detected. I changed those values of those cache write cycles or the DRAM Row/Column Address Strobes, and some of the values stopped the thing from booting properly. When it does boot, the cache is still not being seen.

Running through this forum on the L2 cache not detecting, I saw one of them swapped it with a different cache and found out that these UM61512s in the hand are not working as intended: L2 cache seems to be disappeared

I will try to get some 32KBytes and 128KBytes chips from Taobao (Shipping is quite direct to where I live) with different brands, and these are quite cheap (around $10 for 6 of them 128BKytes including shipping).

You risk compatibility issues with VL cards at high FSB speeds when you switch to T1, but after looking at your board photo, I'm quite confident you are not going to install VL cards into that board 😉

Talking about VL Bus, I once had a 486 PC with these ones, it's some SIS 85C461 (I don't remember if it's a 461 or 471) "Single Chip" board with a Cyrix 486 DX33 (We bought from the middleman, it should be Intel but when opened it much later, it's Cyrix!). Since it was long gone (I blamed myself for not keeping it!) I do not have anymore of these VL cards so I got the PCI version instead.

UncleYong wrote on 2022-10-03, 12:49:

You risk compatibility issues with VL cards at high FSB speeds when you switch to T1, but after looking at your board photo, I'm quite confident you are not going to install VL cards into that board 😉

Talking about VL Bus, I once had a 486 PC with these ones, it's some SIS 85C461 (I don't remember if it's a 461 or 471) "Single Chip" board with a Cyrix 486 DX33 (We bought from the middleman, it should be Intel but when opened it much later, it's Cyrix!). Since it was long gone (I blamed myself for not keeping it!) I do not have anymore of these VL cards so I got the PCI version instead.

Looking at the screenshot, I see that I was wrong. You can choose between T2 and T3. Always choose T2 unless you have slow local bus devices. On this board, there are no local bus devices (except maybe the onboard IDE, but that one will work with T2 at reasonable FSB frequencies, 60MHz being not that reasonable anymore).

UncleYong wrote on 2022-10-03, 12:49:

"BIOS defaults" are reasonably performant settings that will work on typical system configurations. You might want to load "BIOS defaults" and then reconfigure the most important settings.

I had used that "Load BIOS defaults", then re-enabled the IDE and some minor stuff. Here's that BIOS defaults:
bios_defaults.jpg

Possibly I was wrong here again. The settings you show are ultra conservative, not performance optimized. Try the other defaults set.

I did both defaults - still the same no L2 cache detected.

From some findings, I'm also suspecting that some systems will detect the L2 cache when the FPM 72-pin is being used instead:

source: https://ancientelectronics.wordpress.com/tag/486/

Now this motherboard can be notoriously picky and even though my board detected the 256kb of L2 cache at first it wasn’t actually using it and running benchmarks or cachechk utility resulted in no L2 cache detected. I wasn’t until later I discovered I needed to replace the EDO RAM with FPM for my machine to use the L2 cache stick (the performance boost from L2 cache over EDO RAM is significant so choose L2 cache if you have to chose only one). Maybe a different brand of EDO RAM would fix this but I did not have any other makes on hand to test. I also had to try several sticks or FPM RAM before I found sticks it would even boot with, its a very picky board. Also note that I have read that some boards may not detect the L2 cache if your using more then 32MB of RAM. Mine doesn’t seem to have this issue but yours may.

I may get some FPM sticks if that is so.

Your chipset seems to be the newest revision that may work with EDO too.
SiS 496/497 revisions

I've tried EDOs in an older chipset revision and my BIOS forced to use the bootblock routines.

UncleYong wrote on 2022-10-07, 13:27:

From some findings, I'm also suspecting that some systems will detect the L2 cache when the FPM 72-pin is being used instead:

Wow, that sounds interesting. The "preliminary SiS 496/497 datasheet" I have at hand claims that L2 cache is supposed to work even in EDO mode. Maybe there is a common BIOS bug in the SiS chipset support package that accidentally disables L2 when it detects EDO DRAM?

Can you provide a dump of PCI configuration space of the host bridge? You can use my PCI dumping/patching tool at https://github.com/karcherm/dostools for example. If you decide to use that tool, run it like

pci 06/00/00 40.L 50.L 54.W 64.L

to get the contents of all relevant registers for cache configuration?

mkarcher wrote on 2022-10-07, 17:40:

Wow, that sounds interesting. The "preliminary SiS 496/497 datasheet" I have at hand claims that L2 cache is supposed to work ev […]
Show full quote

Wow, that sounds interesting. The "preliminary SiS 496/497 datasheet" I have at hand claims that L2 cache is supposed to work even in EDO mode. Maybe there is a common BIOS bug in the SiS chipset support package that accidentally disables L2 when it detects EDO DRAM?

Can you provide a dump of PCI configuration space of the host bridge? You can use my PCI dumping/patching tool at https://github.com/karcherm/dostools for example. If you decide to use that tool, run it like

pci 06/00/00 40.L 50.L 54.W 64.L

to get the contents of all relevant registers for cache configuration?

I'm using the tool to dump the registers - thanks for the help too! 😁

Disruptor wrote on 2022-10-07, 15:36:

Your chipset seems to be the newest revision that may work with EDO too.
SiS 496/497 revisions

I've tried EDOs in an older chipset revision and my BIOS forced to use the bootblock routines.

I have tried other EDO sticks around my desk and it doesn't want to boot anymore - the long beep and two short beeps are being heard. The strange thing is the Buffalo brand EDO RAM I have actually works with it. Not sure if this chipset is pretty picky about which EDO to use.

Using that pci tool, I get this one:

100:05.0 - 40.L is 0b495106
200:05.0 - 50.L is 00000000
300:05.0 - 54.W is 0000
400:05.0 - 64.L is 00000000

Tried modifying some of these at 0x42-0x43 register (from the SIS '496/497 book) - and changing the amount of cache expectedly crashes the system.

I'm trying to experiment writing more on these registers to see what happened.

Hello retro PC experts!

After getting a small supply of extra cache chips from a 64kbytes to 128kbytes, swapping all of these still didn't work - it refuses to acknowledge the L2 cache...

... until I changed the processor selection jumpers according to the mini-guide in the Taobao page (see the AMD DX4-100):

When I booted it, it is still detecting a DX4-100, but when I started running SpeedSys and CacheChk, it finally detects all the L2 cache!

I'm still scratching my head to see why a wrong processor selection jumper setting could lead to a non-detectable cache...