It looks like your board isn't caching the entire range of memory. Some motherboards have weird limitations like that; BIOS settings sometimes exacerbate such issues.
What's your motherboard and its chipset?

Well, the board says

34DMU=50hl2-l4-vb
p353F0010B
Made in Taiwan

I can't find anything on the internet about it. The chip appears to be a um82c481af.

If it wasn't caching, wouldn't CACHECHK say something like "It looks like megabyte #16 isn't being cached"?

CACHECHK doesn't always say what it should; in some cases, particularly those where the cache and DRAM speeds are fairly close (happens on rather fast-ish boards): it'll say a system doesn't have any cache at all when the timings indicate clearly otherwise.

Would it be possible for you to post a picture of the board? I am wondering if perhaps the TAG SRAM size is too small for the cache to cover the whole 32MB range, or if the BIOS setup is what's keeping it from caching the whole range.

The CACHECHK output shows that addresses past 16MB not only the L2 is not working anymore (which might be caused by the tag RAM / cache size being too limited to cache data past 16MB), but in this case the areas past 16MB is also uncached in L1. This looks as if the chipset treats the area past 16MB as entirely uncachable and explicitly tells the 80486 to not cache that memory in L1 cache. Please check the CMOS setup for an option like "Memory past 16MB cachable".

https://drive.google.com/drive/folders/1CLjjg … L1XPMoykYJR-8Tp

These images looked a lot better on my phone. If you can't see something I can take it apart again.

The BIOS does have a non-cacheable block option. Two of them even. I turned them on and it did what you'd expect. 82s across the board in CACHECHK.

I have individually set each other option, except ELBA# and DMA clock. No change in behavior. I was really hoping ALT bit did something.

Is the MCM6202CP20 the TAG ram? It appears to be 32Kx8, shouldn't that be enough for 256K of cache? Are the adjacent jumpers relevant? Would CACHECHK even see 256K of L2 if jumpers weren't set correctly?

If 256KB of cache get recognized and the system runs stable, the cache jumpers are most likely correct.

I don't see the "above 16MB cachable" option in your chipset setup, so maybe the option has been disabled by the mainboard manufacturer. Are you able to get a BIOS image from your board?

I believe this is the bios. What can we learn from the BIOS dump?

The option appears to be in there. 'strings' outputs in part:

1MNOPMemory Remapping           
2E0000 ROM Belongs to ATBUS 
3Memory above 16MB Cacheable
4C0000-C3FFF,16K  Cacheable 
5C4000-C7FFF,16K  Cacheable 
6C8000-CBFFF,16K  Cacheable 
7CC000-CFFFF,16K  Cacheable 
8D0000-D3FFF,16K  Cacheable 
9D4000-D7FFF,16K  Cacheable 
10D8000-DBFFF,16K  Cacheable 
11DC000-DFFFF,16K  Cacheable 
12E0000-EFFFF,64K  Cacheable 
13F0000-FFFFF,64K  Cacheable 
14Non-Cacheable Block1 Enable
15Non-Cacheable Block-1 Size 
16Non-Cacheable Block-1 Base 

I don't suppose this is something that could be fixed with a hex editor and a new EPROM?

It appears to be a EFA CORPORATION 34M50HL2 from the BIOS string + layout, switches and jumpers.
American Megatrends Inc., X0-0100-001281-00101111-060692-UMC480A ..
BIOS also has this: 34DMU=50H(F)L Ver.2 but is definately not a EFA CORPORATION 4DMU-50AHL if http://www.win3x.org/uh19/ and TH99 are correct.
http://www.win3x.org/uh19/motherboard/show/2053
Can you take a better picture ? One with equal lighting on the board if possible (I know it can be hard when in a case)

So it's apparently the BIOS setup... hmm. That's annoying that the manufacturer would block caching above 16MB like that.
Can you turn on DRAM Page Mode and see what happens to the off-cache access times? I'm curious to see if that will bring that 82ns down to a lower number.

Hatta wrote on 2020-12-19, 18:55:

The option appears to be in there. 'strings' outputs in part: […]
Show full quote

The option appears to be in there. 'strings' outputs in part:

Copy code to clipboard

1Memory above 16MB Cacheable

I don't suppose this is something that could be fixed with a hex editor and a new EPROM?

