Alright, so I believe I've resoldered all the through hall parts. Except the ISA ports....based on the fact that it was locking up with NO cards at all on it, I did not do them, and did not do the memory lines yet either. Have not touched surface mount at all.

So now...it's the same or similar to before and I've got a little more info:
1) if I enable cache, it seems to lock up pretty quickly. Plan is to test the cache chips and possibly try with some spares..more testing needed here
2) with cache disabled....it seems to be able to run for long periods stably. Although I haven't tried gently pushing on the board again, etc. to see if the issues come back. Just my initial impression.
3) With cache disabled, I've had instances where I had to reboot the machine and the POST card gets stuck at 12/13 again. More resets do NOT fix this. However, a cold boot fixes it immediately (i.e. ~10 second delay from on->of->on).

So for the warm boots....it seems like something is not quite resetting as it should. I'm not exactly sure what happens on a hardware level for a warm boot so not sure where to look.

Cache I will look into soon. Would that just be the 4 cache chips + the TAG or are there any other parts involved in that?

Still working on this. Working on mapping out the cache to see how it's wired to make sure it's wired correctly.

No change in basic behavior on the board. With cache disabled it seems to work fine (other than occasionally hanging at BIOS test 0x13)

I have tested the cache that came with the board on my TL866 and it seems fine. I have also pulled two other cache chips (all 15 ns) from some other boards and tested it on the board and get "almost" the same behavior. With one set of cache chips I got the BIOS reported "CACHE MEMORY BAD, DO NOT ENABLE CACHE!". However, the other 2 sets do not get that error. All 3 however are not at all stable.

Any recommendations to track down why the cache seems to be having issues? I have a scope but lack the experience to know what to look at unfortunately.

I'm not sure why the one set of cache gives me the BIOS error message but the others don't. To the best of my knowledge that particular cache is good but maybe it does actually have an issue.

According to the chipset documentation 15 ns should be the correct cache speed for this board running at 40 MHz. https://theretroweb.com/chipsets/376

Warm boot will skip things like memory sizing, refresh setup, any chipset and cache-specific setup as well. But that would point more to a RAM problem than cache.

If the mobo mostly works with cache disabled run GoldMemory or older version of memtest86 from bootable floopy. Let it do 2-3 full passes, this way you can be reasonably sure the RAM is good and the CPU to RAM bus is also OK. Which would leave you with the cache. Could be the chips degraded or are fake and not 15ns. The TAG is most sensitive so put in there known good chip or you will end up very confused.

If the no-cache RAM test passes try with cache enabled. Obviously any errors found now could be either RAM or cache, probably the latter. I found Doom is also a very good cache tester, it will freeze pretty quickly when left in attract mode if the cache is bad or the timings are set too aggresively.

Deunan wrote on 2025-01-20, 23:55:

Warm boot will skip things like memory sizing, refresh setup, any chipset and cache-specific setup as well. But that would point more to a RAM problem than cache.

If the mobo mostly works with cache disabled run GoldMemory or older version of memtest86 from bootable floopy. Let it do 2-3 full passes, this way you can be reasonably sure the RAM is good and the CPU to RAM bus is also OK. Which would leave you with the cache. Could be the chips degraded or are fake and not 15ns. The TAG is most sensitive so put in there known good chip or you will end up very confused.

If the no-cache RAM test passes try with cache enabled. Obviously any errors found now could be either RAM or cache, probably the latter. I found Doom is also a very good cache tester, it will freeze pretty quickly when left in attract mode if the cache is bad or the timings are set too aggresively.

Thanks for the info!

I'm running an older version of memtest86 from floppy.

With cache disabled...it will run for hours without issues.

With cache enabled. It dies pretty quickly (sometimes not even booting correctly), sometimes getting into it about 60 seconds.

I tried changing the cache wait states and other settings to slow things down to see if that helps, it does not. No apparent change in behavior with cache enabled.
Memory Read Wait State: 2 WS
Memory Write Wait State: 2 WS
Cache Read Cycle: 3-2-2-2
Cache Write Wait State: 2 WS

I have tried 3 different sets of cache (2 of which I use in other machines without issues).

