Horun wrote on 2025-05-04, 14:42:

megatog615 wrote on 2025-05-01, 21:03:

Well, with the help of jakethompson1 we were able to track down some 8kx9(MCM6265CP15). It was expensive, and it still doesn't work, so I'm pretty bummed out.

HOWEVER, the machine consistently reports its "CACHE MEMORY BAD. DO NOT ENABLE CACHE !" line after memory check. I don't know what this means for figuring this out but at least it's consistent.

Does it report any cache amount before that error with the 8kx9 in u43 ?

No. Cache reported is on the POST summary screen, not the POST screen. At the time it gets to the summary screen, cache is disabled. When it gets past the cache bad error with other chips installed it always reports 256K.

Horun wrote on 2025-05-04, 14:42:

megatog615 wrote on 2025-05-01, 21:03:

Well, with the help of jakethompson1 we were able to track down some 8kx9(MCM6265CP15). It was expensive, and it still doesn't work, so I'm pretty bummed out.

HOWEVER, the machine consistently reports its "CACHE MEMORY BAD. DO NOT ENABLE CACHE !" line after memory check. I don't know what this means for figuring this out but at least it's consistent.

Fastest 8kx9 I recently found were -30 which I figure would not work, not fastest enough.

MCM6265CP15 is 15ns.

mkarcher wrote on 2025-05-01, 21:21:

The message looks like the verification of the data cache now fails.

Now something I'm curious about is, as this chipset does not seem to have a cache size mode or cache test mode (the BIOS flips the same bits to size/test the cache and then turn it on after POST if it's of nonzero size), in the case of a functional tag RAM but nonfunctional data RAM, how does it even post--you would think spurious cache hits during the flushing/timing process would cause garbage data to be loaded in as code.

Or perhaps, the F000 segment is non-cacheable during this process--that's probably it.

I was thinking how much of the cache test could be reproduced from a DOS program to see where it goes wrong. Further examination of what triggers the "DO NOT ENABLE CACHE!" message could clear up whether the tag RAM is indeed working now as we suspect, and then it's the data RAMs (unlikely as we tested them all) or some trace going to them.

Curious and figure you all looked at this part already but from the few 32kx9 (all 32pin) and 32kx8 (all 28pin) datasheets I found the VCC needs to be changed from pin 32 to pin 28. Do those 4 set jumpers do that ?
Sorry if covered, am tired 🙁

Horun wrote on Today, 01:30:

Curious and figure you all looked at this part already but from the few 32kx9 (all 32pin) and 32kx8 (all 28pin) datasheets I found the VCC needs to be changed from pin 32 to pin 28. Do those 4 set jumpers do that ?
Sorry if covered, am tired 🙁

Typically, on DIP32 cache SRAM sockets, both pin 30-of-32 (which is 28-of-28) and pin 32-of-32 are connected to VCC. On 128Kx8 chips (I know, that's a different thing than 32Kx9), pin 30-of-32 is an active high chip enable pin, so having it connected to Vcc does not disturb operation. This is why DIP32 sockets on "standard" 486 mainboards usually can be populated with either DIP32 chips (using all pins) or DIP28 chips (omitting pins 1, 2, 31 and 32). Checking a 32K x 9 datasheet, those chips also have an active high chip enable there, so no need to jumper 30-of-32 aka 28-of-28.

The jumper is, as already posted in this thread, to change the function of pin 12-of-32 (which is 10-of-28), which is an address bit on 32K x 8, but a data bit (the parity bit in this use case) on 32K x 9. 32K x 9 has an address data bit on 31-of-32, which is not connected to anything if you insert an 32Kx8 DIP28 chip. As there are four data chips, there are four data/address re-routing jumpers required.

jakethompson1 wrote on Yesterday, 23:55:

you would think spurious cache hits during the flushing/timing process would cause garbage data to be loaded in as code.

Or perhaps, the F000 segment is non-cacheable during this process--that's probably it.

Exactly that. This also ensures that the tag doesn't get modified to point into BIOS space, which would (slightly) distort the timing measurements.

jakethompson1 wrote on Yesterday, 23:55:

I was thinking how much of the cache test could be reproduced from a DOS program to see where it goes wrong. Further examination of what triggers the "DO NOT ENABLE CACHE!" message could clear up whether the tag RAM is indeed working now as we suspect, and then it's the data RAMs (unlikely as we tested them all) or some trace going to them.

A DOS program like that is entirely possible. While working on my Biostar 1MB cache module, I developed a "cache monitor utility" for the UMC 8881 north bridge. It relocates itself in the 28K of text mode video RAM that's not used for text page 0, and then is free to manipulate cache and RAM contents as it desires without causing a system crash. This obviously means it runs with interrupts disabled the whole time, you better do not have SMI-based power management enabled, and the tool needs to have its own low-level keyboard and video interface (you can't run INT10 if you can't rely on working RAM/cache).

The intended use case of that utility is to disable L2 cache in the CMOS setup (which can be skipped if the L2 cache works bad enough that the BIOS itself disables the cache), so you boot into DOS with L2 disabled, load that tool, which copies itself to video RAM, and only then enables the cache as required.

If I remember correctly, the "CACHE MEMORY BAD" test is a very simple "load a single line into L2, write somehting into it (which should hit and update L2) and then test whether you can read back the data from L2". This test is performed with L1 disabled, so there is no need to worry about getting good data from L1 which would mask cache errors. The first time I encountered this "CACHE MEMORY BAD" message was in the '90s, when I reinstalled Windows 95 on a 486 computer of a friend-of-a-friend, which took an unexpectedly long time. After the installation finished, I went to CMOS setup to check for obviously bad setting like disabled cache, and sure enough, I found both internal and external cache being disabled. Then I enabled both caches and got that message. Feeling quite confident that this message is only about L2, I just disabled L2 and kept L1 enabled, which obviously improved performance quite a bit. I then took a peek into the computer to check why it said "cache memory bad", and I just found empty sockets.

mkarcher wrote on Today, 16:54:

Horun wrote on Today, 01:30:

Curious and figure you all looked at this part already but from the few 32kx9 (all 32pin) and 32kx8 (all 28pin) datasheets I found the VCC needs to be changed from pin 32 to pin 28. Do those 4 set jumpers do that ?
Sorry if covered, am tired 🙁

Typically, on DIP32 cache SRAM sockets, both pin 30-of-32 (which is 28-of-28) and pin 32-of-32 are connected to VCC. On 128Kx8 chips (I know, that's a different thing than 32Kx9), pin 30-of-32 is an active high chip enable pin, so having it connected to Vcc does not disturb operation. This is why DIP32 sockets on "standard" 486 mainboards usually can be populated with either DIP32 chips (using all pins) or DIP28 chips (omitting pins 1, 2, 31 and 32). Checking a 32K x 9 datasheet, those chips also have an active high chip enable there, so no need to jumper 30-of-32 aka 28-of-28.

The jumper is, as already posted in this thread, to change the function of pin 12-of-32 (which is 10-of-28), which is an address bit on 32K x 8, but a data bit (the parity bit in this use case) on 32K x 9. 32K x 9 has an address data bit on 31-of-32, which is not connected to anything if you insert an 32Kx8 DIP28 chip. As there are four data chips, there are four data/address re-routing jumpers required.

Thanks ! I knew it worked with typical 486 32 pin versus 28 pin but wondered exactly how that works.