Nice work!

Garrett W wrote on 2021-03-26, 09:53:

UMC 82C481BF + 82C482AF based mainboard with Mr.BIOS EEPROM and 128K 20NS cache

Looking at the list of MrBios images, looks like there is a v1.44 for your chipset. UMC_UM82C481BF

Have you considered upgrading? Did wonders for my system.

These are pretty consistent results.

1KiB of internal cache gives, depending on the code, some 65% to about 80% hit ratio. The 80% is probably more for loops than typical unrolled code that 386 prefers. This ratio quickly goes up for typical DOS code - programs back then were way smaller than today. So 32KiB can give you 90% already (again, depends on the code) and since 100% is the limit, the more you have the better but you are not going to see much difference between 90% and 95%.

Anyway, "-e-" is obviously the worst. It might seem weird that 1k internal cache has almost the same performace impact as 32k external on the DLC but keep in mind the external cache is that - external. While it has way higher hit ratio you are wasting 2 cycles for each 4 bytes fetched (and you need to fetch code as well as data), while on-chip cache is 1 cycle latency and basically the bus requests are only for the data once the code has been cached.

Notice how "-e- " is actually somewhat faster than "-e -k". I bet KEN input is floating high (not connected to chipset) so you are not populating the internal cache. Thus it is effectively disabled but with some slight performance drop related to sampling KEN.
"-e -b -m-" is probably the safest setting but frankly the A20 gate mask doesn't do all that much. It's only needed when running XT code that actually uses the 20-bit wrap back to segement zero, and sure there are stupid programs like that (it's why we have that silly masking) but not many. So you can remove "-m-" and not suffer the penalty.
If "-f" has the same performance as "-b" with hidden refresh, and no hangs or corrupted data from/to floppy drives, then I'd say stick to flush. It means that line is connected and the chipset is properly driving it. BARB option will trigger on all kinds of DMA, both read and write, so possibly "-b" will be slower when using SoundBlaster sample playback via DMA. It should not be a massive difference though and all other DMA transfers like floppy R/W are blocking operations in DOS anyway.
"-e" without "-b" or "-f" should not be stable, unless BIOS enabled one of those option for you during boot and you didn't actually try disabling it for testing. Test if you read/write from floppy disk properly, be prepared to reformat after it gets corrupted.
"-a" is most likely unstable because, like KEN, A20M is not connected and floating, so it might randomly mask when it shouldn't and CPU uses wrong cache lines for DOS HMA. The safer default is to assume A20 is not masked all the time (even though it actually is under pure DOS) because, as explained above, most programs don't try that silly wraparound.

BTW cache is always enabled on all 486+ CPU, that includes DLC family. Cyrix worked around that by adding a default exclusion zone that covers all 4GB of memory space. If the BIOS really supports DLC chips it should:
- properly set up exclusion zones for memory range 640 to 1024 KiB
- remove that default exclusion zone (that can be a part of step 1)
- set proper flushing method (preferably KEN+flush, or just flush, or BARB with hidden refresh)
- offer an option to disable the cache via CR0 bit, this is what is actually toggled in BIOS when you select "Internal cache: Enabled/Disabled"
So, if you need to configure the zones yourself, or enable the CR0 bit but BIOS does not offer the option, I'd say the support is lacking.

Flush without KEN will not work on cards with memory-mapped I/O (or say VESA video cards with VRAM mapped into memory space). But can be possibly worked around by adding an exclusion zone . Also DLC chips are really pretty 486-like in how they work so even though the 386 is already mostly bus-bound, some more cycles can be saved on DLC with external cache only. Though obviously it's best to have both caches enabled.

douglar wrote on 2021-04-28, 23:49:

Garrett W wrote on 2021-03-26, 09:53:

UMC 82C481BF + 82C482AF based mainboard with Mr.BIOS EEPROM and 128K 20NS cache

Looking at the list of MrBios images, looks like there is a v1.44 for your chipset. UMC_UM82C481BF

Have you considered upgrading? Did wonders for my system.

That's the version I'm using!

Deunan wrote on 2021-04-28, 23:52:

BTW cache is always enabled on all 486+ CPU, that includes DLC family. Cyrix worked around that by adding a default exclusion zo […]
Show full quote

BTW cache is always enabled on all 486+ CPU, that includes DLC family. Cyrix worked around that by adding a default exclusion zone that covers all 4GB of memory space. If the BIOS really supports DLC chips it should:
- properly set up exclusion zones for memory range 640 to 1024 KiB
- remove that default exclusion zone (that can be a part of step 1)
- set proper flushing method (preferably KEN+flush, or just flush, or BARB with hidden refresh)
- offer an option to disable the cache via CR0 bit, this is what is actually toggled in BIOS when you select "Internal cache: Enabled/Disabled"
So, if you need to configure the zones yourself, or enable the CR0 bit but BIOS does not offer the option, I'd say the support is lacking.

Thanks for the analysis.

After I upgraded to MrBios 1.65, "486DLC " was identified on the post screen and when I'd run "cyrix - q" after boot, it would say "Cache disabled by CR0" and would still have the 4G exclusion zone, but there was no option in the BIOS to configure the on-chip cache. Seems like there was some support, but I agree that it isn't perfect support. There were exclusion zones in the Bios for the mobo cache, but they didn't trickle up to to the on-chip cache.

Win98se Installed, slow and steady via scripted install. "setup.exe msbatch.inf /nf /nh /ie /n /iq /is /if /nm" Took 5 hours. Takes 150 seconds to get to the Win98se desktop from a cold boot. Setting the bar low, I have to say it works better than OS/2 2.0 did on a 486 25 w/ 4MB of ram. I remember I was so excited when I got the beta disks back in 1992, but it took 20 minutes to boot after a 21 diskette install. That poor hard drive took a beating with the swapping.

It's nice to see the proper CPU name in the hardware property page, but I think it just grabs the BIOS string when it populates the registry entry that fills the page.

The Windows install kept the Cyrix.exe calls in the autoexec.bat. Seems to work fine with no performance differences on my system between "c:\cyrix\cyrix.exe -e -xA000,128" or "c:\cyrix\cyrix.exe -e -f -xA000,128". I ran "cyrix -q" from a Windows DOS prompt and the settings were in effect.

I can't seem to turn on DMA with my existing controller & CF storage. I'll get some DMA cards in here & retest next week. I have an ISA SIIG EIDE controller and a Soundblaster 32 that I can try.

Poor little guy. Running hot and winded trying to catch up.

Garrett W wrote on 2021-04-28, 23:57:

That's the version I'm using!

That's what I get for skipping posts in the middle of the thread.

So were all of your issues are worked out by finding an upgraded bios and l2 cache chips that the 486DLC chip likes?

Are you still using the cyrix.exe tool? What kind of cpu index do you get in speedsys ?

Yeah, I pulled some 15ns chips from my 5x86 120 system and tried them, system seemed very stable. I've now put them back on the board they came from and have ordered 9 chips to get up to 256K on this board. If that fails, I'll just drop 4 of them and go back to 128k which I know works.

As for the cyrix.exe tool, yes I use it, I've set L1 cache to disabled in the BIOS and use this line:

"C:\systools\cyrix.exe -e -f -b- -m- -xA000,128 -xC000,256"
Seeing as -m- is probably needless in DOS, I'll see if I can make a Windows option in my Autoexec.bat and Config.sys files for using Win3.11 exclusively. But, all of that will have to wait until I get the cache on my hands. As far as speedsys goes, I'll have to get back to you on that once I get that L2 cache, the added FPU does things with the score.

Hope that your cache chips are not from China sellers.

Cheers,