I've been poking around with my scope looking at signals and see a few things that seem odd to me at least. Of course I don't have a lot of experience with digital circuits so it's possible this is completely normal?
1) On one of the cache chips (not the TAG), the CS# line is only ever reaching maybe 3.6-3.7 volts before leveling off. I was expecting closer to 5.

2) Same chip, line A4 is heading towards 5 volts on occasion but doesn't make it (switches back to ground quickly apparently). Although it does sometimes get a peak and go to 5 volts. But seems odd to me to look like that.

I've got some more images, but didn't want to spam while I'm still digging around trying to understand what is happening.

Poke around at the passives.
Bad resistor? Bad cap?

Did you receive the motherboard with U21 (TAG?) as a 32kx8 chip? The diagram on the motherboard (near QC OK sticker) indicates it should be an 8kx8 chip.

Maybe the TAG is the wrong type?

Guld wrote on 2025-01-21, 02:17:

I'm running an older version of memtest86 from floppy.

With cache disabled...it will run for hours without issues.

With cache enabled. It dies pretty quickly (sometimes not even booting correctly), sometimes getting into it about 60 seconds.

Then I'd say it's the cache. Perhaps not the chips, maybe the sockets or their soldering? Usually the cache can be tested in different mobo or if good chips are transferred from a working mobo the problem should be gone. It doesn't seem to be the case here, and longer timings also don't help.

Guld wrote on 2025-01-21, 02:17:

1) On one of the cache chips (not the TAG), the CS# line is only ever reaching maybe 3.6-3.7 volts before leveling off. I was expecting closer to 5.

Yes, this is CMOS and should be closer to 5V. That being said the slopes look pretty sharp and that voltage should be enough to turn it off. I would consider this suspicious but not a 100% sign of a problem. See if you can trace this connection back to the mobo chip, any copper damage or questionable soldering might be affecting the voltage levels. But in such cases I would also epxect to see the rise/fall times to be much worse then what your scope shows - I mean it looks kinda bad at about 40ns but I think you aren't using 10:1 probe? In 1:1 connection to scope the capacitance of the probe and input will cause the signal to look much worse then it is.

Guld wrote on 2025-01-21, 02:17:

2) Same chip, line A4 is heading towards 5 volts on occasion but doesn't make it (switches back to ground quickly apparently). Although it does sometimes get a peak and go to 5 volts. But seems odd to me to look like that.

At 200ns/div you just don't have enough data points for the scope to reconstruct the signal from samples. To probe X MHz square wave signal you need at least 3x the bandwidth from the scope. And even that will not be very true to the actual signal shape. Go to the highest resolution you can to capture the rise/fall slopes, use 10:1 probe to limit the input capacitance and turn off the 20MHz BW limit on the channel. Then you'll be able to see it much better.

Not necessarily the cache itself. Could be traces from cache to chipset, connections from those traces to either the cache chips or the chipset...
Probably the first thing I'd do is reflow the chipset. The legs on that chip are likely to detach from the underlying pads and make bad contacts.

myne wrote on 2025-01-21, 02:37:

Poke around at the passives.
Bad resistor? Bad cap?

Yeah, still poking around, it's possible I suppose. I don't see any electrolytic caps on the board, just tantalums and what I assume are axial MLCCs. A few resistors around the cache chips as well. Some underneath the cache sockets themselves. Continuing to draw out how it's all set up to see if I can determine anything.

MikeSG wrote on 2025-01-21, 12:35:

Did you receive the motherboard with U21 (TAG?) as a 32kx8 chip? The diagram on the motherboard (near QC OK sticker) indicates it should be an 8kx8 chip.

Maybe the TAG is the wrong type?

Yes, it did come with 5 - 32kx8 (15 ns) chips. So the TAG is using a 32k x 8. And the chipset says to use an 8k x 8. I did look into this a little but I don't think it matters: The only differences are:
Pin 1 on 32kx8 is A14, on 8kx8 is not-connected
Pin 26 on 32kx8 is A13, on 8kx8 is Chip Select. (note that pin 20 is the reversed chip select input on both).
all other pins are identical.

I'm not sure if pin 1 on the TAG is actually connected to anything. It's possible, but I haven't found anything yet. I should probably probe it for good measure and make sure it's at least holding either ground or 5v.
Pin 26 on the board is connected to +5 V directly, meaning that the CS line should always be high. Similarly Pin 20 is connected to ground, so the TAG is wired to always be selected. So even on the 32kx8 it would just end up setting A13 high all the time so....I think it should still work just fine. Unfortunately, I don't have any 8k x 8 laying around to test and be sure. But maybe warrants a little more checking to make sure.

Deunan wrote on 2025-01-21, 16:07:

Yes, this is CMOS and should be closer to 5V. That being said the slopes look pretty sharp and that voltage should be enough to […]
Show full quote

Guld wrote on 2025-01-21, 02:17:

1) On one of the cache chips (not the TAG), the CS# line is only ever reaching maybe 3.6-3.7 volts before leveling off. I was expecting closer to 5.

Yes, this is CMOS and should be closer to 5V. That being said the slopes look pretty sharp and that voltage should be enough to turn it off. I would consider this suspicious but not a 100% sign of a problem. See if you can trace this connection back to the mobo chip, any copper damage or questionable soldering might be affecting the voltage levels. But in such cases I would also epxect to see the rise/fall times to be much worse then what your scope shows - I mean it looks kinda bad at about 40ns but I think you aren't using 10:1 probe? In 1:1 connection to scope the capacitance of the probe and input will cause the signal to look much worse then it is.

Guld wrote on 2025-01-21, 02:17:

2) Same chip, line A4 is heading towards 5 volts on occasion but doesn't make it (switches back to ground quickly apparently). Although it does sometimes get a peak and go to 5 volts. But seems odd to me to look like that.

At 200ns/div you just don't have enough data points for the scope to reconstruct the signal from samples. To probe X MHz square wave signal you need at least 3x the bandwidth from the scope. And even that will not be very true to the actual signal shape. Go to the highest resolution you can to capture the rise/fall slopes, use 10:1 probe to limit the input capacitance and turn off the 20MHz BW limit on the channel. Then you'll be able to see it much better.

Thanks, yeah, I will start focusing on tracing back some of the suspicious lines to see if it tells me anything. It could be nothing. And yes, I was using the probe in 1:1 mode. As I said novice with a scope. I'll switch to 10x.
And thanks for the tip about the resolution, still not all that familiar with digital scopes. I'll play with it and see if that improves how it looks, thanks for the tips! I really appreciate it, I've got a lot to learn still!

stamasd wrote on 2025-01-21, 22:35:

Not necessarily the cache itself. Could be traces from cache to chipset, connections from those traces to either the cache chips or the chipset...
Probably the first thing I'd do is reflow the chipset. The legs on that chip are likely to detach from the underlying pads and make bad contacts.

Yeah, part of my list to check out. I can reflow the chipset but it's very time consuming for me as I don't work much surface mount. If any of them tie back to anything that looks suspicous I may focus on those and see.

Will do some more digging, thanks for the tips everyone, I appreciate it. Unfortunately with small humanoids in the house I get precious little time to mess with this, so it's a slow process 😀.

Alright, I've been doing a lot of testing on the system to see if I could find rhyme or reason for what is going on.

I have 3 sets of cache chips I've been testing on the system ( all same size 32k x 8 ):
Etrontech 15ns
Winbond 15ns
ICSI 15ns

And two sets of 4 x 30 pin simms:
OKI 3 chip 60ns, where 4 simms give me < 4 MB (i.e. 3.?? MB total, I forget the exact value)
Memory Master 4MB SIMMS (i.e. 16 MB total)

