The 486DLC might be tricky to get working with cache enabled. It is not compatible with all 386 chipsets and specifically needs some cache specific signals (KEN#, FLUSH# and A20#) which only late 386 motherboards specifically designed for 486DLC have.

I am not sure where to get UMC481 datasheet to confirm if that chipset is compatible or if your motherboard does that properly. You might try to use a multimeter to see if those signals are connected anywhere on your motherboard.

I'd suggest to get one of the 486DLC register tools such as the one mentioned here and experiment with options.

Disabling 486-style cache controls will likely cost you performance as the CPU might not be able to cache lower 1MB of RAM, lower 64k of every megabyte, would need to fully invalidate cache at every refresh cycle or at every DMA tranfer, etc.. But it might still be better than having the cache completely disabled.

Without those workarounds data in cache gets corrupted which might work for a while before crashing (just like you describe it).

Hi, thanks for the in-depth post. Unfortunately, I tried what feipoa suggested as a general rule of thumb in that thread and it didn't really help any. I was perhaps looking for some more deliberate/targeted tips and suggestions, maybe from someone that has experience using said chip on this chipset.

I think for starters what I'm going to do is remove the FPU and relax the timings just a little bit. Then I'll start looking into the utilities and possible switches I could use. Of interest is the fact that even disabling L1 cache (in the BIOS at least, haven't tried with utility) and leaving L2 enabled will inevitably make the system unstable pretty soon. Is this to be expected? Will using a utility to disable it make a difference?

Also, Mr.BIOS gives me the option to set what it refers to as NON-CACHE BLOCKS 1 & 2, in a very similar manner to the following photo I found in another thread here:

Could that option be of any use?

486DLC has a mode where it flushes its internal cache as soon as bus is requested from the CPU. It should maintain compatibility with any board that doesn't have the 486 style cache control signals available.

There is the Cyrix CPU setup util that allows to control these things.

Messed around with it for a few hours and while I can get DOS to be mostly stable, Windows 3.11 is a lot more volatile. I tried the FLUSH switch, going to take a look at the BARB one next. What an annoying thing 🙁

Found the datasheet. It looks like 82C480 chipset does support 486 signals. In fact it is a hybrid 386/486 chipset. So you problems might not be L1 cache related....

Interesting. Any thoughts as to what could be going on? I'm fairly certain all issues and freezes disappear as soon as I disable both caches or perhaps I haven't been able to make it hang just yet. The exact same issues also manifest when L1 is off and L2 is on.

I use DOS Navigator as a Norton Commander alternative and every so often I will get it to freeze the system when using this processor, no matter the settings, although it obviously tends to happen if I use tweaked settings as per the thread mentioned above. Unfortunately, I can't get it to be 100% stable, at some point, inevitably, when exiting a DOS application or game and while it has to essentially reload Dos Navigator, it often causes a divide overflow error (not divide by zero as I mentioned earlier) often accompanied by "can't load COMMAND".

Concerning Windows 3.1x and WfW 3.11 usage, I wonder if Glenn Slayden's "TI486 VDMAD" driver could potentially be helpful?

Glenn Slayden wrote:

TI486 VDMAD - Version of the virtual DMA device (VxD) for Windows 3.1 or Windows for Workgroups 3.11 which, in order to preserve external cache coherency, controls the 8K on-chip cache on a Texas Instruments TI486SXL (and possibly TI486SLC/TI486DLC) chip at the appropriate times. Using special TI486 registers, I flush and disable the on-chip cache during DMA operations. If this 386-pin-compatible chip is installed in a regular 80386DX system (non PS/2), this software solution maximizes performance while running Windows, without requiring a motherboard modification to support the FLUSH pin.

I'm not yet convinced this is indeed a Cyrix-specific cache problem. If you disable L1 caching on the 486DLC, it should fully conform to the 386DX bus protocol, and it does not need any chipset support. As you experience the crashes also with L1 disabled, the problem is likely located elsewhere. A 386DX-like processor should not notice whether L2 is disabled or enabled, except that the board responds faster to memory requests when L2 is enabled, so enabling or disabling L2 is not generally making the processor work differently. Crashes depending on L2 thus might be mainboard-related instead of processor-related.

On the other hand, while L2 on/off does not generally change the bus protocol, it might specifically change the bus protocol your board uses: The 386DX has an optional feature called address pipelining, which allows shortening memory cycles from 3 to 2 clocks. Maybe you board only uses address pipelining on L2 hits, and the actual problem is an incompatibility between your board and the 486DLC regarding address pipelining. You might want to check whether there is a jumper or CMOS option to disable pipelining. The pin used by the 386DX protocol for pipelining is "NA#" (next address).

Cloudschatze wrote on 2021-03-30, 05:23:

Concerning Windows 3.1x and WfW 3.11 usage, I wonder if Glenn Slayden's "TI486 VDMAD" driver could potentially be helpful?

Glenn Slayden wrote:

TI486 VDMAD - Version of the virtual DMA device (VxD) for Windows 3.1 or Windows for Workgroups 3.11 which, in order to preserve external cache coherency, controls the 8K on-chip cache on a Texas Instruments TI486SXL (and possibly TI486SLC/TI486DLC) chip at the appropriate times. Using special TI486 registers, I flush and disable the on-chip cache during DMA operations. If this 386-pin-compatible chip is installed in a regular 80386DX system (non PS/2), this software solution maximizes performance while running Windows, without requiring a motherboard modification to support the FLUSH pin.

Not such a bad idea to give this one a try once (or if) I manage to get stable in DOS.

mkarcher wrote on 2021-03-30, 07:14:

I'm not yet convinced this is indeed a Cyrix-specific cache problem. If you disable L1 caching on the 486DLC, it should fully conform to the 386DX bus protocol, and it does not need any chipset support. As you experience the crashes also with L1 disabled, the problem is likely located elsewhere. A 386DX-like processor should not notice whether L2 is disabled or enabled, except that the board responds faster to memory requests when L2 is enabled, so enabling or disabling L2 is not generally making the processor work differently. Crashes depending on L2 thus might be mainboard-related instead of processor-related.

On the other hand, while L2 on/off does not generally change the bus protocol, it might specifically change the bus protocol your board uses: The 386DX has an optional feature called address pipelining, which allows shortening memory cycles from 3 to 2 clocks. Maybe you board only uses address pipelining on L2 hits, and the actual problem is an incompatibility between your board and the 486DLC regarding address pipelining. You might want to check whether there is a jumper or CMOS option to disable pipelining. The pin used by the 386DX protocol for pipelining is "NA#" (next address).

You may be onto something. I'm fairly certain I took care of the BIOS options when I set every possible setting to the most conservative option. I'll see if I can take photos of each option screen on the Mr.BIOS and post it here, perhaps someone can see something weird that I didn't notice.

However, when it comes to jumpers I'm presented with the problem that my motherboard is basically a no-name. I've found some PDF manual that more or less seems to resemble it and there's not a whole lot of jumpers to mess with. I'll upload stuff once I'm home.

I want to thank everyone for the replies so far!

Well, that took a while. Sorry about the delay, didn't really have the willpower to work on this for a few days, but today I decided give it another go. I went ahead and tried something different, L1 enabled, but L2 disabled and guess what, system seems stable, I couldn't get it to hang! I pulled off my little stress test of loading Win3.11, then Calmira 3.3, then Solitaire and then Total Commander and tried to connect to my little FTP server and pull some files. Usually, as soon as TC ran, it would crash almost instantly or at best when trying to connect to the FTP, but now it all went smoothly.
For posterity, I used the "cyrix.exe" utility that feipoa suggests in that other thread with the following line added at the beginning of autoexec.bat:

C:\systools\cyrix.exe -e -f -b- -m- -xA000,128 -xC000,256

Of course, as soon as I enable L2 cache, stability goes out the window! Anyway, I'm adding some photos of my system, motherboard photo that I took from elsewhere, BIOS settings as they were before today's modifications (I wonder if I could update Mr.BIOS? 0 experience on that end), as well as what seems to be the manual to a similar if not identical board to mine.

Bumping this in the hope that more knowledgeable people missed it :p

Does the L2 cache work fine on its own without having L1 enabled or is it always crashing when the L2 is on?

I suppose you tried adding read/write waitstates in the cache settings (5th screen) already and it still didn't work? What if you exclude all <1M memory from cacheable range?

If you have spare SRAM chips you might try to replace them to see if that makes any difference and preferably use -15ns chips.

Also as there are electrolytic capacitors in the cache area. I'd try to replace them as they are often dry on 386 era boards.

Well, here's where it gets weird. As long as I use the 486DLC, the L2 does not work fine, even if used solo with the L1 disabled. This was not the case with my 386DX-33 (which I ran at 40), the system was stable and these sorts of issues did not appear.

I have indeed tried to increase the wait states during many phases of tweaking and testing. In fact, as a last measure, I went ahead and increased all wait states across the BIOS to the absolute maximum a.k.a. worst possible config and in general turned every setting I could to its most conservative config, just to be sure. It did not really help, the system would hang with the same frequency.
I have not tried to exclude all <1M memory, I'll give it a go.

I believe I have a 486 VLB board with 256K 20ns chips and maybe even one with 15ns chips that I could try, but would that really fix my issues? Doesn't the fact that the L2 cache works fine when using my 386, with the tightest of timings even, exclude the possibility that the L2 cache chips are at fault? Same idea with the caps.

If everything works fine with the 386DX then SRAM chips are likely OK. And since you tried to increase waitstates faster chips are unlikely to help.

Capacitors might or might not be the issue I am just mentioning them that they are relatively easy to replace and they often create issues. Unlike bigger caps on newer boards bulging might not be apararent, but chances are there would be stability issues with 386 too if they were bad.

I'd also try to underclock the DLC down to 25-33 MHz. Not sure if there is a setting to switch the L2 cache to write-through mode, if there is I'd try that. You might try to use a BIOS from a different UMC481 motherboard. The BIOS update is unlikely to help on its own, but might give you a few extra troubleshooting options compared to the modest Mr. BIOS.

If tried everything you could (settings, jumpers, swapping parts incl. different PSU) and still no luck, it might be that the motherboard is just not compatible with 486DLC. Not all problems have a solution. I'd just use it with your 386DX (or keep L2 disabled) and move to another project 😀 486DLC is known to be problematic.

Thanks for the tips, I'll see what I can apply to my case and hopefully make heads or tails of this situation.

The "M351" print on the BIOS ROM chip reminds me of PCChips, though Google gives me almost nothing about it.

Board is here: http://www.win3x.org/uh19/motherboard/show/5409

... but there's not much on it other than cache and memory settings.

You will need to experiment with multiple sets of sram chips.
Also find the right order in which they work. This also matters !
Been there seen that many times.
Don't assume that too much with that old junk 😀

Thanks for the help, but I'm afraid I don't quite understand what you mean by the above. Do you think it would be a good idea to replace the SRAM chips, even though they seemed to run 100% fine when using the Intel 386 at 40MHz?
What do you mean right order? How would I be able to figure that out?