VOGONS


Reply 20 of 48, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 21 of 48, by Garrett W

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 22 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie

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)

The attachment Photo Apr 21, 12 47 58 PM.jpg is no longer available
The attachment Photo Apr 21, 12 26 37 PM.jpg is no longer available

Reply 23 of 48, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 24 of 48, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

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,

Great Northern aka Canada.

Reply 25 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 26 of 48, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

W that's winbond. Good chips.

Cheers,

Great Northern aka Canada.

Reply 27 of 48, by Garrett W

User metadata
Rank Oldbie
Rank
Oldbie

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!

Reply 28 of 48, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 29 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie

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.
CPU        Mobo   Cyrix  Doom   Speedsys   Read  Write   Move    Avg
Cache Tool Realtik CPU Index MB/s MB/s MB/s MB/s
Ti486DLC No No 32338 9.51 14.86 21.19 9.36 15.14
Ti486DLC No Yes 12809 9.51 14.86 21.19 9.36 15.14
Ti486DLC Yes No Crash 9.85 29.77 21.19 24.71 25.22
Ti486DLC Yes Yes Crash 9.83 29.77 21.19 24.71 25.22
AM386-40 No N/A 30890 4.48 13.55 21.29 10.62 15.15
AM386-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)

The attachment 386-CACH-ConvertImage.png is no longer available

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

The attachment TOOL1-ConvertImage.png is no longer available

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

The attachment TOOLNOL2-ConvertImage.png is no longer available

My attempt at a trace fix:

The attachment Photo Apr 26, 7 35 31 AM.jpg is no longer available

Reply 30 of 48, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 31 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie
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

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

Last edited by douglar on 2021-04-28, 00:28. Edited 1 time in total.

Reply 32 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie

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.

The attachment MR-ConvertImage.png is no longer available

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.

The attachment MRTOOL-ConvertImage.png is no longer available

Reply 33 of 48, by megatron-uk

User metadata
Rank Oldbie
Rank
Oldbie
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.

My collection database and technical wiki:
https://www.target-earth.net

Reply 34 of 48, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 35 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 36 of 48, by Garrett W

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 37 of 48, by megatron-uk

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

My collection database and technical wiki:
https://www.target-earth.net

Reply 38 of 48, by megatron-uk

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

My collection database and technical wiki:
https://www.target-earth.net

Reply 39 of 48, by douglar

User metadata
Rank Oldbie
Rank
Oldbie

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:

The attachment Photo Apr 28, 3 10 54 PM.jpg is no longer available

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.
CPU        Mobo    Cyrix   Doom    Speedsys   Read   Write   Move    Avg
Cache Tool Realtics CPU Index MB/s MB/s MB/s MB/s
Ti486DLC 256KB -e -b 6830 10.29 30.63 37.48 25.53 31.21
Ti486DLC 256KB -e -b -m- 6911 10.29 30.63 37.48 25.53 31.21
Ti486DLC 256KB -e -a 6911* 10.29 30.63 37.48 25.53 31.21
Ti486DLC 32KB -e 7615 10.20 30.55 37.47 25.48 31.16
Ti486DLC 32KB -e -b 7616 10.20 30.54 37.47 25.48 31.16
Ti486DLC 32KB -e -f 7617 10.20 30.54 37.47 25.48 31.16
Ti486DLC 32KB -e -a 7636* 10.20 30.54 37.47 25.48 31.16
Ti486DLC 32KB -e -b -m- 7636 10.20 30.54 37.47 25.48 31.16
Ti486DLC 32KB -e- 9981 9.47 30.55 37.46 38.16 35.39
Ti486DLC 32KB -e -k 9998 9.46 30.55 37.46 30.55 32.85
Ti486DLC No -e 10550 9.88 18.57 37.05 13.48 23.04
AM386-40 256KB N/A 10600 6.88 25.53 30.07 38.30 31.30
AM386-40 32KB N/A 11140 6.88 25.47 30.05 38.16 31.23
AM386-40 No N/A 23654 5.19 16.53 29.87 16.49 20.96
Ti486DLC No -e- 25448 5.76 18.57 37.05 16.49 24.03