Tried another cpu?
Board might always display amount of cache detected, even when its disabled. It not detecting any might mean there is something wrong between cache and main CPU bus.
You can look into my signature to see typical ASYNC 486 cache diagram. TAG chip outputs always go back to the chipset/cache controller. The only explanation I can come up with is something weird with TAG chip socket? like when you insert chip into it it shorts some CPU address pins together?

rasz_pl wrote on 2024-02-24, 23:33:

Tried another cpu?
Board might always display amount of cache detected, even when its disabled. It not detecting any might mean there is something wrong between cache and main CPU bus.
You can look into my signature to see typical ASYNC 486 cache diagram. TAG chip outputs always go back to the chipset/cache controller. The only explanation I can come up with is something weird with TAG chip socket? like when you insert chip into it it shorts some CPU address pins together?

Yeah, I tried a few, 486DX, DX2, SX. Same thing with all of them.

Cache sockets look fine, but it may be worth trying to remove at least the TAG one as it will also make it easier to spot exactly where each trace underneath it goes to.

Before removing sockets try pulling any other chip while leaving TAG in. I have a suspicion it will behave same way as with TAG removed, ergo its not TAGs fault. Might be flaky connection to one of SRAMs, floating CE or OE would do it.

OK, so I ran a few more tests, and what I found is that if the TAG chip is inserted, regardless of whether any of the other 8 cache sockets are populated or not, I get the slightly long POST beep and it hangs on "Starting MS-DOS...". Also I noticed that the table that displays the AMIBIOS settings after POST is drawn very slowly when this happens. Something messing up the bus probably?

On the other hand, as long as I keep the TAG socket empty, I get the regular short POST beep and everything works fine, even with the L2 set to Enabled in BIOS! But with "0KB CACHE MEMORY" obviously. This works with 0 or more cache chips inserted, unless it's the TAG. As soon as I insert the TAG chip, it freaks out (I tried several different chips on the tag socket just to be sure, but as I mentioned above they all work fine on other boards).

The TAG socket looks perfectly fine, I'll try to trace the different pins to see if there's any obvious breaks before any attempts at desoldering.

0KB cache means bios tried detecting cache size but determined there is none or malfunctioning - in that case it will not enable Cache at all. Disabled cache will deactivate cache controller TAG inputs. I cant come up with a scenario where behavior you describe would make sense 🙁 How would TAGs presence make difference to how SRAM chips influence data bus. TAG chip is not wired in any way to data SRAM chips.
Hmm now I see there are jumpers on board to disable cache, what happens if you power up with all sram chips and jumpers set to disabled and 128KB?
Are you sure Turbo is not enabled?
https://theretroweb.com/motherboards/s/asus-i … -486sv2-rev-2.4 has different bios and pdf of SIS 460 with pin numbers for all cache signals, will help you checking if all cache chips are connected with no breaks.
If you manage to find whats wrong and fix it the next step is modding in Alter bit SRAM for L2 Write-Back support 😀

Have you tried selecting the slowest L2 cache speed settings in the BIOS?

