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.