rad wrote on 2021-03-26, 08:28:

Tried downgrading the bios to from 04.02 to 03.03 and surprise - the cache has been detected! But it freezes the moment it tries to load MS-DOS. Either freeze or restart automatically. When I turn off the L2 cache in the BIOS it works great, I can run tests, programs, games, no problems whatsoever. But with L2 cache enabled it refuses to load the OS.

Any idea what could cause L2 cache issues? Faulty cache chips, bad socket/trace, chipset, CPU, Power supply?

As you tried a lot of different cache chips, I don't think it's faulty cache chips. Also, faulty CPU is unlikely. The cache does not put a lot of load on the power supply, but of course might be affected if the +5V line is way too low (like 4.2V) or has way too much noise. Still, I don't think your problem is a typical power supply issue. This leaves bad socket/trace and bad chipset as options.

I had a very similar problem with my Biostar 8433UUD. In that case, the cause was a broken address trace. This is a very simple test you can do: All address pins (except one, typically A0) of all data RAM chips need to be in parallel. Also of all of these parallel pins should also appear on the tag RAM socket (if jumpered for a two-bank configuration). Also matching data pins of both banks need to be in parallel. Within a bank, all control pins (OE, WE, CS) are parallel, too.

On most boards, the cache chips are directly connected to the 80486 address and data bus. If that is the case, you can trace address and data lines up to the processor socket. All data lines from the processor socket need to get to the cache. In dual-bank 256K configuration, address lines A4 to A17 should be directly connected to the cache, too.

mkarcher wrote on 2021-03-26, 09:14:

I had a very similar problem with my Biostar 8433UUD. In that case, the cause was a broken address trace. This is a very simple test you can do: All address pins (except one, typically A0) of all data RAM chips need to be in parallel. Also of all of these parallel pins should also appear on the tag RAM socket (if jumpered for a two-bank configuration). Also matching data pins of both banks need to be in parallel. Within a bank, all control pins (OE, WE, CS) are parallel, too.

Thanks for your advice! I've disassembled the board and started to check the parallel connections. So far:
- All OE pins are in parallel within the relevant banks
- All WE pins are in parallel within the relevant banks
- CS pins are in parallel only on 1st, 2nd, ... chips within both banks (only between chips 1 & 2, 3 & 4, 5 & 6, 7 & 8 in the screenshot)

I've started to look at the parallel address pins now, and that's odd:
- All address lines are only in parallel between chips in red zone and between chip in green zone (i.e. chips 1, 2, 3, 4 together, and chips 5, 6, 7, 8 in screenshot)

I'm going to check the links between CPU pins and cache address / data lines now.

rad wrote on 2021-03-26, 16:36:

Thanks for your advice! I've disassembled the board and started to check the parallel connections. So far: - All OE pins are in […]
Show full quote

Thanks for your advice! I've disassembled the board and started to check the parallel connections. So far:
- All OE pins are in parallel within the relevant banks
- All WE pins are in parallel within the relevant banks
- CS pins are in parallel only on 1st, 2nd, ... chips within both banks (only between chips 1 & 2, 3 & 4, 5 & 6, 7 & 8 in the screenshot)

Despite what I said earlier, this is correct. The 486 does not always access the whole 32 bits at once. The CS pins are gated by the four byte enables, so you need four different chip selects within a bank.

rad wrote on 2021-03-26, 16:36:

I've started to look at the parallel address pins now, and that's odd:
- All address lines are only in parallel between chips in red zone and between chip in green zone (i.e. chips 1, 2, 3, 4 together, and chips 5, 6, 7, 8 in screenshot)

It might be that the address lines from the CPU are amplified (or buffered, as you say in digital logic) by the two 74F245 chips for one of the zones and directly connected to the CPU in the other zone, because the board manufacturers considered two banks of cache to be too much load on the CPU address lines. This might explain the separation.

After further examining the traces on the motherboard, everything make sense now:
- Address pins from all cache chips are in parallel, not only those in red and green zones. It is just that different pins on the address bus have been used. For example, A4 address line is wired to pin A1 on cache chips 1,2,3,4 and pin A12 on chips 5,6,7,8, all those gated via one 74F245 input/output pin. It really doesn't matter, this has been done probably for optimizing trace paths.
- The only address pin on the cache chips that is not wired to the address bus is A8, which is in parallel on all chips on odd bank and on even bank. It goes to either KA3X - Cache address 3 for even bank or KA3Y - Cache address 3 for odd bank, on the chipset. Here I've found the first broken trace - chips 5,7 were not connected to chips 1,3 and to the chipset pin. The other bank - chips 2,4,6,8 are all good.
- Data pins from all cache chips are directly connected to the address bus. Every data I/O pin from one bank (4 chips x 8 I/O pins) is connected to a single data pin on the bus (32 bits total). Here I've found the second broken trace - D3 wasn't connected to I/O3 pins on chips 3 and 4.

First I've found the bad cache address trace, placed a jumper wire, but the board still refused to run properly. Then I've decided to remove the IC socket to see where exactly the trace has been damaged (the trace is on the front side of the board). It looks perfect, but there was no connection on its ends. After that I've discovered the bad data trace, but now I can't test it, because I'm still waiting for a new socket to arrive first. After I solder it will retest the board again.

Hopefully the board will be working fine, although 2 broken traces makes me think there could be more.

mkarcher wrote on 2021-03-26, 09:14:

This leaves bad socket/trace and bad chipset as options.

Thank you @mkarcher for your suggestions!

The board now works perfectly: