Nice! This thread was a fascinating read.

Awaiting pics of the repaired board with all the components in place. 😁

Nice work. You planning to stick an Am5x86-133 in there to see how it runs?

TheMobRules wrote:

Nice! This thread was a fascinating read.

Thanks. I have a bit more repair work to do to finish up. I will catch up the thread with the latest photos and the update that got me to this point soon. I just decided to jump right to testing since I finally reached that milestone. New component list, final words for corrosion-based damage, CMOS battery replacement, click testing, conformal coating are on the way.

feipoa wrote:

Nice work. You planning to stick an Am5x86-133 in there to see how it runs?

Heh. This will go alongside a Pentium 200 MMX that I occasionally disable to cache on using setmul in order to achieve lower speeds. With turbo off on this machine, speedsys doesn't even draw a bar in the speed graph (forgot what the number was). Going to try some native Wing Commander I and only use turbo on/off to see what I can manage (among other games).

But who knows! First up though is to do some disk benchmarking as I have a Goldstar in there right now but found a PROMISE EIDE4030Plus last year that has been chomping at the bit for me to place it in this system! First things first - gotta finish the repairs.

Wow, very good work!

Could you please upload a photo of the repair work with the acrylic lacquer placed over the traces?

And is acrylic lacquer what would have been originally used on this board, or some other form of resin?

Wow, makes me think that my tiny tiny 386 board might be repairable afterall ... Though the corrosion is even worse so I'd need to desolder all the ISA slots 😒

feipoa wrote:

Could you please upload a photo of the repair work with the acrylic lacquer placed over the traces?

Yes. However, I am not at that point yet. I reached a point where I could test, so I hooked things up to see if the repairs were adequate. I am going to build the external battery holder/wire and hook that up next to make sure the CMOS values hold. I may go ahead and hook up a HDD just to put the system through some more paces before doing any sealing. The acrylic coating is easier to undo than silicone, but I would prefer to wait until I have everything as rock solid as possible before sealing it off.

Deksor wrote:

Wow, makes me think that my tiny tiny 386 board might be repairable afterall ... Though the corrosion is even worse so I'd need to desolder all the ISA slots 😒

Go for it! Detail your process on vogons if you could.

Predator99 wrote:

Wow, very good work!

Thanks!

For my 386 mobo, I think I'll start when I'll buy a desoldering station. This should save me up quite some time

Just an update -

I added an external 3xAA battery holder with a series diode on positive. It... kinda works... well, not really.

BIOS values hold for a little while and then start dropping/dying values. Voltage at battery is at 4.89. Voltage after series diode is 4.7x. Voltage after first mobo diode is 4.5. Voltage after second mobo diode is 4.2. That second diode leads to the clear CMOS jumper - a jumper that connects both batteries to CMOS. Pin 3 - or what I'll call the "battery input" pin the clear CMOS jumper reads.... 0.5V. So perhaps a cold solder joint on pin 3 or something. I don't like soldering those little guys. They like to move in and out of their plastic pin block with just a little heat.

Will obviously have to pull the board to fix it. But this is why I am testing before lacquer work.

Secondly - I am sad to report that I am experiencing freezing/graphical glitches/reboots in Wolfenstein 3-D (like 15 seconds) of game play unless I disable external cache. It is my original cache from 1993! Reseating the chips made no difference. Played a level and a half with no cache, and it worked fine.

Memtest86+ is happy. Cachecheck v7, well... <attached>

CkRtech wrote:

Secondly - I am sad to report that I am experiencing freezing/graphical glitches/reboots in Wolfenstein 3-D (like 15 seconds) of game play unless I disable external cache. It is my original cache from 1993! Reseating the chips made no difference. Played a level and a half with no cache, and it worked fine.

Have you tried removing only half of the chips and testing with 128K of L2? It could help narrowing the problem if it is indeed caused by the cache chips.

Did you play with cache and memory wait times? Or try cache from another board?

TheMobRules wrote:

Have you tried removing only half of the chips and testing with 128K of L2? It could help narrowing the problem if it is indeed caused by the cache chips.

Not yet. I multimetered around to track the battery issue and then got memtest and cachechk to the system. I imagine this will be a course of action for the cache.

feipoa wrote:

Did you play with cache and memory wait times? Or try cache from another board?

I didn't mess with the memory wait times much. I used the BIOS/power-up defaults - however, both default sets are AUTO config = enabled. So I think they are 3-2-2-2, Write option: 1 W.S., Wait state: 1 W.S., DRAM Type: FastPage.

I may have another board with cache in the garage somewhere - inside another system. Going to have to start popping lids and peaking inside.

Update -

Jumper-wired the end of the diode series to pin 3 of the clear CMOS block. Values seem to be holding now.

As for the cache/RAM issue - I have no reason to believe this is related to the corrosion damage, but I was hoping to basically have a fully functional system before I put a bow on the repair work (clean up the jumper wires and coat sections of the board with acrylic).

Dropping to 128k worked. Swapping 4x 32k for the previously removed 4x 32k also worked. I did notice that the timings changed when I did the swap, so I reconfigured to 256k and started messing with timings as it appeared the cache itself was at the very least serviceable.

The only way ("lowest") I got it to pass cachechk was 3-2-2-2 0 2. Weird things happened during testing with any instance of 3-1-1-1, and 3-2-2-2 1 1 (the recommended/default) is what produces the "Hmm... really slow!" warning for Megabyte #8 - which I assume is what was screwing up Wolfenstein 3-D. Demo loop of Wolf @ 3-2-2-2 0 2 seems to hold up OK. Haven't play tested.

8 MB (1MB x 8 SIMMS) - All should be 70ns. Cache is 20 ns. I do have a set of cache in a computer in the garage that is 15ns.

Cache Read Option: 3-2-2-2
Cache Write Option: 0 W.S.
DRAM Wait State(s): 2 W.S.

You know, now that you mention this, I experienced a similar issue: a few years ago I got a crappy Unichip-based VLB motherboard with a leaking battery. The corrosion wasn't too bad so I cleaned it and it POSTed right away, installed DOS and a few other tools without issue.

Then, when I fired up Doom to see how it ran, I started getting sudden crashes/resets. Swapping the RAM didn't change a thing so I turned to the cache: it had 256K, with 4 chips being 15ns and the other 4 20ns (the tag was 15ns). I managed to get it to work only with conservative cache timings just like you.

Then I decided to replace the 4 20ns chips with 15ns ones I pulled from another board and then it worked with the faster timings without issue. The cache/RAM settings on my board are presented a bit differently from yours, but the values in bold are the recommended "fast" timings from the manual that I only got to work with the 15ns chips:

DRAM Read/Write [0WS, 1WS or 2WS]
SRAM Read [0WS, 1WS or 2WS]
SRAM Burst [Enabled/Disabled]
SRAM Write [0WS, 1WS or 2WS]

Now, according to what I've heard 15ns vs 20ns should make no difference when running at 33MHz bus speed, but in my case it definitely had some sort of impact. So maybe a similar thing is happening to you?

EDIT: also, one more thing regarding the default timings. In one of my 486 boards, cachechk doesn't even detect the cache if I use the "Auto" chipset config from the AMI WinBIOS. Since it's a PCChips, I originally assumed that it had fake cache, but after setting faster timings manually cachechk detected the 256K 🤣

Strange, but - I replaced the 20ns cache with 15ns from another system I had.

128k (4 chips + tag) can run at the faster speed
256k produces the SAME error. Slow at Megabyte 8 (I have 8 MB total at 1MB per SIMM). Slow it down, and it works.

So either there is something odd with my RAM that memtest didn't report, or there is possibly an issue with the 2nd bank of 4 for the SRAM.

I ran cachechk at pretty fast timings on the board I pulled it from, and it was fine.

The manual for this project board is pretty simple. It doesn't give specifics about timing or anything.

The only other combo I could try is to put the 20ns back in and use 15ns for the tag - but nowhere does it state this is necessary, and the other 486 I pulled the cache from ran pretty quick with 9 sticks of 15ns across the board. Hmm...

I have seen cases with 386 boards which claim to support 256 KB, but have all kinds of issues when 256 KB is actually installed. The 386 boards I am thinking of contained a CHIPS chipset. On one brand of the board, I could only get 128 K running reliably. The other, only 64 K. Another user here was only able to get, I think, 128 K running reliably on yet a 3rd brand board with the CHIPS chipset.

So I suppose it is possible that the issue manifest itself on early 486 boards as well.

There may also be incorrect jumper documentation for your 256 K setting. You might have to trace out the traces. I first would start with known good cache. I don't really rely on cachechk's "your X MB memory appears to be slow". The BIOS may have set a cacheless hole where the program is residing. Run Doom timedemo 3 with various configurations and use CTCM and CTCM7 to confirm your cacheable range.

feipoa wrote:

There may also be incorrect jumper documentation for your 256 K setting. You might have to trace out the traces. I first would start with known good cache. I don't really rely on cachechk's "your X MB memory appears to be slow". The BIOS may have set a cacheless hole where the program is residing. Run Doom timedemo 3 with various configurations and use CTCM and CTCM7 to confirm your cacheable range.

Funny enough, my motherboard manual and board do not match up what i have jumpered. I want to say pin 1 is mislabeled in the manual. I tried selecting the jumpers for what the manual says, but it freezes up while drawing the system summary. I have gone with what I have thought are the appropriate settings for it, and that is all that has allowed me to get going. Swapping the jumper config for JP4, JP5, JP6 (2-3, 2-3, Open for 128k and 1-2, 1-2, Closed for 256k) to the 128k seems to have it work fine. So swapping JP4 and JP5 and closing JP6 should be the appropriate config for 256k.

It would be nice if I had a UMC491 pinout or datasheet to work with. A slightly higher possibility if the Internet in 1993 was the same as it is now...

Those UMC chipset datasheets are impossible to find.

OK. So here is what I've got -

With board at 256k and at Cache Write Option: 1 W.S. and DRAM Wait State(s) at 1 W.S. (I think) -

1: CTCM7:

L2 check took forever. I left it at the final L2 message and nothing happened. I assume it froze. Got to thinking about addressing/mapping a bit.

2: Disabed "Memory Remapping" in BIOS, and it made cachechk and Wolfenstein 3-D happy. Lower numbers, no Megabyte 8 really slow warning (well - and it only reported a 0-7 as turning off memory remapping lopped off a couple hundred kilobytes from the memory total at boot). I was happy for about two minutes.

3: Fired up CTCM7 again. Slow and froze again. Extra "+256" went away though. The L1 and L2 ranges also match now.

4: Doom timedemo starts running and gets slower and slower and finally crashes after a little while. At least I can run the cls command to get my prompt back.

I believe this was bypassing all config/autoexec stuff. I also clipped out some extraneous info:

P_Init: Checking cmd-line parameters... Playing demo demo3.lmp. V_Init: allocate screens. M_LoadDefaults: Load system defaults. […]
Show full quote

P_Init: Checking cmd-line parameters...
Playing demo demo3.lmp.
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
DPMI memory: 0x5e2000, 0x5c2000 allocated for zone

ST_Init: Init status bar.
DOS/4GW Professional error (2001): exception 0Dh (general protection fault) at 170:0017AF2D
TSF32: prev_tsf32 6800
SS 178 DS 178 ES 178 FS 0 GS 20
EAX FFFFFFFF EBX FFFFFFFF ECX 1B9700 EDX F40A044
ESI 10 EDI 460 EBP 4 ESP 214B84
CS:IP 170:0017AF2D ID 0D COD 0 FLG 10246
CS= 170, USE32, page granular, limit FFFFFFFF, base 0, acc CF9B
SS= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
DS= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
ES= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
FS= 0, USE16, byte granular, limit 0, base 15, acc 0
GS= 20, USE16, byte granular, limit FFFF, base F7E0, acc 93
CR0: PG:0 ET:1 TS:0 EM:0 MP:0 PE:1 CR2: 0 CR3: 118000
Crash address (unrelocated) = 1:00032F2D