This is definitely something that can be fixed with a hex editor and a new EPROM. If you are lucky, you can use ready-made tools that simplify the work. You also can fix this with a utility that flips the associated chipset configuration bit after booting. But there is one major catch: Each power-of-two cachable area needs an extra trace on the mainboard between the tag RAM and the chipset. Maybe your mainboard vendor omitted the required trace and jumpers to be able to provide 32MB cachable area (and thus fixed the option "memory above 16MB cachable" to "off"), so hardware modification might be required. I'm going to take a look at the jumpering instruction to deduce whether it is likely that the hardware actually supports more than 32MB cachable area.

I own a mainboard with the same chipset that is able to correctly cache 32MB RAM, but it has a very dangerous catch: The UMC82c481/2 chipset can do "memory relocation" even with 32MB RAM installed, which remaps some of the unused memory to the top of memory. The result is that the highest usable address on that board is 32MB+256KB or even 32MB+384KB (depending on shadow settings). The mainboard vendor (Elitegroup Computer Systems) omitted the trace that enables the chipset to correctly cache memory at addresses above 32MB, but does not enable any cachable area limit. The result is that the board mixes up data from address 0 and data from addres 32MB inside the caches and makes the system crash if the relocated memory is used. That problem can be fixed in software by either disabling relocation (so the highest RAM address available is just below 32MB), or by entering a non-cachable area of at least 512KB starting at 32MB (making the relocated memory uncachable). I am quite annoyed that the board vendor didn't force (at at least recommend) these settings with 32MB of RAM installed. Maybe your system will crash the same way if caching above 16MB is enabled.