I saw the cache problem, so you should try (if you haven't already done so), looking at the manual and see if there is a jumper setting for 0KB, if there is, remove the cache chips and try to see if it starts, in that case you may have a bad chip or track, but you have to try with the TAG chip installed, this will tell (in my opinion) if the TAG chip works, if it doesn't start and taking the TAG chip off, it starts, the problem should be restricted to the (interrupted?) tracks, or to some component such as a faulty resistor or capacitor.
I also have a MB 486 with cache no longer working, unfortunately lately I don't have time to fix it, but I hope to have some time soon.

Hard to tell since I don't have the board at hand. But you could check for any kind of short, check VCC and VSS pins on TAG socket when empty/populated. Maybe a bad capacitor?
Check thoroughly for any additional corrosion or trace damage which you could have easily overlooked. Since your board has so much damage the probability of some hidden damage is of high probability.

rasz_pl wrote on 2024-02-25, 06:10:

0KB cache means bios tried detecting cache size but determined there is none or malfunctioning - in that case it will not enable Cache at all. Disabled cache will deactivate cache controller TAG inputs. I cant come up with a scenario where behavior you describe would make sense 🙁 How would TAGs presence make difference to how SRAM chips influence data bus. TAG chip is not wired in any way to data SRAM chips.
Hmm now I see there are jumpers on board to disable cache, what happens if you power up with all sram chips and jumpers set to disabled and 128KB?

The board has only 3 config options for cache, 64KB (2 banks), 128KB (1 bank) and 256KB (2 banks). No 0KB or disable option via jumpers, external cache enable/disable is in BIOS only. I will try the 128KB option with both banks populated to see what happens.

rasz_pl wrote on 2024-02-25, 06:10:

Are you sure Turbo is not enabled?

Turbo is enabled, I have shorted the TB. SW. header with a jumper, otherwise the board runs at slow speed.

rasz_pl wrote on 2024-02-25, 06:10:

https://theretroweb.com/motherboards/s/asus-i … -486sv2-rev-2.4 has different bios and pdf of SIS 460 with pin numbers for all cache signals, will help you checking if all cache chips are connected with no breaks.

Yeah, I get the same behavior with that newer BIOS. I've been checking the connections between the cache chips and the chipset and everything seems correct so far. One interesting thing I noticed is that for the TAG chip, most of the address pins (A0 to A14, except for A10 and A13) are connected to the the inputs of the nearby 74F245 transceivers. When the cache jumper block is configured for 256KB, A10 also gets connected to one of the 245s, while the 64KB configuration connects A10 to OE/CS pins on the TAG.

I'm still trying to understand how this works, but these 2 logic chips are high on my list of suspects since they are directly connected to the TAG socket which seems to be what is messing things up.

rasz_pl wrote on 2024-02-25, 06:10:

If you manage to find whats wrong and fix it the next step is modding in Alter bit SRAM for L2 Write-Back support 😀

Yes, that was in my plans before I encountered this issue 😉. Hopefully I can fix this.

MikeSG wrote on 2024-02-25, 10:53:

Have you tried selecting the slowest L2 cache speed settings in the BIOS?

Yeah, the BIOS only has "Fast" and "Slow" options for both the cache and DRAM, in all cases I get the same behavior.

PC@LIVE wrote on 2024-02-25, 14:36:

I saw the cache problem, so you should try (if you haven't already done so), looking at the manual and see if there is a jumper setting for 0KB, if there is, remove the cache chips and try to see if it starts, in that case you may have a bad chip or track, but you have to try with the TAG chip installed, this will tell (in my opinion) if the TAG chip works, if it doesn't start and taking the TAG chip off, it starts, the problem should be restricted to the (interrupted?) tracks, or to some component such as a faulty resistor or capacitor.
I also have a MB 486 with cache no longer working, unfortunately lately I don't have time to fix it, but I hope to have some time soon.

No jumper config for 0KB on the manual, only 64/128/256. As I mentioned before, I tested with multiple sets of known working SRAM chips and the result is always the same: as soon as I insert something in the TAG socket, the system hangs while booting, even with L2 cache disabled. I'm still testing connections and components around the area, it's so densely populated that sometimes it's difficult to follow the traces.

Paar wrote on 2024-02-25, 16:54:

Hard to tell since I don't have the board at hand. But you could check for any kind of short, check VCC and VSS pins on TAG socket when empty/populated. Maybe a bad capacitor?
Check thoroughly for any additional corrosion or trace damage which you could have easily overlooked. Since your board has so much damage the probability of some hidden damage is of high probability.

To be honest, the area around the cache chips looks fine, most of the damage was near the battery (and of course the original SIMM slots that were destroyed), but the board looks really good now except for scratches in the plastic of the ISA/VLB slots. But I definitely could have missed something so I'm going slowly through the different connections, as I explained above one of my suspicions is the two transceiver chips directly connected to the TAG socket. However I'll try to discard broken connections and shorts before attempting to desolder those.

Just to be sure - have you tried to use a contact cleaner on the cache sockets? I had several cases of bad memory/cache because of socket contacts oxidization. It's a good strategy to start with simple things before doing it the hard way.
It's a nice board. Hopefully you'll manage to fix it.

It might be some bad cache chip holders.
Either way I would not spend to much effort trying to fix it.
Even if you have 256kb of cache you are only going to gain 2% CPU performance at best.
If you really want to gain CPU performance upgrade the CPU to a faster one.
Motherboard Cache is going to get you better game play performance.

I would put my time and money into a faster CPU instead.

A 486dx2-66 or faster.

I had the same problem with a Gigabyte motherboard cache and left it alone because it’s not worth it to fix for so little reward in performance.

Paar wrote on 2024-02-25, 17:51:

Just to be sure - have you tried to use a contact cleaner on the cache sockets? I had several cases of bad memory/cache because of socket contacts oxidization. It's a good strategy to start with simple things before doing it the hard way.
It's a nice board. Hopefully you'll manage to fix it.

Yes, I applied contact cleaner several times and verified that when a chip is inserted there is continuity from the legs to the pin on the bottom of the board. Eventually I may end up replacing the sockets if I suspect there's something wrong with them, but as you say better try the easier things first 😉.

Intel486dx33 wrote on 2024-02-25, 18:08:

It might be some bad cache chip holders. Either way I would not spend to much effort trying to fix it. Even if you have 256kb of […]
Show full quote

It might be some bad cache chip holders.
Either way I would not spend to much effort trying to fix it.
Even if you have 256kb of cache you are only going to gain 2% CPU performance at best.
If you really want to gain CPU performance upgrade the CPU to a faster one.
Motherboard Cache is going to get you better game play performance.

I would put my time and money into a faster CPU instead.

A 486dx2-66 or faster.

I had the same problem with a Gigabyte motherboard cache and left it alone because it’s not worth it to fix for so little reward in performance.

I know very well how much L2 cache affects performance, and I have multiple 486 boards (many of them faster than this one) and CPUs that I can use instead, that is not the point of this thread.

This is about restoring this board and I have been getting helpful advice from other folks in this thread, no need to change that.

There are two things I'd try before any kind of additional soldering work:

1. Check the pins on SiS chipset. The board was probably badly stored and pin or two could get loose.
2. You made some soldering work on the SIMM sockets. Try to thoroughly clean any residue flux as even small presence can make the board surface conductive where it shouldn't be. I made this mistake before.

TheMobRules wrote on 2024-02-25, 17:45:

The board has only 3 config options for cache, 64KB (2 banks), 128KB (1 bank) and 256KB (2 banks). No 0KB or disable option via jumpers, external cache enable/disable is in BIOS only. I will try the 128KB option with both banks populated to see what happens.

sorry, pictures were at an angle and I just blindly assumed leftmost was 0kb. Try both 64 and 128 positions.
Also just for kicks try with U37 PAL chip (Im guessing responsible for VLB busmastering) removed.

TheMobRules wrote on 2024-02-25, 17:45:

I've been checking the connections between the cache chips and the chipset and everything seems correct so far. One interesting thing I noticed is that for the TAG chip, most of the address pins (A0 to A14, except for A10 and A13) are connected to the the inputs of the nearby 74F245 transceivers. When the cache jumper block is configured for 256KB, A10 also gets connected to one of the 245s

manual of a SiS 85C460 board with full schematic http://www.bitsavers.org/pdf/samsung/pc/98134 … Manual_1993.pdf page 113 shows one cache bank configuration

TheMobRules wrote on 2024-02-25, 17:45:

while the 64KB configuration connects A10 to OE/CS pins on the TAG.

and ground 😀
Its easier to reason about it from the other side using CPU side designations, so not A0-14 but CPU_A4-17
245s are hard wired for one directional operation, so "A10 and A13 are connected to" outputs

TheMobRules wrote on 2024-02-25, 17:45:

I'm still trying to understand how this works, but these 2 logic chips are high on my list of suspects since they are directly connected to the TAG socket which seems to be what is messing things up.

There is infinitesimal chance somehow TAG chip is loading one of them too much leading to glitches? but it feeds all Sram chips so there should be noting special about removing TAG ram vs removing any other SRAM.

OK, I think I found the problem. As I was examining the board, I noticed what looked like an extremely small gouge near one of the VLB slots. When I applied some IPA with a q-tip a tiny piece of trace that was lifted came off. Looking at pictures I took from when I first got the board, it seems this was already broken, so it wasn't me that broke it during the cleaning! 😅

Anyway, I tried to follow where that trace goes and on the chipset side it connects to pin 136 which is... KWEX* (Cache write enable for even bank)! The other end of the trace connects to the WE* pin of the BANK0 cache sockets as expected, and when I probed for continuity between that chipset pin and the cache sockets there obviously wasn't any.

On the other hand, pin 137 of the chipset, KWEY* (Cache write enable for odd bank) is properly connected to the WE* pin on the BANK1 cache sockets. All the other connections nearby (TAG data pins and WE*, Cache read enable for both banks) also check out just fine.

So, when I have some time I will do a quick bodge in order to restore connectivity on that trace and if that fixes the issue I will attempt a cleaner, more elegant fix. I'm confident this will fix the issue, will update the thread as soon as I do this.

This looks promising. It's the kind of damage that's very hard to spot. Great you found it!

Success!!

Fixing the KWEX* trace did the trick, and now the board is fully working! Unfortunately I had to remove the VESA slot in order to patch the trace, but seeing the result I think it was worth it:

Those traces are really thin and made soldering the jumper wire quite difficult without a microscope, but I managed to get a pretty good looking fix. After that I applied some solder mask for protection and reinstalled the slot.

With the slot covering most of the patched trace the end result is quite nice, if I had yellow solder mask instead of green it would have been even less noticeable. But I'm proud of how it turned out!

Thanks to everyone who contributed with suggestions, one more board back from the dead!

I still dont understand the fault mechanism here. With this track ripped BIOS had no chance detecting any cache, so definitely was disabling it no matter the CMOS settings. How would then this disabled cache screw with computer operation? Dangling WE# could lead to spurious activation of this pin, but it shouldnt do anything without CE# active. Truth table states with CE# high WE# and OE# are ignored. Disabled Cache should leave CE# permanently high. And how does TAG chip fit into all of this? Bizarre 😀