VOGONS


First post, by SodaSuccubus

User metadata
Rank Member
Rank
Member

Im a bit confused here.

I just got a kit of 2x 16mb FPM 60ns in, upon upgrading and then booting my 486 Himem.sys complained about unreliable memory.
I thought it was probably bad sticks but i decided to do some more research anyway. Figured it could possibly be bad cache, so i disabled L2 cache in bios and booted again.

Himem passed its test this time. Curious! So i re installed my 2x 4mb sticks and re-booted with cache enabled. Himem passed.
I tried this test multiple times, iv even tried giving the 32mb pair a really good cleaning. Try re-seating the cache too.
Every time its installed with the 32mb set, Himem complains about their being a bad memory when cache is enabled, but mysteriously won't when i go back to 8mb ram total.

The cache im using was NOS. Its all MT5C256B -15. The tag is -15 too, from the same kit. I do have a pair of ISSI -20ns cache lying around too. The 2x16 kit is 60NS, 8 chips. No idea what the 2x4 mb kit i originally was using is.

Board is DataExpert EXP4044. Absolutely confused. Is cache suppose to have a limit of how much ram it could see? I wanted 16mb originally but i ended up (accidentally, believe it or not) grabbing a 32mb kit instead 😜

Anyone got any ideas?

Reply 1 of 3, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie

What FSB are you running? Which cache timing?

I also can imagine that a broken address line may cause the problem; I'm not sure.
What happens with 1x32 MB or 1x16MB?

Reply 2 of 3, by SodaSuccubus

User metadata
Rank Member
Rank
Member
Disruptor wrote on 2020-07-17, 04:49:

What FSB are you running? Which cache timing?

I also can imagine that a broken address line may cause the problem; I'm not sure.
What happens with 1x32 MB or 1x16MB?

DX4-100, so 33mhz. Memory and cache timings where as low as i could get them stable previously with the 2x 4mb sticks.I did reset all the timings back to their auto-config settings during the debug process and it still error'd.

The board won't run with just 1 stick. It complains and lets out endless beeps.

Reply 3 of 3, by mkarcher

User metadata
Rank l33t
Rank
l33t

With L2 enabled in write-back mode, the write-back operation of dirty L2 lines into the RAM can happen in a burst-like fashion. On the other hand, FSB write burst support is only supported and enabled by default on a couple of 486 boards. So if the 2*16MB modules are too slow to handle a write burst from L2, you could get the symptoms you describe.

Another possible reason is cache mismanagement, but you shouldn't have that issue on a PS/2 capable board. I have a 8*30pin 486 board that has a chipset that provides a cacheable area 64MB (given suitably connected L2 tag bits). The board designers decided to cheap out and did not implement cache size jumpering correctly to provide the highest tag bit, so cacheable area is just 32MB. If you put 8*4MB RAM into that board, the chipset on that board can relocate the 256KB/384KB UMB/shadow area to the top of the memory, so physical menory goes up to 32MB+256kB. Because of the missing tag bits, the board confuses cached data from physical address 128kB and 32MB+128kB. Disabling relocation or placing a non-cacheable area at 32MB fixes the problem.

A take-away for your board: You should diligently check the cache size jumper size, because on earlier 486 boards (possibly up to the first boards supporting PS/2 RAMs), the jumpers are used to juggle around address lines to be used as tag ram address lines. also, try swapping the tag chip, as more RAM might expose a bad bit in the tag RAM that goes unnoticed with smaller RAM sizes.