Trying combinations I have determined:
1) Both sets of memory and the board work fine with cache disabled, runs for hours with no issues. Obviously the cache config for this is irrelevant.
2) There is only ONE combination of cache and memory that is stable with cache enabled and ONLY if a fan is aimed at the board, ICSI + OKI memory + Fan aimed at board
3) All other combinations result in apparent system freeze anywhere from 30 second to an hour in. Weird that it's so variable....
4) All combinations still tend to give me an issue stopping at BIOS check 0x13 on cold boot "The video display has been disabled. Port B has been initialized. Next initializing the chipset" Typically only happens once, hitting reset switch clears past it just fine.
5) When the system locks up, I have noticed frequently (possibly always but can't say for 100% certainty) looking at U4 (one of the cache chips) all address lines are holding inputs values and all i/o lines are also holding value. They are not changing at all. I expected it to continue cycling like it does when the system runs, not sure if this is an indicator or not.

I've checked the CLK2 and it shows 80.6 MHz (bear in mind my scope is 100MHz max so it could be off a little).

The cases with the ICSI + OKI memory that work with cache enabled is odd in that without the fan on it, it can run for quite some time. typically gets 1 pass done on memtest86 and then has an issue (well over an hour). Rebooting will see a system failure occur very early in the next memtest86 run. However, aiming the fan on the board and waiting as little as about 5-10 seconds is enough to get it working and it will keep working indefinitely afterwards.

There seem to be two separate issues. Something causing the 0x13, and the heat related issue. Although I haven't the slightest idea why other cache or other memory (which work fine in other systems) change the characteristics enough that it will not work with cache enabled. (even with the fan on the board).

The only other chip that is part of the cache circuit that I can tell so far other than the large QFP chipset part, memory, TAG, and cache chips themselves, is the 74F373PC.

I have also resoldered two sides of the large QFP chipset chip that pertains to cache, specifically the two sides that cover the lines related to the cache. This seems to have made no difference at all.

I also tried putting a metal pan on top of the CPU and large QFP chipset chip that handles cache to try to see if that would dissipate enough heat to change the behavior with the fan off with the ICSI + Oki memory, unfortunately it had no effect.

Can anyone tell me what the rating on the bypass capacitors for the cache chips should be? Are those likely 22uF?
Is there some other chip that I may be missing thats part of the circuit when running with cache other than the 74F373PC that I identified?
Any other suggestions, I'm starting to run out of ideas here 😀. I don't know if the two different memory configs changed the power draw on the system and something is marginal with cache on, or if it's something completely different.
And I currently haven't the slightest clue about the 0x13 error but I also haven't been focusing on it. Is there any documentation that would give me more details on exactly what the system is doing during that part of the system startup would be appreciated. It is related to "initializing the chipset" so...maybe related?

Guld wrote on 2025-02-01, 14:00:

Can anyone tell me what the rating on the bypass capacitors for the cache chips should be? Are those likely 22uF?

The bigger tantalum caps might be 10uF or 22uF. Those rarely go open, mostly they short and then explode and/or catch fire when power is applied. If in doubt you can tack an electrolytic of 10-100uF on the bottom side of the PCB and see if that helps any. If it does then replace the cap with a known good one or a bigger value low-ESR electrolytic.

The smaller caps are almost always 100nF. Some might be even as low as 10nF but 100 is usually acceptable replacement anyway. These almost never go bad but I suppose one could go open, use same technique (add another cap at the bottom) to verify that. Desoldering those just to check is not a good idea, the PCB is old and might not take it well.

Guld wrote on 2025-02-01, 14:00:

Any other suggestions, I'm starting to run out of ideas here 😀

Usually temperature related issues are degraded ICs or microcracks (especially vias) on the PCB. 74 series chips do degrade, the F ones run hot so it's even more likely. But this would not be an issue you can easily diagnose unless you have the chip out and a tester capable of veryfing dynamic characteristics. Basically once you have a suspected chip out you just put a replacement in, and that's it. In a good quality socket if it can be fitted in there. It's only when you know the chip is faulty or there is no space for socket that you put a new one in and solder it permanently. Same reason - soldering over big, old, multilayer PCBs is not easy.

Lastly I remind you to check the mobo bottom side for any scratches or gouges that might affect traces to/from chipset.

If you have no other ideas then consider swapping the 74F chips near the cache, no matter what their role is. Preferably with F parts, you might get away with ALS or AHCT - but put those in sockets in case it doesn't work out.

Deunan wrote on 2025-02-01, 14:57:

The bigger tantalum caps might be 10uF or 22uF. Those rarely go open, mostly they short and then explode and/or catch fire when […]
Show full quote

Guld wrote on 2025-02-01, 14:00:

Can anyone tell me what the rating on the bypass capacitors for the cache chips should be? Are those likely 22uF?

The bigger tantalum caps might be 10uF or 22uF. Those rarely go open, mostly they short and then explode and/or catch fire when power is applied. If in doubt you can tack an electrolytic of 10-100uF on the bottom side of the PCB and see if that helps any. If it does then replace the cap with a known good one or a bigger value low-ESR electrolytic.

The smaller caps are almost always 100nF. Some might be even as low as 10nF but 100 is usually acceptable replacement anyway. These almost never go bad but I suppose one could go open, use same technique (add another cap at the bottom) to verify that. Desoldering those just to check is not a good idea, the PCB is old and might not take it well.

Guld wrote on 2025-02-01, 14:00:

Any other suggestions, I'm starting to run out of ideas here 😀

Usually temperature related issues are degraded ICs or microcracks (especially vias) on the PCB. 74 series chips do degrade, the F ones run hot so it's even more likely. But this would not be an issue you can easily diagnose unless you have the chip out and a tester capable of veryfing dynamic characteristics. Basically once you have a suspected chip out you just put a replacement in, and that's it. In a good quality socket if it can be fitted in there. It's only when you know the chip is faulty or there is no space for socket that you put a new one in and solder it permanently. Same reason - soldering over big, old, multilayer PCBs is not easy.

Lastly I remind you to check the mobo bottom side for any scratches or gouges that might affect traces to/from chipset.

If you have no other ideas then consider swapping the 74F chips near the cache, no matter what their role is. Preferably with F parts, you might get away with ALS or AHCT - but put those in sockets in case it doesn't work out.

Yeah, the tantalums are all 10uF 16V and there are 9 of them on the board in total.
Smaller ones under the cache chips appear to say "104" on them, so guessing 0.1 uF (looks like an axial MLCC to me).

And yes, while I do see signs of light scratching on the bottom of the board, nothing that seems to even come close to damaging any traces.

Checking resistors....I had two resistors between some of the ISA slots which appear to be out of spec. A 10k reading as 8.33k and a 51k reading as 8.71k.

Checking capacitors, no obvious shorts or opens, however, the board is only showing 790 Ohm resistance from 5V to ground....which seems quite low to me (board completely disconnected and cache chips removed, external battery disconnected). All my other boards I quickly checked had resistances much higher than that. Could this be the issue? Maybe a tantalum is close to shorted but not fully shorted? I wouldn't expect a MLCC to fail short. Thinking this might be the thing to look into next? Note that the 790 Ohm starts off at 500 Ohm when I measure it and is slowly climbing to 800+ ohm at about 1 Ohm/sec, guessing due to capacitor discharge affecting my reading? After many minutes it is up to 1.480 kOhm and still climbing at the same rate...very odd.

I also ran a slightly different test today with the ICSI cache plus both banks of memory loaded with the memory that seems to work more often, cache enabled, fan on. It completed 1 full pass in memtest86 and froze after that. Similar to before, the U4 cache chip showed no activity on address or data lines. Seems odd that it seemed to freeze at exactly the point where it completed 1 pass and was moving on to the next pass.

I'm getting ready to order some chips too, so I'll get some sockets and chips to try since I don't have any on hand.

Regarding the "low" resistance on 5v to ground. It appears there is some residual voltage on the board that is throwing my readings off. If I let it sit long enough it gets to ~24 kOhm which seems much more reasonable. Plug in the external battery (this board's varta has long since been removed) and it drops right back to reading 500 Ohm again and starts climbing again when the external battery is disconnected. I find it surprising the caps on the board keep the voltage up so long...and that I can't seem to detect any DC voltage on 5V to ground with my meter between 5V and ground, although I can see some voltage across some diodes near the old battery location, so clearly there some residual hanging around.

This also appears to be affecting my readings on the 10k Ohm and 51k Ohm resistors I was looking at.

If it's still plugged in, the psu caps can hold charge for a surprisingly long time.

Guld wrote on 2025-02-02, 00:59:

Regarding the "low" resistance on 5v to ground.

You are overthinking it. This is an electrical device, it draws current to operate. Let's say you measured only 5 ohms on 5V rail. Would that alarm you? Should it? 5V/5oms = 1A. Or in power terms 5V*1A=5W. Is it that odd that a whole motherboard, even from this era, draws 5 Watts?

Now, the whole thing is not linear at all, it's not just a big resistor, with voltages much lower than 5V you should measure higher resistance because less transistors will turn on, and/or the leakage is going to be smaller. So it depends on the meter and measurment method as well. If you try to measure resistance of a modern chip that operates at 0.8V and still functions in limited fashion (power saving) at about 0.4V or so, you'll get a dead short on most meters.

TL;DR: If there was a shorted cap on 5V rail you'd see and smell it. Some could be open though.

When measured the board was completely disconnected, even from PSU. That being said, I did find residual voltage through some diodes on the board that were affecting the readings, so as said above, the measurements are incorrect. Granted that voltage stays for a surprisingly long time.

I'm assuming the only way to check for open caps is to remove them? And put them in a capacitor checker to measure ESR? Or is there an in circuit way to do it?

Guld wrote on 2025-02-02, 13:44:

I'm assuming the only way to check for open caps is to remove them?

Yes, which you don't want if the PCB is fragile. Consider doing what I explained above, just add another cap to the existing one. If it helps you know where to investigate. If it doesn't then there is no point in removing the capacitor.

This can sometimes also work for some ICs. Putting another 74 chip on top of faulty one can, in some cases, improve things so you also know the the original IC is suspect. So if you get replacements for the 74 series chips you can try that before doing any soldering.

Deunan wrote on 2025-02-02, 14:05:

Guld wrote on 2025-02-02, 13:44:

I'm assuming the only way to check for open caps is to remove them?

Yes, which you don't want if the PCB is fragile. Consider doing what I explained above, just add another cap to the existing one. If it helps you know where to investigate. If it doesn't then there is no point in removing the capacitor.

This can sometimes also work for some ICs. Putting another 74 chip on top of faulty one can, in some cases, improve things so you also know the the original IC is suspect. So if you get replacements for the 74 series chips you can try that before doing any soldering.

Gotcha, thanks for the tips! I will try when I get my parts in. Don't want to make things worse with the existing traces 😀.

Alright, so I added some capacitors to the back of the board in parallel with the existing ones on the 5V lines. This included all but one of the tantalum 10uF, and I also tacked on 0.1uF MLCCs on the existing MLCCs near the cache chips themselves.

And generally, the system is more stable now with cache enabled. For example, previously, my config with both banks filled (7808k memory total) would not work very well at all. And now if I put the fan on the system is has lasted between 1.5-2 hours from cold boot before locking up. Similarly my config with one or both banks filled with my 4MB SIMMs, which previously would barely boot, if at all, lasts 30-60 minutes or so before locking up. All my cache chips exhibit similar behavior, so they are behaving more consistently as well.

But it's still fairly unstable and I'm still not sure why the fan is helping. It doesn't always help, but clearly there's a heat related issue somewhere.

So it's unclear to me right now if adding the additional capacitors has helped the system just though adding additional capacitance? Or if one of the caps may truly be marginal (possibly even one of the ones I didn't add a supplemental one to)? Is it possible a marginal cap is still causing issues and I need to get it out of the system?

My best guess at an observation seems to be that the more chips are on the system, the less stable it runs. e.g. with the 3712k memory config (4 x 3 chip SIMMs), the system is the most stable, with 7808k (8 x 3 chip SIMMs) is the next most stable, then the one with the 16 MB (4 x 9 chip SIMMs) is less stable, and the 32 MB version with both banks filled is the least stable. Could be missing something here, but it sure seems the more chips are "on" the less stable it is.

The cache chips are turned on and off via the OE line going to them (CS is always on on the TAG and cache, even with cache disabled).

Will continue to work with it, but at least it's some sign of progress!

Completely different generation and symptoms, but an athlon I had, had bad caps. The only symptom I noticed was that the mosfet area got super hot.
Once changed, they were quite cool.
I believe they were leaking too much.
Are any caps noticeably lower in resistance or hotter than the others?

I realise mine were electrolytic, and yours are tantrums, but caps do tend to fail short. I don't know the speed of this process, but it's possible it could be slow.