Just for fun - Himem, NOEMS, DOS=UMB:

Playing demo demo3.lmp. V_Init: allocate screens. M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daem […]
Show full quote

Playing demo demo3.lmp.
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
DPMI memory: 0x582000, 0x562000 allocated for zone

ST_Init: Init status bar.
DOS/4GW Professional error (2001): exception 0Eh (page fault) at 170:00491362
TSF32: prev_tsf32 6800
SS 178 DS 178 ES 178 FS 0 GS 20
EAX 302 EBX 8 ECX 1 EDX 3C5
ESI F6CDB6F EDI A8021 EBP 6CDB38 ESP 524B58
CS:IP 170:00491362 ID 0E COD 0 FLG 10206
CS= 170, USE32, page granular, limit FFFFFFFF, base 0, acc CF9B
SS= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
DS= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
ES= 178, USE32, page granular, limit FFFFFFFF, base 0, acc CF93
FS= 0, USE16, byte granular, limit 0, base 15, acc 0
GS= 20, USE16, byte granular, limit FFFF, base 5C70, acc 93
CR0: PG:1 ET:1 TS:0 EM:0 MP:0 PE:1 CR2: F6CDB6F CR3: 8000
Crash address (unrelocated) = 1:00039362

There are two cards in the system right now - a 16-bit I/O card and a VLB Diamond Stealth 24. Memory remapping is disabled, F Segment Shadow RAM and Shadow RAM from C000-C3FF,C400-C7FF is cached. The rest are disabled.

Whatever knowledge I had of troubleshooting this particular issue is about 25 years old now, so I am open to suggestions.

EDIT. CTCM7 -

XMM not installed ! CTCM uses Memory from address 00120000 Int15-Memory=7340032 […]
Show full quote

XMM not installed !
CTCM uses Memory from address 00120000
Int15-Memory=7340032

CTCM, translated by Thomas Pabst, copyright ct-Mag. V1.5b/t2
Processor-Timing : i486SX
Processor CPUID : i486SX/ Typ:00 Fam:04 Mod:02 Stp:03
Clck : 33.3 MHz
internal Bus : 32 Bit between CPU and primary Cache or Memory
FPU : not found or unknown
L1 Cache : 8 KByte,4-way associative
L2 Cache : 256 KByte, direct mapped
Write Strategy L1 : Write Thru
Write Strategy L2 : Write Back
Dirty Tag L2 : n/a

Through Put & Bus Performance: Main Memory from 00120000

Best Time for 8K MOVSD (Cache /Page Hits) : 191 mcs - 42.9 MByte/s
average t. for 8K MOVSD (Miss + Hit) : 371 mcs - 22.1 MByte/s
average t. for 8K MOVSD (if clean) : 657 mcs - 12.5 MByte/s
average t. for 8K MOVSD (if dirty) : 656 mcs - 12.5 MByte/s
Main Memory 8K MOVSD (Cache misses) : 886 mcs - 9.2 MByte/s

average with 256 KB L2-Cache /DOS (640K) : 446 mcs - 18.4 MByte/s
average with 256 KB L2-Cache /WIN (4M ) : 630 mcs - 13.0 MByte/s

CTCM7 will always hang on a 486 after finising up the check for L2 cache area. What I wanted to see was if all your RAM was cached and it does not appear to be. The L1 and L2 cache range for RAM are really odd. Something is up. Try re-running CTCM7 with 128 KB cache. Note that CTCM (not 7) will run fine on a 486, but it doesn't check to see what range in RAM is being cached.

Your symptoms remind me of the CHIP board not working well with 256K.

On these early 486 boards and 386 boards, the CMOS settings can be a bit difficult to optimise. I've seen one which had its ISA clock speed divisor reversed as determined by an oscilloscope.

You mentioned you have a VLB graphics card. Is there a jumper for "Delay" and "No Delay" concerning VLB? ALso a jumper for 0 WS and 1 WS? I noticed this is sensitive on VLB systems. I would recommend using all ISA for the time being.