Garrett W wrote on 2021-04-21, 08:42:

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?

Usually 20ns chips are not fast enough to run at 40MHz with 0WS. You need 15ns, and preferably a 12ns tag chip as well - it all depends on the chipset and quality of signal routing. Some mobos might even need 10ns, especially if you intend to populate both banks. This BTW might not be a good idea, you gain a little but possibly loose a lot by having to go +1WS. Though CPUs with on-die cache tend to gain more from bigger (even if slower) external cache then 386.

You got lucky with 386, the SRAM chips are probably much better than 20ns and the access patterns are way diffgerent (386 will mostly fetch code while DLC chips, even with their small cache, can do semi-random data fetches while in a loop - can't quite recall the numbers but 1kB is already over 80% hit rate). That being said with elevated temperature even that 386 will eventually glitch and crash, maybe you didn't test it long/hard enough to notice.

Appreciate the suggestion, but I think this would put me on a wild goose chase. I've already tried the slowest possible wait states (3WS I believe) and the crashes and divide by zero errors kept appearing with the same frequency. On the 386, these issues never materialized and I had that running Doom for hours to test stability. I'll see if I can get a fan blowing towards the SRAM chips just in case.

As a last measure, I'll try some known good cache chips from another board, although I'd prefer to avoid that due to the hassle.

I am working through a similar situation. I have a MICROMATION TECHNOLOGY, INC. 80386-WBH (http://www.win3x.org/uh19/motherboard/show/3688) motherboard with the OPTi 82C391/392 WB chip set. It came with 64Kb WB motherboard cache. Benchmarked it when I found it and the 64Kb cache was working.

I upgraded it to MR BIOS and it posted & booted. I was upgrading a couple boards that day and didn't really investigate too deeply because I had other boards that were being more fussy about MR BIOS.

Later I tried to upgrade the cache to 256MB and it didn't detect. I tried putting the 64Kb cache back in place and it wasn't stable. It would post with the most relaxed timings but was not stable. I thought I may have ordered the wrong sram & ruined the 64kb chips with a dry January ESD, but I had been careful. There was definitely a drop off in performance without the motherboard cache, which made me unhappy.

When a good price showed up on SRAM in February, I bought a second set of SRAM chips for a 256Kb cache, but it was from China and took a 10 weeks to arrive.

In the meantime, I sold a pair of spare AM5x86 P75 chips and used the proceeds to get a 486DLC chips from Czech. It works, but it's hot and I was not able to get the L1 or L2 to work with it

The second set of SRAM arrived, but I cannot get it to detect either, so I don't think it is related to the chips.

When looking at the pins after changing the jumpers, I noticed that pin 3 for both JP7 and JP10 looked low. Checking the back, looked like there was damage.

Seems like the middle pins on the jumpers connect to the IC labeled P9236 / DM74LS244N or the tag ram
Seems like the 1 & 3 pins on the jumpers connect to the OPTi F82C206L chip through RP10

Except for the ones that look damaged
JP7 -Pin3 (disconnected )
JP10-Pin3 (ground)
I started to clean out the post hole for JP10 Pin3, but I'm worried that I'm making things worse and I don't need JP10-Pin3 unless I am doing a 32K cache, so as long as it's not causing a damaging short, maybe I can leave it as is.

I need JP7 -Pin3 to be connected. The trace from JP7 -Pin3 goes to a via and JP3 pin3 is not connected to the via, so there a break in there. The via connects to the CPU (Pin L13 if I'm counting things correctly)

I'd remove the coprocessor for testing. I never had issues with my Cyrix FasMath and 386DX or DLC CPUs (both original Cyrix and Ti ones - and AFAIR the very early Cyrix DLCs had issues with NPUs that were later fixed) but I did have hangs with Ti SXLC and GREEN MATH 4C87SLC-40. The same NPU has no issues working with 40MHz 386SX. I have no idea if it's a mobo, CPU or NPU issue but clearly there is something going on.

So before you rework the whole cache area remove the coprocessor and test again - could be it's the culprit.

Please listen to everyone: DO NOT, I repeat do not buy any semiconductors from Chinese source! They are bogus as you seen that happen and had happened to others as well. I purchased more than 5 semiconductors types including memory chips, ampifier IC etc and they were not working or extremely low quality, pins cannot be soldered or broken off so easily.

Get quality cache chips from anyone else. You will need to source 8 x 32K x 8 bit of known brands like Winbond, etc at 15ns, If yiou can get 12ns tag chips do so. The one you have are not good one.

Doing properly does cost some money, this will help much and you will not usually be disappointed and actually saves time and money in long run.

Cheers,

pentiumspeed wrote on 2021-04-21, 20:07:

Please listen to everyone: DO NOT, I repeat do not buy any semiconductors from Chinese source! They are bogus as you seen that happen and had happened to others as well. I purchased more than 5 semiconductors types including memory chips, ampifier IC etc and they were not working or extremely low quality, pins cannot be soldered or broken off so easily.

I agree that there are some spotty vendors out there and I'm sorry to hear that you have had bad luck. However I've had good luck with this vendor so far. Seems like he's trying to build a legit business and keeps communication open. I tested the chips in another board and they seem like good W24257AK-12 32K X 8 SRAM.

W that's winbond. Good chips.

Cheers,

Well, what do you know. I pulled off some 15ns cache from my 5x86 system and replaced the one on the 386 board. It seems to run mostly fine now, able to complete benchmarks such as Quake which it couldn't before (or could but with graphical errors). I've had an odd hiccup once , but I'd say that's down to something else and honestly not sure if it is even worth looking into.

So, lesson learned I guess? I'm not sure what the lesson was though. What an odd thing, to have the cache work just fine on one processor and then on another crap out so spectacularly. I guess the 486DLC really does do things very differently. In any case, the question now becomes whether or not I want to keep it at 128K or grab the rest of that cache and go all the way up to 256K!

It's mostly down to access patterns, which will be different if the CPU has on-chip cache enabled. Again, keep in mind going to 256k will require even faster chips, especially for tag RAM. Oh and for the fun of it you can try to keep the 20ns in the bank but just replace the tag with 15ns and see if that works. If it does, even if it's less stable than all-15ns set, you know you need a fast tag above all - which is usually the case.

I was able to get the motherboard cache working again on my 386 mobo with OPTi 82C391/392 WB chipset.

I had two issues.
1) The board works with 8x8 cache chips, but they only work with the AMI bios that came with the board. MrBios detects the cache when I use 8x8 cache chips, but locks after the POST mem test, whether I use the 486DLC or a AMD386-40 CPU.
2) The board doesn't work with 32x8 cache chips right now. Mr Bios doesn't detect any motherboard cache when using 32x8 chips. The vendor AMI bios locks after the POST mem test when I enable the cache and configure it to use 32x8 chips in the BIOS. Jumpers for configurations that use 32x8 chips require bridging pin 3 on J7. There is trace damage on the bottom of the board for that pin. Tried to patched the trace with Floppy motor wire, (my first trace fix attempt that's longer than 1mm) but no luck so far. I'd still like to get the bigger cache working, but I don't want to risk breaking the board until I finish this round of testing.

I'm testing with 32MB Ram, generic multi/io controller and an ISA ATI Mach64 (109- 19301-10)

Notes:

• Graphics modes were a mess when I ran Cyrix.exe with "-f -i1" so I switched to : -f -m- -xA000,128 -xC000,256 and things looked better.
• The system wasn't able to run Doom for more than a few seconds with the Ti486DLC chips when the mobo cache was enabled. Doom + mobo cache + DLC = doom.
• The system has halted with parity errors twice randomly under dos when using the Ti486DLC processor. Once when trying to rename a file. Both times it happened after warm boots.
• I have not seen any parity errors with the AMD386-40 processor. That's been very stable. Benchmarks suggest that the Mobo cache is working in WB mode.
• Speedsys doesn't see the Cyrix cache. Memory Speeds are for main memory or mobo cache if enabled.

1CPU        Mobo   Cyrix  Doom   Speedsys   Read  Write   Move    Avg
2           Cache  Tool  Realtik CPU Index  MB/s   MB/s   MB/s   MB/s
3Ti486DLC    No    No     32338    9.51    14.86  21.19   9.36  15.14
4Ti486DLC    No    Yes    12809    9.51    14.86  21.19   9.36  15.14
5Ti486DLC    Yes   No     Crash    9.85    29.77  21.19  24.71  25.22
6Ti486DLC    Yes   Yes    Crash    9.83    29.77  21.19  24.71  25.22
7AM386-40    No    N/A    30890    4.48    13.55  21.29  10.62  15.15
8AM386-40    Yes   N/A    12750    6.76    24.87  21.28  36.98  27.71

Using 386-40 w/ Mobo Cache: (Looks like the cache is working in WB mode)

Using 486DLC + Cyrix.exe w/ Mobo Cache: (Does not look like cache is in WB mode any more)

Using 486DLC + Cyrix.exe w/o Mobo Cache: (reports a high memory bandwidth number, not reflected in the cache stairs graph)

My attempt at a trace fix:

All the signals around the cache SRAMs are very fast and sensitive to (otherwise not that important) stray inductance, capacitance, and too high resistance. So a wire repair in that area must be done in a specific way - as short as possible. Preferably just a bridge over the break in the copper with a short piece of wire soldered over the unmasked trace. Sometimes you can even get the solder to just bridge the gap, but that has to be a very clean and short gap.

If, for some reason, you can't get it repaired that way, another method would be a longer point-to-point wire like yours but with careful consideration on how to route it to make it short, preferably following the original trace. And before you solder it, you cut the bad trace off completly, on both sides, so that the remains will not act as a small capacitor.

Deunan wrote on 2021-04-26, 19:58:

All the signals around the cache SRAMs are very fast and sensitive to (otherwise not that important) stray inductance, capacitance, and too high resistance. So a wire repair in that area must be done in a specific way - as short as possible. Preferably just a bridge over the break in the copper with a short piece of wire soldered over the unmasked trace. Sometimes you can even get the solder to just bridge the gap, but that has to be a very clean and short gap.

Thanks for that advice on traces. Since this one was connected to a jumper block, I figured it might have wider tolerances, but I'm not happy with the trace repair, so I'll go for shorter like you suggest.

I found this post that lead me to a newer MR-BIOS ( 1.65 vs 1.3): Re: How about a MR-BIOS ROM file repository?

These looked like good candidates:

• V020B324 OPTi 82C391 - 386 WriteBack Revs A,B
• V020B32E OPTi 82C391 - 386 WriteBack x020B324 (T-)
• V020B32F OPTi 82C391 - 386 WriteBack x020B324 (T+)
• V020B32G OPTi 82C391 - 386 WriteBack x020B324 (CL-)
• V020B32H OPTi 82C391 - 386 WriteBack x020B324 (CL+)

I chose the first one because I have a rev B1 chipset. I'm assuming they are talking about chipset revisions there. Anyone have any guesses what the others are for?

Anyway, the BIOS is from 1994 and knows about Ti486DLC chips, which was promising.

Using MR Bios, I was able to get the Cyrix working with write back cache, but it wasn't completely stable and it looked like cache coherency issues.

I grabbed the cyrix.exe parameters from this thread: Re: 486DLC internal cache and Speedsys

1cyrix.exe -e -b -m- -xA000,128 -xC000,256

And we are running DOOM @ 7634 realtics, no crashes! Huge improvement. Almost playable. I'll get the bench marks and cache stairs posted later. Note-- the Doom realitcs are boosted quite a bit by taking the ISA bus to 10MHz.

The Cyrix chip that I have runs really hot. I'm going to out fit it with a heat sink.

Here's the results with the MR Bios, 0 wait state memory, and 10mhz ISA bus. Looks like the motherboard cache is in write back mode because the move speed is so high.

Here's the results with the MR Bios, 0 wait state memory, 10mhz ISA bus, and the Cryix tool. Looks like cyrix.exe disabled the writeback cache somehow because the move speed drops, but maybe the move speed drops because of the BARB cache flush.

douglar wrote on 2021-04-27, 21:03:

I found this post that lead me to a newer MR-BIOS ( 1.65 vs 1.3): Re: How about a MR-BIOS ROM file repository?

Can you link to that v1.65 82C391 MR BIOS image? I've dug through that thread and can only find the early one; I'm currently debugging my PC-CHIPS M321 with the v1.30 file, but I'd prefer to use the later one if at all possible.

douglar wrote on 2021-04-28, 00:22:

Looks like cyrix.exe disabled the writeback cache somehow because the move speed drops, but maybe the move speed drops because of the BARB cache flush.

BARB is the last-ditch option when the mobo doesn't support anything else (and that can be verified by checking if the extra CPU pins are actually connected to chipset or not - I have U4800 based mobo that has some nice BIOS options but in reality only one configuration works).
Problem with BARB is it can trigger on memory refresh cycles, which happen so often that not only it negates the cache, it actually lowers CPU performance because full cache flush is not a free operation. If you have to use BARB see if your BIOS offers option called hidden refresh. If so, enable it.

As for the Cyrix CPU running hot, it does but usually doesn't go above some 65C (certainly below 70C with 25C ambient temp). It should be fine, but some extra cooling will not hurt.

EDIT: Oh and one option that my mobo has, but doesn't work with Cyrix and Ti chips, is fast A20 gate. So turn that off if you have cache issues since it most likely means the gate mask signal is not routed to the CPU.

megatron-uk wrote on 2021-04-28, 08:47:

Can you link to that v1.65 82C391 MR BIOS image? I've dug through that thread and can only find the early one; I'm currently debugging my PC-CHIPS M321 with the v1.30 file, but I'd prefer to use the later one if at all possible.

I put @jheronimus bundle of MRBIOS files here: http://vogonsdrivers.com/index.php?catid=77&menustate=32,29
His list of bios is here: https://docs.google.com/spreadsheets/d/1rClAW … k-HA/edit#gid=0
And this post covered the different revisions with Re: Chipset datasheet for M321 (PC Chips)
(T+/-) = Different Turbo settings
(TL+/-) = Different TurboLight settings
(CL+) = Different CacheLight settings
V1.65 is nicer. Supports drives > 528MB.

Can't really comment on most of this, but regarding the heat I too did not feel comfortable with it. It was unbearable to touch. I initially added a heatsink, which I felt was getting a bit too hot as well, so I stuck a fan as well. It's a bit noisy, but the 1GB HDD already takes care of covering most of that, so it is no biggie! The CPU is now at room temperature I would say.

douglar wrote on 2021-04-28, 13:07:

I put @jheronimus bundle of MRBIOS files here: http://vogonsdrivers.com/index.php?catid=77&menustate=32,29 His list of bios is […]
Show full quote

megatron-uk wrote on 2021-04-28, 08:47:

Can you link to that v1.65 82C391 MR BIOS image? I've dug through that thread and can only find the early one; I'm currently debugging my PC-CHIPS M321 with the v1.30 file, but I'd prefer to use the later one if at all possible.

I put @jheronimus bundle of MRBIOS files here: http://vogonsdrivers.com/index.php?catid=77&menustate=32,29
His list of bios is here: https://docs.google.com/spreadsheets/d/1rClAW … k-HA/edit#gid=0
And this post covered the different revisions with Re: Chipset datasheet for M321 (PC Chips)
(T+/-) = Different Turbo settings
(TL+/-) = Different TurboLight settings
(CL+) = Different CacheLight settings
V1.65 is nicer. Supports drives > 528MB.

Top stuff! Thanks!

douglar wrote on 2021-04-28, 13:07:

I put @jheronimus bundle of MRBIOS files here: http://vogonsdrivers.com/index.php?catid=77&menustate=32,29 His list of bios is […]
Show full quote

megatron-uk wrote on 2021-04-28, 08:47:

Can you link to that v1.65 82C391 MR BIOS image? I've dug through that thread and can only find the early one; I'm currently debugging my PC-CHIPS M321 with the v1.30 file, but I'd prefer to use the later one if at all possible.

I put @jheronimus bundle of MRBIOS files here: http://vogonsdrivers.com/index.php?catid=77&menustate=32,29
His list of bios is here: https://docs.google.com/spreadsheets/d/1rClAW … k-HA/edit#gid=0
And this post covered the different revisions with Re: Chipset datasheet for M321 (PC Chips)
(T+/-) = Different Turbo settings
(TL+/-) = Different TurboLight settings
(CL+) = Different CacheLight settings
V1.65 is nicer. Supports drives > 528MB.

Just a quick note to say that v1.65 BIOS (the TL+ version) works on my M321 (rev 2.7) board. Thank you!

I'm pretty happy with how this all turned out. The MrBios 1.65 make this all workable / stable since it knows about Cyrix 486DLC chips. Interesting to note that it disables the on chip cache during boot, which the AMI BIOS and MrBios 1.3 did not do, so it was important for me to include "-e" on the cyrix command line.

My CPU runs at 70c in a 20c room under load, which is pretty hot. The Am386 never breaks 40c.

I'm using this for the time being: c:\cyrix\cyrix.exe -e -xA000,128 I'll try a windows 9x install later and see how it goes.

I was able to make the 256KB cache work. Turns out that the new SRAM chips didn't agree with this board. The chips that I bought last winter worked after patching the J7 trace. Here are the chips that worked:

Notes:

• Doom scores with an * at the end would lock up sometimes after completion. Doesn't look like I'll be using the -a switch
• -f (Flush) and -b (Barb) perform the same for me, but I do have hidden refresh enabled in the BIOS
• -m- causes a mild performance decrease in some areas and I don't seem to need it in DOS
• -k (Ken) performed worse than no on chip
• Any mobo cache has a bigger impact on performance than expanding the Mobo cache. I think that's commonly known these days.
• The mobo cache had significantly larger impact on the Cyrix chip than it did on the AMD when the internal cache was turned off. Still pondering this one
• The mobo cache had a bigger impact on the Cyrix performance in DOOM than the internal 1KB cache did . Doom has larger data sets, I guess?
• All bench marks are with MrDos 1.65, Hidden Refresh, 0 wait states, 10Mhz ISA bus
• There are a couple places where increased memory bandwidth is associated with reduced benchmark scores. Not sure why that is either.

1CPU        Mobo    Cyrix   Doom    Speedsys   Read   Write   Move    Avg
2           Cache   Tool  Realtics  CPU Index  MB/s    MB/s   MB/s   MB/s
3Ti486DLC   256KB  -e -b     6830    10.29    30.63   37.48  25.53  31.21
4Ti486DLC   256KB -e -b -m-  6911    10.29    30.63   37.48  25.53  31.21
5Ti486DLC   256KB  -e -a     6911*   10.29    30.63   37.48  25.53  31.21
6Ti486DLC   32KB   -e        7615    10.20    30.55   37.47  25.48  31.16
7Ti486DLC   32KB   -e -b     7616    10.20    30.54   37.47  25.48  31.16
8Ti486DLC   32KB   -e -f     7617    10.20    30.54   37.47  25.48  31.16
9Ti486DLC   32KB   -e -a     7636*   10.20    30.54   37.47  25.48  31.16
10Ti486DLC   32KB  -e -b -m-  7636    10.20    30.54   37.47  25.48  31.16
11Ti486DLC   32KB   -e-       9981     9.47    30.55   37.46  38.16  35.39
12Ti486DLC   32KB   -e -k     9998     9.46    30.55   37.46  30.55  32.85
13Ti486DLC   No     -e       10550     9.88    18.57   37.05  13.48  23.04
14AM386-40   256KB  N/A      10600     6.88    25.53   30.07  38.30  31.30
15AM386-40   32KB   N/A      11140     6.88    25.47   30.05  38.16  31.23
16AM386-40   No     N/A      23654     5.19    16.53   29.87  16.49  20.96
17Ti486DLC   No     -e-      25448     5.76    18.57   37.05  16.49  24.03