In the meantime I did some additional tests.

1. The "CE#" pin of the Dirty TAG chip is pulled up by a 1K resistor. Jumper JP36 pin 3 is also connected to the "CE#"pin. As soon as JP 36 is shorted 2-3, it connects it to pin B13 of the CPU (WB/WT) and there is a 330R pulldown resistor present. So the CPU is put in L1 WT mode and the Dirty TAG chip gets enabled - all fine.

2. When JP 36 is shorted 1-2 (pin 1 is Vcc), the CPU enables L1 WB operation, but at the same time the Dirty-TAG "CE#" pin is connected to Vcc and the chip is disabled. For solving this, I interrupted the trace going from B13 to "CE#" and added a 330R pulldown at "CE#" locally. If JP 36 is shorted 1-2, the CPU is now put in WB mode, while the Dirty TAG chip stays enabled.

3. When booting into DOS from HD with jumper JP36 1-2 closed and 4-5 open there is L1 WB + L2 WB with active dirty TAG. When booting from floppy the boot process hangs when loading DOS, with JP36 4-5 closed I get two kind of "£" symbols after the A:/ prompt, I can run programs, L1 and L2 are in WB mode, but Dirty-TAG is disabled.

Then I came across this topic:
Intel Saturn northbridge pinout

I checked my rev. 1.8 mainboard and found that the data-in pin of the dirty chip is connected to pin5 of the northbridge, pin 6 is connected to "HITM" at the cpu socket AND to the data-out pin of the dirty TAG via a 33R resistor when JP36 is shorted 4-5.
Pin 179 of the northbridge (valid) is connected to "I/O 7" (8th bit) of the TAG-RAM. So this design error seems to be fixed in Rev. 1.8?
Pin 7 of the northbridge is connected to "INV". As for the CPU´s "CACHE" output things are more complicated. It goes to JP38, when JP38 is closed it connects "CACHE" to the B-input of the 1st or-gate (pin 2) of U37. It´s output is connected to pin 2 of JP35 and can there be connected to pin 204 of the northbridge (PCD/CACHE). I haven´t traced the A-input yet.
I also cannot find the article about this issue in CT magazine 10/94.
mkarcher, do you remember your results / findings from 2021??

Be careful with that pin-out post when troubleshooting an 486SP3G. The info has been gathered from reverse engineering an 486SP3G, so any eventual routing mistake on that board made it directly into that post. My interpretation of the shared pin for HITM and dirty data out is that the chipset supports only one of L1WB and an external dirty tag at the same time. So the jumper that disables the dirty tag chip and enables L1WB at the same time makes sense.

The BIOS uses the CPUID (from DX-at-reset) to configure the chipset for L1WB support, and IIRC it only recognizes the Pentium Overdrive as L1WB processor. Without chipset support for L1WB, you wll obviously get cache coherency issues on DMA cycles, if not even bus conflicts when the processor tries to flush L1WB on DMA, but the chipset doesn't expect such a thing and already starts a DMA transaction at the same time. Interestingly, on warm boot, that BIOS pulls the cpu type from some reserved byte in the BIOS data area and places it back into the CMOS location Award uses for storing the CPU type. You can fake it to say "Pentium Overdrive" and do a warm boot. The BIOS will then initialize the bus protocol register in a special way that likely enables L1WB support (or is at least supposed to do so), nevertheless DMA coherence was IIRC still broken.

When configuring the L1 and L2 cache modes, the SP3G BIOS does extra chipset programming ensuring that it does not execute INVD or WBINVD while L1WB support is enabled. To achieve that, the bus protocol mode is temporarily reset to some L1WT variant. This seems to be for very good reason: As soon as I execute INVD or WBINVD with the bus mode set to L1WB, the FSB locks up. Executing the invalidation instructions will cause an externally visible bus cycle instructing the chipset to also invalidat external caches. Most 486 chipsets just ignore this cycle, and immediate acknowledge it. As most consumer 486 chipsets use an always-valid topology for the L2 cache, they just can not invalidate the L2 cache. The Saturn can, because the 8 bit tag RAM is used as 7+1, but the +1 is not used as dirty bit, but as valid bit. When the chipset is configured to L1WT, it iterates over all cache lines and clears the tag (including the valid bit). This requires 2 clocks per cache line. After invalidation, RDY is returned to the processor. On the other hand, with the chipset configured to L1WB, it counts twice as fast on the address lines (1 clock per cache line!), and does so in an infinite loop, never asserting RDY. That's where I basically gave up on L1WB with the Saturn chipset until someone digs out a data sheet.

majestyk wrote on 2024-07-16, 10:24:

As for the CPU´s "CACHE" output things are more complicated. It goes to JP38, when JP38 is closed it connects "CACHE" to the B-input of the 1st or-gate (pin 2) of U37. It´s output is connected to pin 2 of JP35 and can there be connected to pin 204 of the northbridge (PCD/CACHE). I haven´t traced the A-input yet.

My notes say:

JP38: Connect P24D CACHE (DX4/5x86) to P24T CACHE (Pentium Overdrive).

JP35: 1-2 = Pin 204 is PCD; 2-3 = Pin 204 is CACHE or PCD.

I recently came across a mainboard that actually supports L1 WB cache under the Intel Saturn II (420TX with 424ZX ) chipset.

https://theretroweb.com/motherboards/s/anigma-p4d-420tx

If someone owns this board we could do some research. Note that it provides 2 x 32K x 8 and and 1 x 64K x 1 TAG/Dirty-TAG chips.