A more technical background to the problem: (As a side node: To not make matters more complicated, I write the explanation as-if the 486 would access single bytes and had address lines A0 and A1. In fact it doesn't, because it has a 32-bit bus. The difference doesn't matter for the issue at hand, though) The L2 cache on standard 486 boards is a direct-mapped cache with 8 tag bits (in write-through mode, I don't think the UMC82c481 supports write-back). This means that the lowest address bits uniquely determine which cache location might contain a copy of the RAM at that position, and the tag RAM tells you whether it in fact does. In a setup with 256KB cache, each location is the cache is uniquely associated with the lowest 18 address bits. For each combination of the lowest 18 address bits, only one of them will be in the L2 cache. As the cache on 486 boards is organized in "cache lines" of 16 bytes, and not single bytes, a 256KB cache splits the 18 address bits into the low 4 bits which select the byte of a line, and the next 14 bits which select which line to use. The 8-bit wide tag RAM is indexed with this 14 address lines (which means the capacity of the tag RAM needs to be 16 KByte == 128KBit), and if the tag RAM contents are equal to the higher address bits of a memory access, we know that the target address is actuallly in the cache. For the example of a 486 board with 256KB cache, it means that the 8 data bits from the tag RAM are compared to the lowest 8 address bits that are not used to select a position inside the cache. As I mentioned above, you need the address bits up to A17 to select the cache line, so address bits A18..A25 need to be compared to the tag RAM contents. On the other hand, if you only have 64KB of cache, the highest bit used to select a position inside the cache is A15, so the address bits A16..A23 need to be compared to the tag RAM contents. Notice how the upper limit of A23 matches 16MB addressable range!

A key point about the 82c481 (and many contemporary competing chipsets) is that the comparator that compares tag RAM contents with memory address bits is built into the cache/memory controller, but it has fixed inputs for comparing A15 up to A25 (i.e. 11 inputs, they are called TA15..TA25, and are pins 43 to 53 on the 82c481). The A15 input is only used if you run at a measely 32KB of cache, the A16 input is used if you run at 32KB or 64KB of cache, the A17 input is used if you run at 32KB, 64KB or 128KB of cache, and so on. Routing tag RAM contents to the appropriate pins on the cache/memory controller needs to be done in hardware, on the mainboard. Modern 486 chipsets, approximately coinciding with PCI support, have just 8 tag data pins, and route tag data bits to the correct address bits internally in the chipset. This means that on a UMC 82c481 board, you need two jumpers to select whether the two lowest data bits of the tag ram need to go to TA16 and TA17 (as is appropriate for 64KB of cache) and have TA24 and TA25 pulled down permanently for a maximum cachable area of 16MB, or those bits need to go to TA24 and TA25 (as is appropriate for 256KB of cache) for a maximum cachable area of 64MB. On my board, I mentioned above, there is no jumper to choose between TA17 and TA25, so in 256KB cache mode, that board still provides the tag bits on TA17..TA24, with TA17 being ignored by the chipset, but TA25 being permanently zero. The consequence is thus: If the chipset tries to write to the tag that a memory address above 32MB is in the cache, the highes address bit goes nowhere, and when it looks up what is cached, TA25 being permanently zero makes it seem that the memory at an address 32MB below what's actually in the cache would the the address that is in the cache...

mkarcher wrote on 2020-12-20, 12:54:

Hatta wrote on 2020-12-19, 18:55:

Memory above 16MB Cacheable

But there is one major catch: Each power-of-two cachable area needs an extra trace on the mainboard between the tag RAM and the chipset. Maybe your mainboard vendor omitted the required trace and jumpers to be able to provide 32MB cachable area (and thus fixed the option "memory above 16MB cachable" to "off"), so hardware modification might be required. I'm going to take a look at the jumpering instruction to deduce whether it is likely that the hardware actually supports more than 32MB cachable area.

I did so. It seems like you are lucky. If the cache jumpering design is done in the typical way for those 486 boards, W4/W5 are the jumpers you need to properly support 64MB cacheable area if you have 256KB cache. If you don't, upgrade your cache! W6 toggles between single-bank and dual-bank operation, W7 is only used for 61256-type cache chips (used for the 128KB and 256KB operation), and its position also depends on single-bank and dual-bank operation. W8-W11 seem to be meant to enable high-order address bits to go from the chipset to the cache. My board I mentioned before misses the equivalent of W5. It's http://www.win3x.org/uh19/motherboard/show/2123, but the jumper link is broken. See http://www.uncreativelabs.de/th99/m/P-R/31770.htm as replacement. You notice that its JP22 is equivalent to your W6, and JP28 is equivalent to your W4, but nothing is equivalent to your W5.

Hatta wrote on 2020-12-19, 18:03:

I believe this is the bios. What can we learn from the BIOS dump?

It's an AMI BIOS (you probably already knew it before), and it has the required option. If your CMOS is working (proper battery supply present), try AMISetup to toggle that option.

I just stumbled across configuration files for the CTCHIPZ main board configuration utility. There is a UM82c481 configuration file included. Use the following debug snippet to create a COM file make the whole RAM cachable:

1C:\>debug
2-a100
3xxxx:0100 mov al,93
4xxxx:0102 out 22,al
5xxxx:0104 jmp short 106
6xxxx:0106 jmp short 108
7xxxx:0108 in al,24
8xxxx:010a or al,80
9xxxx:010c jmp short 10e
10xxxx:010e out 24,al
11xxxx:0110 int 20
12xxxx:0112
13-rcx
14CX 0000
15:12
16-ncache64.com
17-w
18writing 00012 bytes
19-q
20C:\>cache64
21C:\>

Oh wow, thanks for all the info. I tried it, but unfortunately it would not POST with W4/W5 set, or either individually.

I was however able to enable caching above 16M with AMISetup. How can I test if my machine will crash? What are the downsides to disabling relocation?

Is there a difference between enabling caching above 16M with AMISetup and running that COM file?

Hatta wrote on 2020-12-20, 20:35:

Oh wow, thanks for all the info. I tried it, but unfortunately it would not POST with W4/W5 set, or either individually.

Do not change W4/W5! These jumpers must be set according to the size of your L2 cache.

Hatta wrote on 2020-12-20, 20:35:

I was however able to enable caching above 16M with AMISetup. How can I test if my machine will crash? What are the downsides to disabling relocation?

Use any memory testing tool, e.g. memtest86+ (the plus is important) version 4.1 or earlier (later versions are not compatible with 486 processors). But in this specific case: If CACHECHK didn't crash when measuring timing at 16MB, you can be confident that your board is handling caching of addresses above 16MB correctly.

If you disable relocation, you loose 256KB (or even 384KB without BIOS shadow) of extended memory. How much memory do you have installed? How much cache do you have installed? If you have 32MB RAM, and just 128KB cache, then *don't* enable relocation, because you will get a caching problems otherwise.

Hatta wrote on 2020-12-20, 20:35:

Is there a difference between enabling caching above 16M with AMISetup and running that COM file?

The cache behaves the same - but the COM file works instantaneous, whereas you have to reboot after using AMISetup. If you run that machine without a CMOS battery, running AMISetup every time you power it on and then reboot it to get good cache performance might get annoying. Putting that COM file into AUTOEXEC.BAT is much less annoying. If you have a working CMOS battery, the AMISetup solution is a little bit more efficient, because you can save the time to load the COM file.

Thanks for the detailed explanation. I got through a full cycle of memtest86+ with caching above 16MB and memory relocation. Worked great.

I have also found that there's an MR BIOS for this chipset that is supposed to increase performance. Going to give that a shot too.