VOGONS


First post, by Garrett W

User metadata
Rank Member
Rank
Member

Greetings!

2020 was a very rough year. However, if there's one positive aspect of it that I can find is that I got infected by the retro virus once again. Well, my wallet would have a different saying on that, but the free time/boredom chart showed a definite rise to unprecedented levels. In October, some family friend gave me 5-6 old PCs, including 486 systems with which I had never toyed around much, so I started diverging into even older systems, culminating in a search for a 386. So, somewhat recently I finally got my very own system, here are the specs:

Intel 386DX-33
UMC 82C481BF + 82C482AF based mainboard with Mr.BIOS EEPROM and 128K 20NS cache
8MB RAM
Goldstar Prime 2C for my I/O needs
Cirrus Logic GD5422 1MB
Opti 82C929A
3Com Etherlink III
Slow 1GB HDD (couldn't get my CF2IDE adapter going on this MB 🙁 )

I was running this system with zero issues at 40MHz, but then I hit them E-Bays and quickly bought a Cyrix based TI486DLC40 along with a Cyrix FasMath-33 (couldn't find a 40Mhz part), because why the hell not? I had heard that sometimes BIOSes might have issues enabling the L1 cache on the 486DLC CPUs, but I had never stumbled upon all the other issues that came with it. As such, since installing the chip, I've had a ton of issues and instabilities. Initially, I thought the FPU was to blame, what with the overclock and everything, but seeing as the same issues persisted even after its removal...
I'm using the most aggressive settings and timings possible in the BIOS, which were perfectly stable on the 386DX, so I thought perhaps something had to give, so I went ahead and used the absolute worst settings on everything, just to be sure. No difference. Then I read a bit on cache coherency with the L1 and L2 caches and it all started to make sense. As soon as I disabled both caches, everything ran fine, but of course performance is nowhere near where it should be. At this point, even enabling L2 cache solely will cause a crash or divide by zero error sooner or later.

I've tried a few utilities and suggestions seen in the forum, but I gotta admit I'm a bit in over my head, so I just cleaned my autoexec and config files to the way they used to be, made sure my Win3.11 setup was clean as well and will present them to you attached at the bottom. Any suggestions that should work for most systems that I could try on mine? Any help would be appreciated, as this system is a speed demon compared to similar ones online, I'm getting some real satisfaction from this 😜. Just for fun, here are some indicative scores from Phil's suite, from the tests I managed to complete with L1 and L2 cache enabled, even for a short while:

3DBench : 24.3 fps
PCPlayer : 6.2 fps
Doom (using FastDoom): 13fps
TopBench: 117 marks

Attachments

Reply 1 of 48, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

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).

Blog|NexGen 586|S4

Reply 2 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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:
file.php?id=44505&mode=view

Could that option be of any use?

Reply 3 of 48, by Tiido

User metadata
Rank Oldbie
Rank
Oldbie

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.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 4 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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 🙁

Reply 5 of 48, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

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....

Blog|NexGen 586|S4

Reply 6 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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".

Reply 7 of 48, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 8 of 48, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie

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).

Reply 9 of 48, by Garrett W

User metadata
Rank Member
Rank
Member
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!

Reply 10 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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.

1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg system-2.jpg system.jpgimg-20201211-174159949-hdr-5fd3f9aeadaed355867474.jpg

Attachments

Reply 12 of 48, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

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.

Blog|NexGen 586|S4

Reply 13 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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.

Reply 14 of 48, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

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.

Blog|NexGen 586|S4

Reply 16 of 48, by th1r5bvn23

User metadata
Rank Newbie
Rank
Newbie

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

AMD K6-2+ 500, FIC PA-2013 2.0 (1MB cache), 128MB SDRAM PC100, Voodoo3 3000 AGP, Labway Yamaha YMF719B-S with NEC XR385
AMD Athlon 64 3000+, ECS K8M800-M3, 512MB DDR 400, GeForce FX 5200, SoundBlaster Live! SB0060

Reply 18 of 48, by pshipkov

User metadata
Rank Member
Rank
Member

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 😀

retro bits and bytes

Reply 19 of 48, by Garrett W

User metadata
Rank Member
Rank
Member

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?