Possibly. Of the 5 boards I am testing, I have noticed that they are very particular about what the CMOS A20 gate setting must be for using L1 cache. I will try to find this out when I get back into the testing.

I didn't notice that one and it's confusing the heck out of me.

NJRoadfan wrote:

Could it be the A20 gate activating during the benchmark? HIMEM controls it when loaded and allows DOS=HIGH. 386 boards can be old enough to rely on the slow A20 gate on the keyboard controller.

Indeed, I totally forgot to say A20 is also something to consider.
Some of my 386 mainboards do already have an A20=fast/normal setting in CMOS setup.
And some of my 286 also have a memory remapping feature (required for +1MB on some boards).

Anyway, Himem.sys from DOS5/6 also has the ability to handle A20 in different ways.
Normally, it does use some kind of auto detection mechanism to find the most appropriate machine type.
Choosing another machine type couldl help a bit in this regard (there are about three alternate modes for ATs).

I remember that there was also a switch named /cpuclock.
I once used that one to stabilize my 286-it helped me to get rid of memory problems.
Don't ask me what what was the cause for that issue (memory timing was set to standard setting).

There is one motherboard which I had to adjust the the HIMEM lines for to get the L1 cache working properly, it was a SiS Rabbit (85C310/320/330) based board. I had to set config.sys to:

HIMEM.SYS /TESTMEM=ON /CPUCLOCK=ON /MACHINE=1 /V

and on that board, I need to set FAST Gate A20 to disabled.

There is an A20M test which comes with the Cyrix L1 enabling software, although I don't really rely on it.

On my VIA 481/495 board, there isn't a Gate A20 option in the BIOS.
On my UMC 481/482 board, I must set "Force A20-Gate Always On" to NO
On my CHIPS 351/355/356 board, I must set Fast Gate A20 to ENABLED
On my SiS 460 board, there is no Gate A20 settings.
On my SiS 310/320/330 board, Fast Gate A20 must be set to DISABLED
On my VLSI 330/331/332 board, Fast Gate A20 set to ENABLED

RESOLVED!

After some testing, I noticed that the benchmark discrepencies no longer occured when HIMEM was loaded if I disabled the L1 cache on the CPU. However, I beleive that the issue is due to the benchmark software being run on a non-cached region of memory. Why do I beleive this?

Normally you set the 1st 64 KB of each 1 MB of RAM as non-cacheable. I don't recall the exact reason for this, but did notice that if it is not set as non-cacheable then many 386 boards will have problems loading (or within) Windows 3.11 if using a 386 CPU with L1 cache enabled.

I seem to recall not needing to set the 1st 64 KB of each 1 MB of RAM as non-cacheable when in DOS though.

Most 386 boards which support the Cyrix DLC CPU automatically set the 1st 64 KB of each 1 MB of RAM as non-cacheable. The issue arrises if you are using a benchmark program which happens to use this region of memory. Whether the benchmark program resides in this region while being run varies by motherboard and whatever else is loaded, e.g. HIMEM.

There is a cyrix.exe command to disable setting the 1st 64 KB of each 1 MB as non-cacheable. It is cyrix.exe -m and when using this command I no longer notice the benchmark discrepencies. There are other non-cacheable regions which normally get set by the BIOS; I think it is 640K - 1 MB. This can be set to cacheable with cyrix.exe -i1 -i2 -i3 -i4, however keep in mind that Windows probably wants these left as non-cacheable.

For consistency between motherboards, I think I will need to set the noted regions as cacheable. I will also continue to load HIMEM.

Some motherboards might have floppy write issues if these regions are set as cacheable. I forget which motherboard had that issue.

Holy…. Feipoa you safed my sleeping time for today. I ran into exactly the same issue and already found myself dealing with a20 options, diff homes versions, etc and then I found this thread. Nice 😀 and thanks.