How to troubleshoot your defective 386/486 motherboard with an oscilloscope

[feipoa]

I'm looking for two things:

1) Someone who has experience in troubleshooting dead 386/486/socket7 motherboards with an oscilloscope and is willing to share their knowledge. 

2) An all inclusive hand holding self-help guide to troubleshooting dead 386/486 motherboards with an oscilloscope. 

My situation is as follows:

I have four MSI MS-3131 motherboards.  They are 386 motherboards.  All four were originally dead - that is no signs of life, no display on the screen, no beep codes.  I was able to get two of the boards working.  One issue was that one of the leads on the 206 DMA memory controller had separated from the solder pad.  I resoldered it, and the board worked fine thereafter.  On the second board, I discovered that one of the cache size-set jumpers was overly loose.  Replacing the jumpers brought the board back to life.

On the remaining two boards, I have tried the following:  check for CLK2 signal at CPU and on ISA slot.  The signal appeared clean on the scope and at the expected frequency; confirmed all jumpers tight; confirm PSU working properly as it works with the other two boards; checked all SMD solder points for loose contacts; checked bottom of board for visible cold solder joints; ran the multi-meter across all resistors and caps checking for shorts (often tantalum caps of this age short out before exploding); ensured the BIOS is working by using a known working BIOS from one of the working boards; tried new CMOS battery; tested all SRAM in an SRAM tester; tested SRAM from a known working board; replaced the KBC chip from a know working board.

The board has no electrolytic caps, and no MOSFETS.  The board basically has a QFP 206 DMA controller, and what looks like a QFP north bridge (UMC 481), a QFP south bridge (UMC 482), and various other TTL 74F DIP and QFP ICs. 

Other than confirming that each chip is making contact with Vcc and GND, I do not know the start-up routine of these boards and do not know what to start probing with the scope.   These boards come with a QFP AMD 386DX-40 CPU soldered on, but also contain a PGA-132 socket.  I find it odd that the motherboard manufacturers didn't implement a float jumper for the 386DX-40.  The FLT# pin on the 386DX is connected to Vcc.  My next course of action is to cut the trace leading FLT# to Vcc and connect FLT# to GND to allow the 386DX to float its pins.  Once this is done, I can insert a CPU to the PGA-132 socket.  This will allow me to test a known working 386 CPU.  If that fails, I will remove the QFP AMD 386DX and, again, test a CPU in the PGA-132 socket. 

Once I have determined that the CPU is not the issue, I'm left at trying to figure out what is wrong with this motherboard.  Either some trace/via/solder point is not making contact, or one of the components are dead.  And I assume this is where the oscilloscope is needed to start tracking down the bad part; this is where I require assistance.

I have the datasheet and pinouts for the UMC 206, 481/482 chipsets but do not know what to look for in fault diagnosis. 

The nice aspect of these UCM 481/482 boards is that there is a MR BIOS-branded BIOS available for them, as opposed to the feature-limited AMI/MSI BIOS.  MR BIOS is like the Rolls-Royce of BIOSes for this era.  They are feature rich and somehow eliminate wait states when you use 60 ns DRAM as shown in benchmarks.  I've tried, both, the AMI/MSI BIOS and MR BIOS on the dead and working boards.

I'm attaching an image of the board.  I've done my best to provide as high resolution as possible while conforming to the 1 MB limit imposed by this forum.  For this reason, the image is split in two.

[Alex Eisenhut]

Are you aware of POST codes?

https://www.ebay.com/itm/Hot-4-Digit-Analyzer-Diagnostic-Motherboard-POST-Card-Tester-Computer-PC-PCI-ISA/263057768484?hash=item3d3f770024:g:cw8AAOSwB-1Ynizt

[feipoa]

Thanks for the suggestion.  Yes.  I have one of those, but I don't find them all that helpful in general.  I'll have to pull it out again and note what code it hangs on for this particular case.   In the past, though, and on different motherboards, the POST code might hang on CPU initialisation, yet I know a working CPU is installed without any cold solder joints.

I'd really like to learn how to troubleshoot this with an oscilloscope.

[Alex Eisenhut]

OK, but why specifically an oscilloscope? As opposed to a logic analyzer, or just a DMM and frequency counter?

[feipoa]

Well, I guess because I have a oscilloscope (2-channel, 100 MHz), do not have a logic analyser, and am not sure what else I can do with my DMM aside from what I've already done.  I am by no means an expert and am hoping to learn.

Attached is an image showing the result of the ISA PC Analyser board. It displays only a double dash -- and no error code

[feipoa]

Floating the onboard QFP AMD 386DX by connecting FLT# to GND and inserting an AMD 386DX or TI486DLC into the PGA-132 socket did not help.

Measuring resistance from Vcc to GND is in the k-ohm range on all four motherboards.

[Twoflower]

Attached is an image showing the result of the ISA PC Analyser board. It displays only a double dash -- and no error code

OK, that might be a mistake by me. But doesn't one of the unpopulated sockets say 80286? In that case any POST value would be a big surprise to me.

EDIT: Yes, it has a processor installed. I fell over the same point again in the past (many years ago). So please ignore my post. But out of interesting: What is the number in the open socked?

[cdev]

You can find a 8 bit Sigrok compatible LA on ebay starting at around $6, a 16 bit one for less than $20 (even less if you simply use a $8 FX2 dev board with your own wires and cable) and a 400 MHz one for $99 so absolutely no reason not to have one.

Its probably super useful with signals within its data capture range. check sigrok.org and the 'opentechlab' youtube channel (the author of pulseview, the GUI program for sigrok LAs, is great for learning how to use pulseview and LA's generally)

Well, I guess because I have a oscilloscope (2-channel, 100 MHz), do not have a logic analyser, and am not sure what else I can do with my DMM aside from what I've already done.  I am by no means an expert and am hoping to learn.

Attached is an image showing the result of the ISA PC Analyser board. It displays only a double dash -- and no error code

[feipoa]

OK, that might be a mistake by me. But doesn't one of the unpopulated sockets say 80286? In that case any POST value would be a big surprise to me.

Yes, the unpopulated PGA-132 socket says 80286 and it is clearly a typo.  It should read 80386.

You can find a 8 bit Sigrok compatible LA on ebay starting at around $6, a 16 bit one for less than $20 (even less if you simply use a $8 FX2 dev board with your own wires and cable) and a 400 MHz one for $99 so absolutely no reason not to have one.

Its probably super useful with signals within its data capture range. check sigrok.org and the 'opentechlab' youtube channel (the author of pulseview, the GUI program for sigrok LAs, is great for learning how to use pulseview and LA's generally)

cdev, for someone who has not used a logic analyser before, perhaps you can explain the benefit of a logic analyser over that of an oscillscope, aside from the fact that the logic analyser can view significantly more channels simultaneously?  If the advantage is simply one of more simultaneous channels, then it seems this can be performed on a oscilloscope with more switching of the probe.  And don't I still need to know what to probe and what is the expected behaviour?  Some insight on this would be appreciated.

[Rasz]

cdev, for someone who has not used a logic analyser before, perhaps you can explain the benefit of a logic analyser over that of an oscillscope, aside from the fact that the logic analyser can view significantly more channels simultaneously?  If the advantage is simply one of more simultaneous channels, then it seems this can be performed on a oscilloscope with more switching of the probe.  And don't I still need to know what to probe and what is the expected behaviour?  Some insight on this would be appreciated.

you have 2 good boards + 2 bad ones, perfect situation for differential analysis
you could put logic probes on bios chip address pins, or ISA bus data lines and capture good board boot, then do the same with bad one (using same bios) and compare
this will give you an idea about
-is cpu starting
-how far does it execute before freezing
-where exactly does it stop, this one requires bios dump in idapro and smarts/dedication

$6 Cypress FX2 board can capture 16 bit at 10MHz

do faulty boards beep at all? keyboard leds flash once? have you checked that post card in the good board?


without logic analyzer you can power both good/bad boards side by side and use multimeter/scope to ~randomly probe and compare until you find something odd. Use scope to check supply on all the big chips. Powering them from lab supply and looking at the power draw is another good way, this is what I do first when troubleshooting dead laptops. If you dont have lab supply just splice your meter into supply line and measure the draw.

[feipoa]

Thank you for your comments.  Could you provide a web address for the $6 logic analyser which you are recommending?  e.g. https://www.ebay.ca/itm/CY7C68013A-56-EZ-USB-FX2LP-USB2-0-Develope-Board-Logic-Analyzer-EEPROM-M36/351494353170

The BIOS has 16 address pins and 8 Data in/out pins.  Aren't these values going to change rapidly during the boot process on the working board?   If so, how would it be possible to pause the scope right at the moment where the output catches the very first event sequence and not the nth state during the boot process? 

Could you please explain by way of example how probing all the address pins on the BIOS will let me know if the CPU is starting and how far along it is in the boot process?  It seems to me if the dead boards have no codes from the PC analyser card that almost nothing is starting?  Wouldn't this provide some insight as to the high liklihood items for the failure?  Like which components must be broken or contain disconnect for this to happen?  For example, it doesn't seem like the 206 DMA controller chip needed to be connected for the motherboard to output a PC speaker beep sequence, and that is, in fact, how I troubleshooted one of the now working boards.

Let's say I am able to take a snapshot of the exact moment in the boot process in which the working board turns on, call it item sequence 1 in the boot process. Now if address A0, for example, on the working board has a pulse, and A0 on the dead board does not, how does this information assist in troubleshooting the faulty component?

Concerning probing the chipsets, how would I get the probes onto the pins?  In the absence of some sort of clip-on adapter for QFP chipsets, wouldn't I need to solder a wire to the tiny leads on the chipset?  And would the same ring true for probing the CPU and other soldered ICs?  If so, then wouldn't it be easier to replace the 206, 481, and 482 chips?  Is there not a more systematic and sequential approach to finding the fault? 

If I remove the QFP AMD CPU, then probing the PGA-132 socket would be fairly straight-forward and no soldering required.  But do you think probing the PGA-132 CPU socket in a power-on state without the CPU installed be of any value?  If so, where to start probing and what to look for? 

Alternately, as the system has a QFP AMD CPU installed and the board contains a PGA-132 CPU socket, perhaps this combination would be of value to have easy probing access to the CPU's pins.  If so, what to probe and what are the expected results at the 0th state in the boot process?   Unfortunately, when I went to check if CLK2 on QFP AMD CPU is connected to CLK2 on the PGA, they were not.  This is true for these boards.  So if CLK2 on PGA doesn't make a direct connection to CLK2 on QFP, then other pins may not be directly connected as well.

To directly answer your questions - the faulty boards do not beep at all; the keyboard LED does not flash; the POST card does run through the codes in sequence on the working boards.

Is there a systematic approach to probing rather than random probing of the boards?  I do not know what to look for, when it should occur, and on which pins.  Do you know?  It seems like we would want to know the very first course of action the motherboard takes upon power up, e.g. like initialise the keyboard controller, and if so, which pins should look like what on the scope?

In a power-off state, I have confirmed that Vcc and Vss are reaching the chipsets and the CPU.  What I found a little odd was that, according to the AMD datasheet, pin 34 = Vss and pin 35 = Vcc. For this set of pins only, the motherboard is wired such that pin 34 = Vcc and pin 35 = Vss.  I figure it might be a typo because the working boards are wired the same as the dead ones.

I suppose could measure the supply current.  What information will this provide for the troubleshooting process?  I figure the dead board will have a lower current draw than the working one.  The easiest for me would be to plug-in a kilo-watt meter, albiet with less significant digits then splicing in the DMM.  EDIT: working board runs with 0.43 A ac and dead board runs with 0.36 A ac, as measured with a Kill-A-Watt.

[CJay]

Ahh, back in the day, happy memories...

I miss my Antron ICEs, if you're going to make a habit of repairing old 286, 386 etc. boards then it might be worth trying to track down an old CPU in circuit emulator, exceptionally handy for this sort of problem as you can delve in and initialise the chipset, test register read write, get instant status of CPU operation etc.

An EPROM emulator can be a useful diagnostic tool if you get the right one, we had a couple, one of which would allow you to alter the contents on the fly as well as allowing you to check the address bus so you could 'seed' the EPROM code with HLT instructions for a 'checkpoint' diagnostic.

There were other ISA POST cards that came with a set of EPROMs to replace the BIOS chips too, they were more useful as they could run diagnostics on the chipset as long as the board was out of reset, some of the later ones even had their own CPU!

(It dawns on me it may even be possible to plug in a CPU card from an industrial PC and run diagnostics on the host board that way but it's *very* involved)

Sadly those UMC boards were crap but...

You've answered most of the questions I was going to ask already, the POST cards work in good boards so we can make the assumption the bad boards aren't getting out of the first few bytes if they are even beginning to run BIOS code (POST codes are generated a way into the BIOS code) so first step is to watch RESET on the '386, also take a look at OE on the EPROM and check for activity.

If they check out then work through the address and data lines on the EPROM, you're not looking specifically for content but levels, if any are stuck high or low, if any are 'odd', not making full amplitude then you may have a problem there.

Same follows for RAM and cache, removing RAM and/or cache might give an insight too. 

I'm pretty sure the QFP '386 chip pins will be directly connected to the equivalent pin on the PGA socket so you can probe signals on that instead of worrying about how to make contact on the QFP chip, it would be useful to meter out the connections though, I spent an awful lot of time reworking QFP chips in that era, applying moderate pressure to the tops of chips and watching for changes to the control signals on EPROMs, RAM, Cache etc. can be a useful diagnostic.

Running a meter on continuity to ground and along those ISA sockets would be a worthwhile quick and dirty test too.

Some boards output POST codes on parallel ports if they have headers fitted, depends on BIOS version so I'd at least confirm the BIOS EPROM is the same on all boards (don't rely on labels), by swapping if necessary, and test again.

*edit* Found a very useful resource, others may know it but I reckon it's worth a mention, http://www.minuszerodegrees.net/manuals.htm

 

[Rasz]

Thank you for your comments.  Could you provide a web address for the $6 logic analyser which you are recommending?  e.g. https://www.ebay.ca/itm/CY7C68013A-56-EZ-USB-FX2LP-USB2-0-Develope-Board-Logic-Analyzer-EEPROM-M36/351494353170

yep, some more details: http://forum.hobbycomponents.com/viewtopic.php?f=102&t=1891
Just keep in mind this wont be out of the box experience, you pay $6 + time to set everything up and learn somewhat primitive tool etc.

The BIOS has 16 address pins and 8 Data in/out pins.  Aren't these values going to change rapidly during the boot process on the working board?   If so, how would it be possible to pause the scope right at the moment where the output catches the very first event sequence and not the nth state during the boot process? 

Thats why I suggested going that route only with logic analyser. its perfectly capable of capturing all this traffic up to your computers memory capacity, ~ 50 seconds per GB. btw you dont have to capture both address and data lines, one or the other will be enough for comparison.

Could you please explain by way of example how probing all the address pins on the BIOS will let me know if the CPU is starting and how far along it is in the boot process?  It seems to me if the dead boards have no codes from the PC analyser card that almost nothing is starting?

ISA postcode boards work by mapping Port 80h. Bios writes codes like this:

Code: [Select]

mov   al, 0D5h ; some post code
out   80h, al     ; out it goes to the postcard
no post codes can mean not executing bios at all, but it can also mean executing bios and hanging before having opportunity to output first post code, or something wrong with ISA address decoders, or something between

Wouldn't this provide some insight as to the high liklihood items for the failure?  Like which components must be broken or contain disconnect for this to happen?  For example, it doesn't seem like the 206 DMA controller chip needed to be connected for the motherboard to output a PC speaker beep sequence, and that is, in fact, how I troubleshooted one of the now working boards.

Let's say I am able to take a snapshot of the exact moment in the boot process in which the working board turns on, call it item sequence 1 in the boot process. Now if address A0, for example, on the working board has a pulse, and A0 on the dead board does not, how does this information assist in troubleshooting the faulty component?

This means you know there is something bad between bios chip and cpu(not necessarily the cpu itself). First thing 386 CPU does is fetch BIOS contents (mapped to 0xF0000 - 0xFFFFF) starting with 0xFFFF0 address (actually 0xFFFFFFF0, but thats beside the point).
Why didnt it try fetching bios? many possibilities:
-no clock
-bad cpu
-bad chipset (translates between cpu and peripherals like ISA slot/bios chip, decodes addresses)
-something blocking one of the data or address busses. Chipset <-> bios, chipset <-> cpu, for example stuck bit somewhere, broken connection etc.

Concerning probing the chipsets, how would I get the probes onto the pins?  In the absence of some sort of clip-on adapter for QFP chipsets, wouldn't I need to solder a wire to the tiny leads on the chipset?  And would the same ring true for probing the CPU and other soldered ICs?

needle and steady hand, good eyes or glasses.

If so, then wouldn't it be easier to replace the 206, 481, and 482 chips?  Is there not a more systematic and sequential approach to finding the fault? 

sure, its even easier to replace whole motherboard

If I remove the QFP AMD CPU, then probing the PGA-132 socket would be fairly straight-forward and no soldering required.  But do you think probing the PGA-132 CPU socket in a power-on state without the CPU installed be of any value?  If so, where to start probing and what to look for? 

why are you so hell bend on removing the cpu? first make sure its bad. Extra cpu socket is a great spot for scope probing, download 386 pinout
http://pdf.datasheetcatalog.com/datasheet/Intel/mXtuvqv.pdf
and scope  CLK2, RESET, A2-A31, D0-D31, VCC, compare with working board

Alternately, as the system has a QFP AMD CPU installed and the board contains a PGA-132 CPU socket, perhaps this combination would be of value to have easy probing access to the CPU's pins.  If so, what to probe and what are the expected results at the 0th state in the boot process?   Unfortunately, when I went to check if CLK2 on QFP AMD CPU is connected to CLK2 on the PGA, they were not.  This is true for these boards.  So if CLK2 on PGA doesn't make a direct connection to CLK2 on QFP, then other pins may not be directly connected as well.

clock is most likely connected thru separate TTL buffer gates, scope it

To directly answer your questions - the faulty boards do not beep at all; the keyboard LED does not flash; the POST card does run through the codes in sequence on the working boards.

Is there a systematic approach to probing rather than random probing of the boards?

start with critical stuff:
-clocks. CPU, but also RTC 32.768 kHz and ISA ~8MHz (B20 on the slot, https://en.wikipedia.org/wiki/Industry_Standard_Architecture )
-supply on individual chips, correct voltage and noise levels
-important signals like CPU reset, W/R, ADS etc


CJay made very good points, try pressing on chips with your finger(gently but firmly) and then boot while maintaining presure. He also mentioned removing non required chips - try booting naked board with no ram/cache/isa cards - this wont be a problem for early boot stages, enough to monitor biosA0/cpu A2 with scope.

I do not know what to look for, when it should occur, and on which pins.  Do you know?  It seems like we would want to know the very first course of action the motherboard takes upon power up, e.g. like initialise the keyboard controller, and if so, which pins should look like what on the scope?

Some of the info is in Intel docs, some in bios code, some you learn repairing computers. I cant really point you at one spot on the web with all of that knowledge Its all spread around
x86 bootup sequence is in intel pdfs, some here:
 https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
bios :
 https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered
 https://sites.google.com/site/pinczakko/bios-articles
power sequence in modern computers:
 https://www.elvikom.pl/szkolenie-nr-1-podstawy-diagnostyki-plyt-glownych-laptopow-t986.html half translated, might be readable with google translate


It all starts with chipset resetting CPU, CPU fetches bios, CPU starts executing bios, first thing BIOS does is most likely memory controller initialization.
side note: more modern systems based on CPUs with L1/L2 cache do tricks to treat cpu cache as temporary ram in order to speed up initial bios load and execution.

In a power-off state, I have confirmed that Vcc and Vss are reaching the chipsets and the CPU.  What I found a little odd was that, according to the AMD datasheet, pin 34 = Vss and pin 35 = Vcc. For this set of pins only, the motherboard is wired such that pin 34 = Vcc and pin 35 = Vss.  I figure it might be a typo because the working boards are wired the same as the dead ones.

looks like typo, Intel has same pinout as your boards http://www.nj7p.org/Manuals/PDFs/Intel/241267-003.PDF

I suppose could measure the supply current.  What information will this provide for the troubleshooting process?  I figure the dead board will have a lower current draw than the working one.  The easiest for me would be to plug-in a kilo-watt meter, albiet with less significant digits then splicing in the DMM.  EDIT: working board runs with 0.43 A ac and dead board runs with 0.36 A ac, as measured with a Kill-A-Watt.

no , you need milliamp range, temporal readout is a bonus(https://www.eevblog.com/forum/beginners/how-to-measure-current-on-an-oscilloscope/). Using power draw for troubleshooting is an art, mastered by Chinese cellphone/laptop repair gurus. The trick is to map out power draw over time of a booting 100% working system and correlate that to sequence of initialization stages said booting system goes thru. Additionally you build a list of known faults with subsequent readings.
In your case it could be something like first milliseconds after power applied CPU should still be held under reset - low draw, then when it starts it goes up a little, then CPU puts out its first read command on the bus - draw changes, then chipset has to translate this command to 16bit isa bus and interrogate bios chip - again different draw, etc etc. You can graph such power sequence with power on Y axis and consecutive stages on X.

With such map in hand it takes mere second to diagnose broken unit, just plug lab supply and watch the sequence, you automatically know when it deviates from norm.

[CJay]

ISA postcode boards work by mapping Port 80h. Bios writes codes like this:

Code: [Select]

mov   al, 0D5h ; some post code
out   80h, al     ; out it goes to the postcard
no post codes can mean not executing bios at all, but it can also mean executing bios and hanging before having opportunity to output first post code, or something wrong with ISA address decoders, or something between

Absolutely, 80H is the most common and it is highly likely to be 80H on the OP's boards but it's not always there, even on contemporary ISA boards.

If you 'scope the parallel port data pins pre VGA init on an IBM PS/2 ISA machine you'll see some very interesting activity which can be decoded with a couple of HP hex LED displays

[rhb]

Make a free run harness.  This is a device that sits between the CPU and the MB.  It feeds a NOP to the CPU, forcing it to cycle through all the addresses no matter where it starts.  A scope probe on the address lines will tell you if you have an address line fault and a probe on the data lines will tell you if you have a data line fault.

I made one for a 6502 using a socket and a pull up resistor. Construction will be more complicated for your needs, but the idea is the same. 

There *should* be a way to single or slow step them, but the Intel manuals are not indexed, so I can't find out how easily.  I'll let you sort that out. There *is* a way.

Cycling through the addresses will give you a ROM dump which you can compare against the working boards.  But you'll need an LA which dumps to disk to do that.

The first thing to do would be to check the power rails at various locations with a suitable load resistor and look for bad capacitors.

There's a lot more to it, but you're trying to acquire a lost art.  When I did this, the 386 didn't even exist.

[feipoa]

Thanks to everyone for their time-involving responses.  Some further comments now...

CJay:

Do you have a link to provide for such a circuit emulator? 

I do not really intend to spend much money on this.  I know there was a logic analyser on eBay within the past few months which also contained the sandwich layer interposer boards for PGA-132 and PGA-168, but the cost was in the hundreds before shipping. 

ISA Post cards with various EPROM sets - could you provide a weblink?

Why do you say these UMC boards were crap?  These particular boards were made by MSI, which has a decent reputation and still exists today.  The UMC 480 chip set series was a bit slow with RAM throughput if you use the AMI BIOSes, but when using MR BIOS, the performance is similar to that of the SiS Rabbit (386) or VLSI 330 series chipsets.  I did run a simple benchmark analysis of about a half dozen 386 chipsets and these three came out on top.  The aspect I don't really like about the UMC 480 series is that it was also used in early 486 designs, which diminishes the novelty of running a pure 386 motherboard.

OK, so you are recommending that I probe RESET on the AMD386DX and probe OE on the BIOS socket? I can certainly do this.  Is it helpful to probe any of these without the CPU's presence?  I was thinking to remove the AMD 386DX on one of the dead boards, and keep one on another.

OK, on the EPROM, I will probe addresses A0-A15, Data I/O's Q0-Q7, and OE.  Let the power be on 20 seconds or so to view changes?  Or is a 5s timeframe good enough?  Also, is using the native MSI AMI BIOS preferred, or is MR BIOS OK? 

I also thought that the PGA and QFP 386 would be connected 1 to 1, but CLK2 is not.  Perhaps CLK2 goes to different output ports of a line driver chip?  I have another brand UMC 480 series board and CLK2 also is not directly connected on PGA and QFP.  I'll check a few of the other pins to ensure that CLK2 is the only abnormality.

When looking at the EPROM's address and data pins, should each of them at least have one incident of a low-to-high or high-to-low swing?  From your wording, it sounds each of them should have at least one transition.

OK, I will apply pressure to the 4 QFP chips when cycling the power.  Which pins in particular am I probing while doing this?  chip select, write enable, and output enable inputs?

For running the continuity meter from GND to X pins on the ISA slots, I assume with power off?

I did check all the BIOS chips in working boards, they all appear to be of the same revision.  But I generally use the MR BIOS for um480 series.  I've used it for years in another UMC 480 series board and it seems to work in this MSI um480 boards.  The board does not have a parallel port built onto the motherboard - it is on an ISA I/O card.  How can I read the post codes from the parallel port?

Thanks for the weblink.  It does contain a user manual for the UMC 481B / 482A chipset, although my board has the 481A revision marking.  Unfortunately, that manual makes no mention of the 386, only the 486.  Perhaps that is where the difference from B to A is.


Rasz & rhb:

I ran out of time to read your next posts in detail.  Its getting late and I'll have to pick this up again tomorrow.  I only have about 1 hour each night to play with this hobby. 

Quickly, though, I do have an extra PGA-132 which I could sandwich in there and solder a 30 AWG wire to.  The kynar jacket on the wire is pretty thin and a lot of wires will be bundled up, so not sure if there will be a capacitative coupling issue between adjacent wires.

For $6, I might just grab that LA board.  Actually, if there is a slightly better one (e.g. faster & more ports) for under $25, any recommendations?

why hell bent on removing the QFP AMD - you are observant!  And the reason is because, at the end of the day, I plan to remove it anyway, or at least float it, so that I can use the PGA-132 with different CPUs, e.g. TI 486SXL, DRx2, IBM DLC3, etc.  If I don't want the CPU on there, and plan to remove it, doing it sooner would allow for a quick test if the CPU is bad.

I'll try to read the rest of the posts tomorrow.

Thanks again for all your comments.

[CJay]

Do you have a link to provide for such a circuit emulator? 

There are plenty via Google but I get no hits at all for the Antron ones I used.

Intel, Agilent, Tektronix all produced them back in the day as did a few smaller companies.

I do not really intend to spend much money on this.

ICE pods were several thousand when current, the Intel ones were in the tens of thousands, they're a bargain at a couple of hundred if you can find one but I appreciate they will probably be more money than you want to spend, if you intend to repair a lot of boards they're an excellent investment.

ISA Post cards with various EPROM sets - could you provide a weblink?

Probably not, it's a *long* time ago, we're talking about the time when the boards you have were new on the market and the web probably wasn't even a twinkle in Tim Berners-Lee's eye.

Why do you say these UMC boards were crap?  These particular boards were made by MSI, which has a decent reputation and still exists today.

Thing is, MSI weren't always a quality brand and the UMC chipset wasn't great, there were much better boards out there and, undoubtedly, worse.

OK, so you are recommending that I probe RESET on the AMD386DX and probe OE on the BIOS socket? I can certainly do this.  Is it helpful to probe any of these without the CPU's presence?  I was thinking to remove the AMD 386DX on one of the dead boards, and keep one on another.

Yes, but you won't see any activity on the EPROM if there's no CPU.

OK, on the EPROM, I will probe addresses A0-A15, Data I/O's Q0-Q7, and OE.  Let the power be on 20 seconds or so to view changes?  Or is a 5s timeframe good enough?  Also, is using the native MSI AMI BIOS preferred, or is MR BIOS OK? 

If you're not seeing activity after a second of power on then it's either in RESET or dead.

Track down and try to follow POWERGOOD as well.

When looking at the EPROM's address and data pins, should each of them at least have one incident of a low-to-high or high-to-low swing?  From your wording, it sounds each of them should have at least one transition.

On power up and release from reset the CPU should start to fetch code from the EPROM almost immediately (after a few microseconds at most), it gets complicated on some boards because very early on they 'shadow' copy the EPROM into RAM and run from there but you should at least see the activity while that's happening and possibly beyond that.   

OK, I will apply pressure to the 4 QFP chips when cycling the power.  Which pins in particular am I probing while doing this?  chip select, write enable, and output enable inputs?

Not necessarily any pins, pressing down on the chips can temporarily bypass dry joints that may have developed, if you spot a change when you do it, reflow the chip.

For running the continuity meter from GND to X pins on the ISA slots, I assume with power off?

Yes, definitely, you're looking for shorts to ground or 5V where there shouldn't be any, comparing readings from a good board with a bad board can also be useful.

I did check all the BIOS chips in working boards, they all appear to be of the same revision.  But I generally use the MR BIOS for um480 series.  I've used it for years in another UMC 480 series board and it seems to work in this MSI um480 boards.  The board does not have a parallel port built onto the motherboard - it is on an ISA I/O card.  How can I read the post codes from the parallel port?

Plug in an ISA parallel port card

Your BIOS may not output codes to $378 though, it was just to point out for future reference that not all boards output POST codes to $80, indeed on some of the cards I used there were jumpers which allowed you to change the port they 'listened' on.

Thanks for the weblink.  It does contain a user manual for the UMC 481B / 482A chipset, although my board has the 481A revision marking.  Unfortunately, that manual makes no mention of the 386, only the 486.  Perhaps that is where the difference from B to A is.

It was a very confusing time, there were all sorts of oddities which would bite you if you weren't careful so I'm not at all surprised there are discrepancies and changes like that, it's a *lot* simpler to build machines these days.

why hell bent on removing the QFP AMD - you are observant!  And the reason is because, at the end of the day, I plan to remove it anyway, or at least float it, so that I can use the PGA-132 with different CPUs, e.g. TI 486SXL, DRx2, IBM DLC3, etc.  If I don't want the CPU on there, and plan to remove it, doing it sooner would allow for a quick test if the CPU is bad.

You probably don't need to remove that QFP chip to use the PGA socket, at least on the boards I remember the on-board CPU was disabled either by jumper or automatically.

[rhb]

A bit more about the free run harness. 

The pins on the data line which are logic low can just be tied to any adjacent ground.  I don't know the op code for the 386 NOP, but the only other wires will be the ones that tie via  pullup resistors  to a nearby power pin.  SMD parts glued to the bottom of the socket might work.   Put some nail polish on to protect it after soldering the lines.  It might be a good idea to use clear nail polish as the glue to prevent shorts and then carefully scrape any excess off the pins.  Nail polish has pretty good dielectric properties at 386/486 clock speeds.

Use a scrap memory card to make a way to probe the address and data lines.

Another construction option might be to use a dead CPU for the pins after splitting the ceramic package.  But that involves a lot more work to wire up.  I'd suggest doing that only if the socket hack proves too difficult.

Just for fun I tried a search on ["free run harness" computer]  and got no hits other than a post of mine from 5 years ago.  I have a large library with quite a few books on computer hardware and troubleshooting.  I've only seen the concept mentioned one time.  I'd post the citation but it would probably take a few hours to locate.  I did *not* invent the idea.

Edit:

I neglected to mention that the data lines coming to the CPU must be floated.

The source of the free run harness idea:

"Troubleshooting On Microprocessor Based Systems"
G. B. Williams
Pergamon Press 1984
ISBN 0 08 029988 1

A couple of other good books on the topic:

Practical Electronics Troubleshooting
James Perozzo
Delmar Publishing 1985
ISBN 0 8273-2433-2

Microcomputer Troubleshooting
James Perozzo
Delmar Publishing 1986
ISBN 0 8273-2500-2

I seem to recall having another good book on the topic of component level microprocessor repair, but do not find it.  Not sure if it's MIA or a spurious memory.

[Rasz]

If you 'scope the parallel port data pins pre VGA init on an IBM PS/2 ISA machine you'll see some very interesting activity which can be decoded with a couple of HP hex LED displays

same on Toshiba Laptops until they dropped LPT, Toshiba even used LPT dongle (every other pin connected) to reset bios password.

Quickly, though, I do have an extra PGA-132 which I could sandwich in there and solder a 30 AWG wire to.  The kynar jacket on the wire is pretty thin and a lot of wires will be bundled up, so not sure if there will be a capacitative coupling issue between adjacent wires.

why go to all that trouble when you can just shove scope probe into socket holes one by one? EDIT: ah, you are already planning on removing soldered on cpu

For $6, I might just grab that LA board.  Actually, if there is a slightly better one (e.g. faster & more ports) for under $25, any recommendations?

Im afraid no, and its NOT an LA, this is just a simple dev board that can be used as one, there is no threshold control, no clamping diodes, no resistors, this is very basic and crude tool. Its biggest strength is its simplicity - it doesnt trigger on anything, it just pumps raw logic level on its pins over USB to the computer at set frequency, up to 16 bit x 12MHz, or 8 x 24MHz. When using 'normal' LAs you need to know what to trigger on, and have limited memory buffer to work with (in old designs as ridiculous as 4Kbit).

why hell bent on removing the QFP AMD - you are observant!  And the reason is because, at the end of the day, I plan to remove it anyway, or at least float it, so that I can use the PGA-132 with different CPUs, e.g. TI 486SXL, DRx2, IBM DLC3, etc.  If I don't want the CPU on there, and plan to remove it, doing it sooner would allow for a quick test if the CPU is bad.

I suspected as much (Ultimate 386 Benchmark?). Me personally I would wait until Im sure its the CPUs fault (doesnt do anything after reset). Im guessing you already tested using socketed cpu on one of the working boards to confirm its fully operational on this board model, and experimented with 50MHz(or even 25MHz) clock gen chip?

You already know of http://datasheet.datasheetarchive.com/originals/scans/Scans-067/DSA2IH00218654.pdf UMC datasheet. It has a very nice reference design block diagram that will help you visualize whats connected to what, and all inter dependencies.
It shows that with board stripped out (no ram/cache/bios chip/KB controller chip) you need at minimum working:
-481(address bus)
-482(data bus)
-clock generator
-U23 74f244(http://www.ti.com/lit/ds/symlink/sn74f244.pdf) clock buffer <- this is why clock pins are not directly connected between socket and cpu.
-finally cpu

to see any activity on BIOS chip pins, you can probe bios address pins or/and pins 20/22 (chips select/output enable). If you see signals here it will mean at least that path works and we can move on with troubleshooting.

Track down and try to follow POWERGOOD as well.

good idea! didnt even think of that :/

On power up and release from reset the CPU should start to fetch code from the EPROM almost immediately (after a few microseconds at most), it gets complicated on some boards because very early on they 'shadow' copy the EPROM into RAM and run from there but you should at least see the activity while that's happening and possibly beyond that.

shadow copy is usually(always?) a bios function, requires already initialized ram controller with running refresh and the idea about amount of ram installed, chipset cant do it on its own

For running the continuity meter from GND to X pins on the ISA slots, I assume with power off?

Yes, definitely, you're looking for shorts to ground or 5V where there shouldn't be any, comparing readings from a good board with a bad board can also be useful.

wouldnt be stupid to do the same for the BIOS/keyboard controller sockets - they are on the other side of ISA slot TTL buffers (fried buffer might screw with data/address lines on one side)

A bit more about the free run harness.

I suspect its impractical for 32bit data bus cpu.

[feipoa]

OK.  I still haven't finished reading all your comments and items to test yet, but what I have done is setup the test bed. I'll attach a photo.  On the right is the working board (CH1 on scope - yellow); on the left is the dead board (CH2 on scope - blue).  Each board has an identical ISA graphics card, 256 K of cache, 4 MB DRAM, and the MSI AMI BIOS.  I'm using the PGA-132 to probe the CPU's pins.  The dead board is using a native AT power supply, while the working board is using an ATX power supply with AT converter cables and latching switch.  Both are setup with a speaker and reset button.  Both are on a KVM.

I managed to source and download the datasheets for every IC on the motherboard, omitting the crystal oscillator, resistors, caps, diodes, inductors, etc.  This task consumed a lot of time.  In brief, I have the UMC 206/481/482 chipset (though I suspect the 206 datasheet I have might not be correct), EEPROM (using W27C512), AMD 386DX QFP-132, AMD 386DX PGA-132 (top and bottom views), ISA pinout, 30-pin SIMM pinout, SRAM (using W24257A), and keyboard controller (using Winbond W83C42, but also have the sheet for the AMI Megakey).  The 7400 series chips on the board include: 74FCT244 (Buffer/Line Driver - I'm pretty sure this is the chip which splits CLK2 to QFP and PGA CPUs), 74F244 (Octal buffer/driver), 74F245 (Octal bus tranceiver), 74F32 (Quad 2-input OR gate), 74F74 (D-type flip-flop), 74ALS245A (Octal bus tranceiver), 74F00 (Quad 2-input NAND gate), DM7407 (Hex buffer), DM74LS14 (Hex inverter w/schmitt trigger inputs), and CD4069UB (Hex inverter).

It is quite late now and I will have to stop for the evening, however, I did do a quick check of the ISA pins - no pin other than GND is shorted to GND.

I also ran the two systems with the probe on the CPU's RESET pin.  On the working board, at hard reset, the RESET pin goes to Vcc, then remains at GND.  On the defective board, the RESET pin stays at Vcc.  What can we deduce from this information?

Here is the photo of the test bed.

[CJay]

The processor isn't being released from reset so *nothing* happens, there won't be activity on any EPROM pin, the ISA bus or anything.

Check the processor reset pin isn't shorted to 5V.

I don't know/remember the UMC chipset well enough but one of the chips will be handling clock generation and RESET, it should have an input from the power good circuitry so you can trace this back (If PG is not asserted the board shouldn't* come out of reset).


* Some boards completely ignored PG from the PSU and came up anyway, as I mentioned before, it was a weird time where there were all sorts of odd things out there

[Rasz]

I have done is setup the test bed. I'll attach a photo.

nice and tidy

I have the UMC 206/481/482 chipset (though I suspect the 206 datasheet I have might not be correct)

82C206 is a famous chip, born at Chips & Technologies as part of NEAT chipset https://en.wikipedia.org/wiki/NEAT_chipset
Everyone and their dog made clones, most 386, and lot of early (no integrated FDC/IDE) 486 boards(*) had one made by C&T, SiS, Opti, UMC, even Samsung.

umc: http://www.datasheet.hk/view_online.php?id=1293506&file=0098/um82c206_1018292.pdf
http://www.elenota.pl/datasheet-pdf/58717/UMC/UM82C206
C&T: http://www.elenota.pl/datasheet-pdf/60708/others/82C206
Cant find pinout for the 100 pin package

* even some shitty first generation Pentium reference designs still had 82c206 http://bitsavers.trailing-edge.com/pdf/opti/brochures/PTMAWB_Chipset_Brochure_1992.pdf

I also ran the two systems with the probe on the CPU's RESET pin.  On the working board, at hard reset, the RESET pin goes to Vcc, then remains at GND.  On the defective board, the RESET pin stays at Vcc.  What can we deduce from this information?

The processor isn't being released from reset

Yep.

UM82C206 takes powergood, but only uses it to float itself on the bus in case of bad logic level. Most likely 482 will be responsible for reset, its the one handling main clock.
 You will have to trace CPU reset pin back to the origin.


Edit: if you want to see what is needed for 386 cpu to run here are some good resources:
https://blog.lse.epita.fr//articles/77-lsepc-intro.html <- homemade 386SX dev board
http://www.s100computers.com/My%20System%20Pages/80386%20Board/80386%20CPU%20Board.htm <- homemade S100 386DX40 motherboard, included are examples of debugging with USB logic analyser dev board I mentioned earlier.

[feipoa]

That looks to be the same datasheet for the UMC Um82C206 that I have. The pin count is wrong for what I have and I am measuring GND (Vss) pins for the 206 in completely different locations as specified on that datasheet.  I'm getting GND around pins 71, 55, and 14.  I also do not measure a Vcc anywhere on the 206, even on the working motherboard.  Does the Vcc from the PSU head to a resistor greater than 50 ohm, in series, before heading to the 206?   Or does Vcc from PSU head to one of these IC's, perhaps to change the output impedance?

From what I can  tell by DMM probing, the power good (PG) pin from the power supply heads only to GD4069UB (HEX Inverter), the output of which heads to one of the pins on the UMC 206 (6th in from the top left), or around pin 69 on the wrong datasheet, which is HRQ, which is an output, which cannot be.  I'm assuming the real pin name for where the output of GD4069UB goes to is PWRGD on 206.

Nice 386 resources; wish I had time to really get into them.  These days, I hardly have time to shop for groceries.

The RESET pin from the CPU goes to pin 5 (PESCPU) on the 482 chip. I couldn't find any description for what PESCPU stands for.  Under which conditions does the 482 change PESCPU's output from high to low?  Faulty 482, or could it be something else?  Should I cut the trace and force RESET to GND?

I checked to ensure that RESET is not shorted to Vcc.

One other item of note is that on this particular dead motherboard, I do get the three keyboard lights illuminating at power on.  They go on for less than a second, then all go out.  If connected to the KVM, they go on, out, on, then out again.

I tried exerting a good amount of thumb pressure on all the QFP chips, then hit reset while still holding pressure, however the board did not come to life.

I measured the clocks along 481, 482, ISA and KBC.  On 481, CLX2/CLK measures 80 MHz; TIMCLK measures 0.  On 482, ATCLK measures 6.67 MHz; KBCLK measures 7.17 MHz; TIMCLK measures 80 MHz; CLK2/CLK measures 80 MHz.  On the ISA slot, CLK measures 6.67 MHz; OSC measures 14.39 MHz.  On KBC, KCLK measuers 5V dc. On the working board, it measures 0 V dc.

I probed OE on the BIOS chip.  Working board has a square wave pulse at about 1 MHz, but the freq. bounces around during the boot process. Dead board has 5 V dc.

I probed A2 on CPU socket.  Working board pulse in KHz range. Dead board, 5 V dc.

Without CPU RESET pin going low, what is left to probe?  I assume I can disregard the previous probing recommendations at this point.  Is the evidence pointing towards the 482, or more likely some other component which feeds into the 482 is faulty, and is making the 482 not want to set RESET to low?

CJAY

You probably don't need to remove that QFP chip to use the PGA socket, at least on the boards I remember the on-board CPU was disabled either by jumper or automatically.

I thought the FLT# pin had to be connected to GND to float the CPU?  For whatever reason, on this board FLT# is connected to Vcc, even though I think it should have be left unconnected (there is an internal pull-up in the CPU to prevent this pin left floating).  Unfortunately, this motherboard does not have a jumper which connects FLT# to GND to flat the QFP AMD 386DX.  However, you are saying that I can leave the QFP enabled and insert a PGA CPU?  From what I understand, I must connect FLT# to GND to disable the QFP CPU.

Rasz

Im guessing you already tested using socketed cpu on one of the working boards to confirm its fully operational on this board model, and experimented with 50MHz(or even 25MHz) clock gen chip?

I did not test my PGA AMD 386DX CPU in one of the working boards because there is no float jumper for the soldered-on QFP AMD 386DX.  If inserting the PGA CPU shows a working motherboard, I would not know if it is the QFP or PGA CPU which is working. I know the PGA AMD 386DX works in other boards (not this MSI board). But this is a good point, perhaps I should try a really low OSC to see if that does anything.   OK, I removed the 80 MHz osc and tried a 20 MHz, still showing no signs of life.  The working boards works with the 20 MHz osc.

I have checked the ISA, KBC, and BIOS to ensure that no pins, other than those indicated on the datasheet, are connected to the corresponding Vcc or GND.

[Rasz]

That looks to be the same datasheet for the UMC Um82C206 that I have. The pin count is wrong  for what I have

its for different package

for what I have and I am measuring GND (Vss) pins for the 206 in completely different locations as specified on that datasheet.

of course, you cant just expect different package to have same pinout.

I'm getting GND around pins 71, 55, and 14.  I also do not measure a Vcc anywhere on the 206, even on the working motherboard.  Does the Vcc from the PSU head to a resistor greater than 50 ohm, in series, before heading to the 206?   Or does Vcc from PSU head to one of these IC's, perhaps to change the output impedance?

1 sounds like you are measuring on powered off system, try powered on. homemade probe made out of a needle is perfect for this kind of thing, or high quality sharp meter probe.
2 later you used "6th in from the top left" phrase, which combined with inability to find VCC makes this whole thing highly suspect
http://www.lapis-semi.com/en/package/images/drawing/dr_l_qfp100-p-1420-0.65-bk.jpg
are you using correct pin numbers? qfp100 pin 1 is clearly marked on the silkscreen with a giant white triangle
3 UM82c206 Vcc is NOT directly connected to power supply (datasheed page 49/50), you cant use continuity/resistance to find it, 206 has integrates real time clock and needs power 24/7, thats what the battery is for D1 Q1 D2 Q2 form two circuits switching power between Battery/external battery J1 connector(J1 is not a keyboard connector as claimed by motherboard pinout floating on the web) and AT supply.


Just looking at 206 PLCC84 pinout, 482 qfp160 pinout and picture of the board with 206 qfp100 I can guess how the pinout shifted.
pin 78 is Vcc, probably also 30
nonetheless UM82c206 is not our problem at this time, it has no mechanism to generate RESET or manage powergood (PG is only an input)

From what I can  tell by DMM probing, the power good (PG) pin from the power supply heads only to GD4069UB (HEX Inverter), the output of which heads to one of the pins on the UMC 206 (6th in from the top left), or around pin 69 on the wrong datasheet

what is 6th from the top? which top?
http://www.lapis-semi.com/en/package/images/drawing/dr_l_qfp100-p-1420-0.65-bk.jpg

and What is the logic level on that pin on good vs bad board when powered on?
also where are the rest of 4069 inputs connected, and where are the outputs going? most likely it splits powergood to at least one more chip, is it also feeding UM82C482?

Nice 386 resources; wish I had time to really get into them.  These days, I hardly have time to shop for groceries.

arent you retired?

The RESET pin from the CPU goes to pin 5 (PESCPU) on the 482 chip. I couldn't find any description for what PESCPU stands for.  Under which conditions does the 482 change PESCPU's output from high to low?  Faulty 482, or could it be something else?  Should I cut the trace and force RESET to GND?

again with the cutting ..
PESCPU might be a typo for RESCPU, reset cpu
we dont know, but we will if we fix this board, charm of reverse engineering.

One other item of note is that on this particular dead motherboard, I do get the three keyboard lights illuminating at power on.  They go on for less than a second, then all go out.  If connected to the KVM, they go on, out, on, then out again.

of course they are, KVM has its own embedded keyboard controller and initializes connected keyboard. Its not possible to hot swap keyboards, they have to be emulated. PC keyboard is not a dummy array of switches, it has its own processor inside.
Irrelevant, I asked you about leds of keyboard plugged into the motherboard, not kvm . I asked because its a cheap indicator of CPU executing bios without resorting to POST cards. One of the things BIOS does quite early on is initialize keyboard - this resets keyboard controller and makes the embedded chip inside keyboard flash all 3 leds once. its a small trick of the trade, useful when sitting in front of dead computer and trying to guess whats going on - keyboard blink but otherwise dead computer indicates at least CPU, CPU power circuit, and bios are fine, so most likely bad ram or graphic card.

Without CPU RESET pin going low, what is left to probe?  I assume I can disregard the previous probing recommendations at this point.  Is the evidence pointing towards the 482, or more likely some other component which feeds into the 482 is faulty, and is making the 482 not want to set RESET to low?

not disregard, leave for later once we get cpu going and board still doesnt work

UM82C482 pins 11 PDC and 12 PWR are interesting
Edit2: nope, those are Processor Data/Control, Processor Write/Read
Edit: also  13 PMIO  and 25 ATRDY
Edit2: nope, Processor Memory/IO, ATready is for ISA bus

146 RSTIN and 26 RESMCP
trace the RESET header (one for the case reset button) and check if its not stuck high, and where its going
Edit: so my guess is something external(4069 + capacitor?) generates reset and feeds 146 RSTIN

Rasz

Im guessing you already tested using socketed cpu on one of the working boards to confirm its fully operational on this board model, and experimented with 50MHz(or even 25MHz) clock gen chip?

I did not test my PGA AMD 386DX CPU in one of the working boards because there is no float jumper for the soldered-on QFP AMD 386DX.  If inserting the PGA CPU shows a working motherboard, I would not know if it is the QFP or PGA CPU which is working. I know the PGA AMD 386DX works in other boards (not this MSI board).

I assumed you did the FLT mod on working board already.

I have checked the ISA, KBC, and BIOS to ensure that no pins, other than those indicated on the datasheet, are connected to the corresponding Vcc or GND.

remove everything removable(except clock gen) from bad board, you dont need any removable chips to at least get a sign of life (cpu starting and trying to access bios), removing redundant chips helps with shrinking our troubleshooting surface

[feipoa]

I do not expect different pin quantity packages to have the same pinout. In the beginning, I did not realise it was QFP-84 vs. QFP-100. I have only managed 4-hrs of sleep per night for the past week. It is catching up with me.  To clarify, I was trying to use the pin numbers on the QFP-84 to provide some idea as to where I'm measuring my current findings.  I was using the numbers closest to any edge as a reference platform.  Instead, I should have counted up the appropriate PGA-100 pin number designations, but was too tired to do so.  When I said a reference from the "top left", I was refering to the top left of the chip with the markings on the chip in the reading position to the viewer.  Again, I should note down the proper QFP-100 pin number.  I have now printed out a blank UM82C206 QFP-100 diagram so I can write on it.  Previously, all I had was the QFP-84 to write on.  GND goes to QFP-100 pins 3, 52, and 77.

Yes, I was measuring with the system powered off.

Interesting - I had forgotten about the switching circuit.  I recall now that I have run into this many years ago in dealing with my SiS Rabbit board. With Vcc high, Vcc connects to 206. With Vcc off, 206 connects to EXT BATT positive header via diode(s). 

Previously, I had removed the EXT BATT for probing, although you can still see it connected on the working board in one of my previous photos.

Yes, I realised early on that J1 is for the EXT BATT.  That 5-pin header near the keyboard DIN-5 is for a secondary keyboard connector, KB2.

Seems like I should be able to determine the Vcc pin on the 206 based on where the positive EXT BATT circuit goes. And it looks like BATT heads to two diodes in series and to a 33 ohm resistor before heading to the 206.  So Vcc is at pins 26 and 78.  Good guess.  I realise this is slightly off focus, so thanks for clearing that up.

PG goes to pin 5 of CD4069UB, the output of pin 5 is pin 6. I misread the CD4069UB diagram last night and was looking at the functional diagram, whos input/outputs are in a different order than on the packaged view of the diagram.
  So, correction, pin 6, the output of the inverter, goes to pin 3, the input of another inverter (same package), the output of which (pin 4) goes to pin 13 of DM74LS14 (located under the KBC). DM74LS14 is listed as a Hex inverter with Schmitt trigger inputs. The other end of this inverter is pin 12, which goes to pin 9 of SN74F32 (2-input OR gate).  Pin 9 is one of the inputs to be OR'd. The output of this OR gate goes to pin 146 of UMC 482 chipset, which it labels as RSTIN.  The other input to the OR gate (SN74F32 pin 10) is the output from DM74LS14 (pin 6). The input to pin 6 is pin 5, which is connects to Vcc via a 10K resistor in parallel with a diode.  Looks messy in words.

Pin 4 of CD4069UB also connects to a 1K resistor, which connects to capacitor C14 in series, which goes to GND.  The other end of that 1K resistor also goes to pin 6 on UMC 206.  Might be best if I draw all this out.  See attachment.  Do you still want me to draw the circuit diagram for the rest of the CD4069UB pins?  PG only goes to pin 5 of 4069.  Some of the other 4069 pins seem form the oscillator circuit with Y2, probably for the RTC.

On the working board (and with the PSU powered on), if I hold down the reset button, the logic level of UM482 pin146 is 5 V.  Immediately when I release reset, logic level is 0 V and stays there.  The outcome is identical for that of the dead board.

On the working board, UM206 pin 6 is 5V always. On dead board, it is the same result.

Retired?  In a sense.  I have 3 kids between the ages of 0 and 5.  Kids are always sick or needy, can never seem to sleep on time, frequently wake up in the middle of the night screeming... needy wife, appointments all the time, always tired.  Playing with computers and electronics is my escape from my daily life, but to do so requires the sacrifice of sleep. Three kids is really the tipping point, for me anyway. By far more exhausting and less mentally rewarding than my previous occupation.

Back on track.  UM482 pin 11 (PDC), starts out at 5 V when holding down RESET button, then bouces around a bit during power on, and ends up being an inconsistent series of pulses in the 8-22 KHz range.  On the dead board, pin 11 stays at 5 V.  However, if I hold the RESET button down for about 4 seconds, then release it, pin 11 shows a pulse train in the 500-800 KHz range.  It is not the same pulse train as on the working board.  Further goofing around with the reset button, and pin 11 can sometimes be made to stay at 0 V.  Not sure what any of this means.

UM482 pin 12 (PDC), 13 (PMIO), and 25 (ATRDY#) - go to their respective pins on UM481, that is, pins 147, 145, 134.  I cannot seem to determine where else they go.  I did not check all the resistor packs because I do not have easy top access for the sandwiched packs.  Do you want me to probe these 3 pins with the scope?  I was hoping they connected to a via for easy access.

No - I did the FLT mod on a dead board.  I desoldered one of the QFP leads, propped it up, then soldered a 30AWG wire to GND.

Its also OK to remove the KBC to get a sign of life?  If I remove the ISA card, what is the sign of life?   PC Beep perhaps?

EDIT: Also added CMOS battery switching circuit.  I didn't triple check this, so there may be errors.

[Rasz]

PG goes to pin 5 of CD4069UB, the output of pin 5 is pin 6. I misread the CD4069UB diagram last night and was looking at the functional diagram, whos input/outputs are in a different order than on the packaged view of the diagram.
  So, correction, pin 6, the output of the inverter, goes to pin 3, the input of another inverter (same package), the output of which (pin 4) goes to pin 13 of DM74LS14 (located under the KBC). DM74LS14 is listed as a Hex inverter with Schmitt trigger inputs. The other end of this inverter is pin 12, which goes to pin 9 of SN74F32 (2-input OR gate).  Pin 9 is one of the inputs to be OR'd. The output of this OR gate goes to pin 146 of UMC 482 chipset, which it labels as RSTIN.  The other input to the OR gate (SN74F32 pin 10) is the output from DM74LS14 (pin 6). The input to pin 6 is pin 5, which is connects to Vcc via a 10K resistor in parallel with a diode.  Looks messy in words.

great, you identified reset circuit.

Pin 4 of CD4069UB also connects to a 1K resistor, which connects to capacitor C14 in series, which goes to GND. 

you drew it wrong on diagram (cap to Vcc instead of Vss), I noticed when logic transitions didnt add up :-)

so here is what happens:

Code: [Select]

power on, PG starts low           -> 6 of 4069 High -> 4 of 4069 Low                                          -> 12 of 74LS14 High -> 8 of 74LS32 High -> RESET is active, system is stopped.
power stabilizes, PG goes High    -> 6 of 4069 Low  -> 4 of 4069 still pulled Low while capacitor is charging -> 12 of 74LS14 High -> 8 of 74LS32 High -> RESET is active, system is stopped.
PG High, nano/microseconds passed -> 6 of 4069 Low  -> 4 of 4069 cap finally charged, letting it go High      -> 12 of 74LS14 Low  -> 8 of 74LS32 Low  -> RESET is inactive, system starts.


The other end of that 1K resistor also goes to pin 6 on UMC 206.  Might be best if I draw all this out.  See attachment.  Do you still want me to draw the circuit diagram for the rest of the CD4069UB pins?  PG only goes to pin 5 of 4069.  Some of the other 4069 pins seem form the oscillator circuit with Y2, probably for the RTC.
 

https://en.wikipedia.org/wiki/Pierce_oscillator standard RTC oscillator on older boards.
Its enough info to check if this circuit works as advertised.

On the working board (and with the PSU powered on), if I hold down the reset button, the logic level of UM482 pin146 is 5 V.  Immediately when I release reset, logic level is 0 V and stays there.  The outcome is identical for that of the dead board.

=manual reset is working

On the working board, UM206 pin 6 is 5V always. On dead board, it is the same result.

just to clarify, we are talking nanosecond pulses here, are you eyeballing the scope, or did you actually set up trigger?
you need to setup scope to trigger on channel 1 high logic level, while the other probe is capturing our event. Then scroll thru the capture and find the reset pulse. Rest at the end of post.

Back on track.  UM482 pin 11 (PDC), starts out at 5 V when holding down RESET button, then bouces around a bit during power on, and ends up being an inconsistent series of pulses in the 8-22 KHz range.  On the dead board, pin 11 stays at 5 V.  However, if I hold the RESET button down for about 4 seconds, then release it, pin 11 shows a pulse train in the 500-800 KHz range.  It is not the same pulse train as on the working board.  Further goofing around with the reset button, and pin 11 can sometimes be made to stay at 0 V.  Not sure what any of this means.

PDC was a red herring, its a signal generated by CPU (DATA/CONTROL), nothing to do with powergood/reset. I mentioned it because it sounded good with that P in front, almost like Power_something . BUT! what you wrote here suggests CPU IS actually working. DATA/CONTROL signal is generated _only_ when CPU tries to execute something.

What it means is earlier " ran the two systems with the probe on the CPU's RESET pin.  On the working board, at hard reset, the RESET pin goes to Vcc, then remains at GND.  On the defective board, the RESET pin stays at Vcc" wasnt entirely accurate.
I suspect Im going too fast, throwing 10 things at once and expecting you to keep up, we need to slow down.

Its also OK to remove the KBC to get a sign of life?  If I remove the ISA card, what is the sign of life?   PC Beep perhaps?

YES. For the third time Lets start with BAD board stripped out, no ram, no cache, no bios, no KB controller, no ISA cards, no keyboard. Just motherboard with AT supply,20MHz clock gen, and RESET button wired up. This is your base line.
First step setup Oscilloscope, trigger on channel 1 rising edge >3V. 4 captures, Power cycle for capture:

probe1 on +5V, probe2 on PowerGood
probe1 on PowerGood, probe2 on Pin 6 of UM82C206
probe1 on PowerGood, probe2 on Pin 146 of UM82C482
probe1 on PowerGood, probe2 on Pin 5 of UM82C482

Trigger set to channel 1 falling edge <3V. 1 capture, press RESET to capture:
probe1 on Pin 146 of UM82C482, probe2 on CPU reset pin (or Pin 5 of UM82C482)

play with timebase so you get both events on the screen (if there are events on both channels), take screenshots.
Btw this is why I suggested that $6 dev board, its faster to setup and capture everything at the same time than constantly swapping scope probes around.

[feipoa]

Yes.  I am trying to accomplish more than I have time for, and trying to do it too quickly while tired.  This is evident from the dialogue -  as you pointed out, I worded the circuit diagram correctly, yet I drew the cap to Vcc incorrectly. Yet I wrote that paragraph before I drew the diagram.  I have since updated the diagram.

Nice write-up on the reset ckt.  Its been so long since I've thought about these circuits, I probably would have overlooked the RC time constant in charging that capacitor.

OK, so you think it is worthwhile to confirm the RTC osc ckt.  Will check.

When I said 5 V, I was, in fact, eyeballing the scope w/out trigger. From your previous responses, I was under the impression that we were looking for rough signals at this stage.  I did not zoom all the way in to look for ns pulses because they are usually, but not always, evident in the zoomed out view. So when I said 0V, I see what appears to be a 0V DC. When I said 5 V, I see what appears to be 5 V DC.  If I'm zoomed out too far, I might not notice pulses.  Should I check this again?  I thought to start we were just looking for obvious high-level differences between the working board and dead board.  Once a difference was detected, then we would view in greater detail with timing and triggering. Is this a flawed approach? 

Glad you're counting, because I lost count!

Moving forward, is this the correct order of operation, or is there something else in the middle text somewhere I also need to re-check?:

1) Confirm RTC OSC CKT

2)

no ram, no cache, no bios, no KB controller, no ISA cards, no keyboard. Just motherboard with AT supply,20MHz clock gen, and RESET button wired up. This is your base line.
First step setup Oscilloscope, trigger on channel 1 rising edge >3V. 4 captures, Power cycle for capture:

probe1 on +5V, probe2 on PowerGood
probe1 on PowerGood, probe2 on Pin 6 of UM82C206
probe1 on PowerGood, probe2 on Pin 146 of UM82C482
probe1 on PowerGood, probe2 on Pin 5 of UM82C482

Trigger set to channel 1 falling edge <3V. 1 capture, press RESET to capture:
probe1 on Pin 146 of UM82C482, probe2 on CPU reset pin (or Pin 5 of UM82C482)

play with timebase so you get both events on the screen (if there are events on both channels), take screenshots.

I appreciate all your help with this, but tonight, I need to catch up on some lost shut-eye.  I'll look into ordering that dev board; hoping to find the package with the female-to-clip jumpers.

[Rasz]

1) Confirm RTC OSC CKT

Im mostly sure 32KHz is fine, and even if it wasnt its not being fed to main chipset so doesnt matter at this time.
I meant checking part responsible for reset.


That happy coincidence of me telling you to measure wrong thing (PDC) and there actually being transitions on it (impossible with RESET stuck high, Intel "5.2.9.4 RESET (RESET)" 386 datasheet) after hard reset might mean power on reset doesnt work, but hard reset is fine. We will see after you measure everything again on stripped board.

You can throw in additional:
Trigger set to channel 1 falling edge <3V. 2 captures, powercycle and press RESET to capture:
probe1 on CPU reset pin (or Pin 5 of UM82C482), probe2 on A2 of CPU
just to be sure

[martinator]

How have you been removing the chips from their sockets, with a screwdriver?

If so check under the chips and socket body for damaged traces. It's easy to fumble around and miss the actual chip and try to lever up the socket instead especially if someone tried this in the past (swapping parts) while the board was still inside a confined space like a case. Make sure all the data and address traces connect to the correct places.

[feipoa]

I haven't yet had time to probe the board w/triggering, but I did check a few items this evening.

1) Drew the RTC OSC circuit diagram and measured the freq. on the two dead and one working board.  They all are 32.77 KHz and the clock goes to UM206 pin 75. 

2) While removing all the board's components, I ran a few tests.

a) On the dead board I've been working with thus far, when I remove the KBC, I do get beep codes and my ISA PC analyser card seems to respond.  It runs through all the codes that the working board does when the KBC is removed.  When I put the KBC back in (on the dead board), the ISA analyser card shows nothing and there are no beeps.  I tried swapping KBC's in the past, and the KBC itself is not the issue.  So perhaps some other component connected to the KBC is at fault.  Might this help narrow down the issue?

b) On dead board #2, removing the KBC does not yield any codes on the ISA PC analyser card - the analyser card still shows nothing, that is, --.  There are no beeps.  So there is a stronger likelihood that each board has a different affliction.

3) I have ordered the DEV board.  I do not know when it will arrive, so I'll continue with the scope this week.

martinator: Thanks for chiming in.  Fortunately, the sockets and board look fairly pristine with no evidence of rough housing to report.

[CJay]

a) On the dead board I've been working with thus far, when I remove the KBC, I do get beep codes and my ISA PC analyser card seems to respond.  It runs through all the codes that the working board does when the KBC is removed.  When I put the KBC back in (on the dead board), the ISA analyser card shows nothing and there are no beeps.  I tried swapping KBC's in the past, and the KBC itself is not the issue.  So perhaps some other component connected to the KBC is at fault.  Might this help narrow down the issue?

KBC can and will hold down the system if there's a problem, at this point it would be really useful for you to get hold of a copy of the IBM AT hardware reference manual, it should have schematics and a circuit description which will explain an awful lot about the KBC and how/why it can prevent a system starting.

[Rasz]

brilliant, lets focus on dead board #1 since it sounds closer to a fix.

1: mark dead board #1 somehow visibly, big sticker on the chipset for example, so we dont get them mixed during debugging
2: mark dead board #2 and put it away for now
3: put stickers on KBC chips so they wont get mixed, and rerun the test swapping KBCs around, just to be sure

similar vintage 486 board diagram, SiS85C460 :
http://www.textfiles.com/bitsavers/pdf/samsung/pc/98134-925-009_DeskMaster_486Q_SD925E_Service_Manual_1993.pdf  "SHEET NO. 9/17" has typical 8042 keyboard controller circuit
8042 compatible datasheets:
http://www.s100computers.com/My%20System%20Pages/MSDOS%20Board/HT6542B%20Keyboard%20Controller.pdf
http://www.diakom.ru/el/elfirms/datashts/Smsc/42w11.pdf

KBC pins that can screw with the boot are 2,3,4,8,10,12,13,14,15,16,17,18,19,40
This sounds mechanical, like putting KBC in the socket shorts one of the those pins.
I would measure resistance (powered off systems) to ground on all of them on empty good/bad board, and repeat good/bad board with same KBC chip in socket. Compare good/bad board readings. If that doesnt find a fault repeat with powered on system measuring voltage instead, again empty/full socket both good/bad boards.
I would lean towards on of KBC chips being bad tho, either pooling reset or clock hard to one of the rails.

[feipoa]

Actually, I already did put the KBC from the known working board into the dead board in question.  I did it last night as a recheck, and swapping KBC's did not help.

I'll probe these KBC pins after the wife and kids have retired for the evening.

[Rasz]

Now that I think about it, start by going over all KBC socket solder joints with soldering iron. Then check with multimeter if all the pins have good contact.
Maybe cracked joint makes one of the pins float and thats the problem. Would explain mechanical nature of the fault.

[feipoa]

That's not a bad idea and is certainly a simple test.  I'll reflow the KBC pins right now.

EDIT: reflowed with rosin core, Kester, SN60 PB40 - showed no improvement though

[Rasz]

then back to measuring
its also possible one of the ttls got weak with age, and addition of KBC loading its output blocks that signal, luckily you have good board to compare to.

[feipoa]

It was rather tedious, but I managed to finish probing the KBC with a digital multi-meter.  I am including the raw data, but a quick summary follows.

All pins showed similar characteristics, except for the following:

On the good board, pin 3 had a 15 M-ohm resistance to GND (PSU:off, w/out KBC), while the bad board was open circuit (drawn as infinite in the raw data).

On the good board, pin 9 had a 286 K-ohm resistance to GND (PSU:off, w/out KBC), while the bad board measured 1.76 M-ohm.

That was about it for resistance measurements.


On the good board, pin 2 measured 900 mV to GND (PSU:on, w/KBC), while the bad board measured 1.96 V.

On the good board, pin 11 measured 900 mV to GND (PSU:on w/KBC), while the bad board measured 4.08 V.

On the good board, pins 12 - 19 measured about 4.4 V (PSU:on w/KBC), while the bad board measured 5.1 V.  This is about the voltage drop of a standard forward biased diode.  Some component on the bad board is shorted out? Perhaps an IC's internal diode or transistor?  Or even an on board diode?

On the good board, pins 35 & 36 measured about 0 V (PSU:on w/KBC), while the bad board measured 5.1 V.

On the good board, pins 34, 32, 31, 30, 29, 28, 27, 23, 22, and 21 measured 5.1 V (PSU:on w/KBC), while the bad board measured 0 V.

On the good board, pin 24 measured 1.17 V (PSU:on, w/out KBC), while the bad board measured 1.77 V.  Again, this difference is about that of the drop across a pn junction diode.

Can any conclusions be drawn from this?  If not, should I pickup with the triggering and screen capture on the 482 and 206 as discussed previously?

There are two IC packages under the KBC: DM74LS14 and DM7407.  I ran a quick check to see if any of the outputs were shorted to inputs, but they were not.

The conditions of measurement were: no SRAM, no BIOS, no RAM.  Soldered on QFP AMD 386 yes, OSC yes, reset SW yes, speaker yes.  Used a digital multi-meter.

[CJay]

Nope, buzz out those pins that show a difference on the good board (power off, KBC out) and track down what they connect to, if your meter continuity check is fast then it will take a minute or two as you can 'sweep' the moving probe across the other chips (I'd also have a look at the schematics and ref manuals)

Check again on the dead board and see if the connections are the same.

I'm also wondering if there's a battery on the board that might have leaked and corroded some tracks now?

No battery on the pics you posted.

I'm inclined to agree the KBC is good, it's a connection problem or a bad solder joint somewhere.

I don't think you're far from the problem now

[Rasz]

pin 3 looks promising, there should be a clock around 5-12MHz fed there, or directly connected crystal.
can you make a picture of the socket under KBC?

trace where pin 3 is going

[paulca]

You do know they don't need to boot to be used for their best purpose as a door stop?

[feipoa]

I have attached a photo of the PCB under the KBC.

I may have found the disconnect.  Rasz was right on the money with pin 3 of the KBC.   Pin 3 goes to a via; from the VIA, the trace goes to C5.  Using the continuity feature of the DMM, I get a beep with Pin 3 to via.  I get a beep from via to C5.  The issue is that even the mildest pressure from the DMM's probe causes that VIA to make contact with the trace.

These boards did have some mild battery acid leak in the past, which I cleaned up with gentle scrapping, ISO, acetic acid, ISO, drying, etc.  It was the most mild case of acid leak I have come across, but I still treated the clean-up as if it was a major corrosive explosion.  I checked all the traces after cleanup.  The issue is that even the mildest pressure from the DMM allowed for contact between trace and VIA.  I'll correct this and report back this evening.

I also made a small correction to the PG circuit shown on page 1.  I missed a pull-up resistor, and cap to GND.

[feipoa]

A great weight has been lifted.  The issue was that one via not making electrical contact.  In fact, the other dead board had the same issue with the same via!  One of the boards also had one SRAM module which was bad.  A bad SRAM module does not allow the system to even beep, nor does the PC analyser card show anything but --.  So happens the bad SRAM was the TAG.  I haven't extensively tested the result, but the system did boot into Windows 3.11.

I was mildly disappointed with the outcome.  I was hoping to learn new troubleshooting techniques and tricks of the trace with the scope and that DEV board I ordered.  I may get the chance yet.  I'll post it in another thread, but I have been working on a PGA-132 to PGA-168 adapter specifically for the TI 486SXL2-66 (same CPU, different package + lower voltage). I was wanting to prototype before designing a custom PCB.

One other comment about this MSI MS-3131 motherboard is that you cannot merely insert a CPU into the PGA-132 when the soldered-on QFP AMD 386DX is installed.  I tried to put in a TI486DLC, but the system did not show any signs of life.  The good news is that desoldering the FLT# pin, and connecting it to GND, allows for use of the PGA-132.  I'm not sure why MSI did not include a float jumper with this motherboard.

Special thanks to Rasz and CJay for their invaluable insight during the troubleshooting process!  Until next time...

[CJay]

Congratulations, glad you got there

Thing is, the vast majority of the things we discussed *are* the fault finding techniques you need, a multimeter will do, a 'scope if you want to get fancy (flippant I know but often all you're looking for is an indication of a signal, not the content of), it's really that simple.

I'm not saying don't buy the test gear, just that the more complex stuff has limited utility because most faults just don't need that much effort to repair, you can plug in 50K of test gear to every board you get but if you don't understand how the board works in the first place then you stand no chance of interpreting the avalanche of information it will produce and it can actually make it way more complex to find the fault.

(I mentioned processor emulation pods because they can turn up occasionally and be *very* cheap, they're very complex but the ones I had were pre-loaded from factory with a bunch of simple to use test routines that would initialise most PC boards and/or test the various support/peripheral chips, RAM, Cache etc.)

[Rasz]

A great weight has been lifted.  The issue was that one via not making electrical contact.

good job

  In fact, the other dead board had the same issue with the same via!

weird coincidence, or solder mask imperfection in source design in that one spot leaving bare copper exposed?

One of the boards also had one SRAM module which was bad.  A bad SRAM module does not allow the system to even beep, nor does the PC analyser card show anything but --.  So happens the bad SRAM was the TAG.

did you try that board without cache before the fix? What usually happens is you get chip in undetermined state hogging the bus, like KBC without clock signal has undefined behavior, can crap on the data bus, can randomly drive its output pins (in fact thats what your measurements shown)
Jumpers dont allow no cache option, but usually cache has to be explicitly enabled by the bios(needs to be pre filled etc), before that every access is treated as cache miss and goes straight to ram.

I was mildly disappointed with the outcome.  I was hoping to learn new troubleshooting techniques and tricks of the trace with the scope and that DEV board I ordered.

I do hope you learned something  at least how to approach the problem, and more or less what happens when system starts, order of things, whats required etc.

I may get the chance yet.  I'll post it in another thread, but I have been working on a PGA-132 to PGA-168 adapter specifically for the TI 486SXL2-66 (same CPU, different package + lower voltage). I was wanting to prototype before designing a custom PCB.

I follow your 486->386 adventures on vogons. Love this kind of stuff. Happy to help.
Edit: Btw it could be possible to clone GAL 16V8 chips from your 486HPi converter, depending on what they are doing.

One other comment about this MSI MS-3131 motherboard is that you cannot merely insert a CPU into the PGA-132 when the soldered-on QFP AMD 386DX is installed.  I tried to put in a TI486DLC, but the system did not show any signs of life.  The good news is that desoldering the FLT# pin, and connecting it to GND, allows for use of the PGA-132.  I'm not sure why MSI did not include a float jumper with this motherboard.

chabuduo
you want fun stories? listen to guy leading Wireless division under Jobs in the nineties (~1999 iMacs/iBooks, Apple was the first to come out with 802.11b, not many people know this)

[feipoa]

ouch, a 3-hour video.  I'll have to span that over a 3-week period to watch.  I'm going to spend this evening getting this guy's MS-3131 board ready with the hardware I agreed to trade him for two working boards, then ship him some hardware and [finally] a working board back to him.

Yes, I tried that board without cache before the fix.  It came with no cache!  It had the same via contact issue.  The via separation may have something to do with my cleaning of the via with various gauge of solid core wire to get any residual corrosion out, usually with 24-30 AWG.  It could also be the combination of mild corrosion plus my cleaning technique.  But I cleaned about 3 vias like this on each board.  Why just these two?  Perhaps they were the most corrosive.  I've had board a lot more corrosive than this in which the vias were fine with lots of cleaning of the vias.  Oh well, water under the bridge now.

What I would like to do is integrate the ultimate 386 benchmark comparison into a new 486 benchmark comparison.  Ideally, use every PGA-132 CPU available, including the Transcomputer module which lets you use an Am5x86 at 160 MHz on a 386 motherboard.  I don't know what motherboard I'll use for this - probably the fastest board which supports all the crazy upgrade modules for PGA-132.  Before I can begin such a task, I would like to get ahold of a TI 486SXL2-66.  They are rare and only one guy on Vogons seems to have one and he paid a ridiculous amount for it.  This is why I set to make my own.  I'm not sure if you've seen these two posts on the subject?

http://www.vcfed.org/forum/showthread.php?58780-How-to-troubleshoot-a-486SXL2-upgrade-CPU-with-an-oscilliscope
and
http://www.vogons.org/viewtopic.php?f=46&t=54953

Do you think its worth starting a thread on eevblog?  I wasn't able to find anyone who was knowledgeable enough to help in those forums, certainly not to your level anyway.  I ended up putting the project on hold.  I'm starting to think I might have an issue with capacitative coupling between the wires, as these 30 AWG wires use a pretty thin kynar cladding and are very tightly pressed against one another.  If you have time to read those posts, what do you think could be the issue?  I still plan to try the module using 8-12 MHz oscillators in hopes to get some signs of life.  What I did not mention in any of those posts, is that I finally got two motherboards to at least display the initial start screen, but the board won't continue into the boot routine.  I think I was using a 33.3 MHz crystal osc.  Aside from those two boards, the other boards act as if the system is dead.

When using a TI486SXL2-66 on a PGA-132, I should not need any GALs or PALs.  From viewing the SXL reference book, the PGA-168 QFP-144, and PGA-132 form factors for the 486SXL are nearly identical.

Are you a vogons of vcforum member?  I'm not sure that I recollect your user name.

Yes, definitely learned more about troubleshooting this time around, but could always learn more.  It would be nice to see more involved troubleshooting threads popup for 386/486 motherboards.  I'd like to come across one in which the chipset went bad.  The worst I've had to replace so far is the Super I/O on a 486 board. e.g. https://www.vogons.org/viewtopic.php?f=46&t=49337  I have sense bought thinner solder for this type of work. 

[Paul Moir]

The via separation may have something to do with my cleaning of the via with various gauge of solid core wire to get any residual corrosion out, usually with 24-30 AWG.

FWIW, I think it was the original corrosion that caused this.  I've seen open vias many times with boards subjected to corrosive chemicals.  I don't know exactly why they seem more susceptible to damage than traces.  When PCBs are manufactured the vias are plated after drilling the hole, so maybe the plating is much thinner than the traces.  Or the lack of soldermask means the damage happens there earliest.  Or perhaps the liquid likes to wick in there and only very slowly evaporate so they have more time to act.  Either way, a caveat when repairing anything with liquid damage.

[Rasz]

ouch, a 3-hour video.  I'll have to span that over a 3-week period to watch.

forum ate my timestamp, lets see

Code: [Select]

https://youtu.be/Tj5NNxVwNwQ?t=1h34mat 1h34m there is a 2 minute story about attitude of Chinese factory managers. Art was responsible for spinning up wireless card factory in Taiwan, and had a very hard time with chabuduo, culture of least effort good enough. PCChips fake cache is another result of that culture trait.

http://www.vcfed.org/forum/showthread.php?58780-How-to-troubleshoot-a-486SXL2-upgrade-CPU-with-an-oscilliscope
and
http://www.vogons.org/viewtopic.php?f=46&t=54953

yeah, dont know about that. 33MHz is the max for IDE cables, and those are multistranded and parallel, not to mention drive strength is huge compared to CPU.
 Original interposer is at least 4 layer for a reason.

...8-12 MHz oscillators...

good idea, this rats nest has a chance of working somewhat reliably around 5-8MHz.
You might also buy/build a cheap clock circuit/signal gen for this sort of thing instead of collecting/manually swapping fixed frequency can generators.
For example 0-160MHz:
$8 https://www.adafruit.com/product/2045
$7 https://www.adafruit.com/product/1500
https://ceworkbench.wordpress.com/2015/05/19/controlling-the-si5351-via-usb/

or borrow/buy real signal gen (>$200 decent used ones).

What I did not mention in any of those posts, is that I finally got two motherboards to at least display the initial start screen, but the board won't continue into the boot routine.  I think I was using a 33.3 MHz crystal osc.

That sounds like signal integrity problems, you can check that with scope capturing all the important lines and analyzing signal shape.

Do you think its worth starting a thread on eevblog?

We have few people into retro here posting in the "Microcontrollers & FPGAs" section, building 8bit computers from scratch etc.
As for other resources on the web for this kind of thing, there is John from S100computers with his great 386 and 486 S-100 compatible boards  http://www.s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm
and recently Andrew trying to build 486 SBC at https://www.retrobrewcomputers.org/doku.php?id=dev:boards:linux-sbc:start

When using a TI486SXL2-66 on a PGA-132, I should not need any GALs or PALs.  From viewing the SXL reference book, the PGA-168 QFP-144, and PGA-132 form factors for the 486SXL are nearly identical.

I meant in case you were thinking of replicating HPI converter.

Are you a vogons of vcforum member?  I'm not sure that I recollect your user name.

Im just a passive member on both.

Yes, definitely learned more about troubleshooting this time around, but could always learn more.  It would be nice to see more involved troubleshooting threads popup for 386/486 motherboards.  I'd like to come across one in which the chipset went bad.  The worst I've had to replace so far is the Super I/O on a 486 board. e.g. https://www.vogons.org/viewtopic.php?f=46&t=49337  I have sense bought thinner solder for this type of work.

and again with cutting/replacing when it wasnt necessary especially when you have working unit for comparison. I would lean toward breaks in address/data bus traces.
At the end of that thread Synoptic describes similar defect, but his serial ports wander around, means most likely damaged config pin traces.

[feipoa]

I am looking forward to watching that video.  missing caps and supreme commander!  I have noticed many motherboards, the MSI MS-3131 included, that there are missing capacitors.  There are solder pads and values silkscreened.  I assume this is a cost-saving measure, or sometimes when you want to exclude features on the board, e.g. no onboard audio.  Looking at the MSI board now, there are a few 0.1 uF caps missing.  Any value in soldering these in?

Wasn't multi-stranded cables mainly for flexibility?  And possibly to take advantage of the skin effect at higher frequencies?  I noticed that the MSI motherboard, usually the trace which contains a clock signal is quite a bit wider.  I think I used a larger wire for the CLK on that PGA168 to PGA132 interposer, 28 or 26 AWG.  Perhaps I should have used 26 AWG or 28 AWG for the whole routing of wires as the cladding is much thicker, then multiply that by 2.  I'll be looking for some troubleshooting steps to see exactly what is the issue, but will start another thread (not now). I'll look into posting a thread in the Microcontrollers and FPGA section later on.

I first need to ensure that the motherboard will work reliably with an 8 MHz oscillator using a packaged CPU.  With an 8 MHz osc, the CPU will be running at only 4 MHz.

I've always liked the convenience of Adafruit products.  I used to work more with the Arduino.   I do have a benchtop signal generator, but it only goes up to 2 MHz.  8K to 160M for $8 is a bargain.   

I probably wouldn't want to replicate the Transcomputer 486HPi upgrade module, for two reasons.  1) It does not work with the PGA-168 486SXL2-66, even when setup as a i486SX.  According to the TI reference manual, there are a few differences between the i486SX and 486SXL which would require some hacking of the module; 2) for my personal interests, using a 486SXL-2 in such an upgrade module which can take an Am5x86-160, feels like one hasn't fully upgraded the system; 3) In my opinion, the TI 486SXL-2 and IBM DLC3 are the last processors which could be argued as still "386-class".  I'd rather use a 486DX with a true 486 motherboard.  This is just my personal preference.

Well, we don't know 100% that the Super I/O on that MB-8433UUD board was still working.  There is the possibility that it did die.  There is also the possibility that it was fine.  I get your point though; I will try to restrain myself with the scalpul until absolutely certain it is needed.  With my knowledge at the time, it seemed like a logical conclusion. 

Back to the MSI MS-3131 motherboards now - I may have pulled the cork out of the champagne bottle a little prematurely.  After having time to text them in greater depth, it appears as if 1 board hasn't been fully rectified.  It is the board which had that bad SRAM module in the TAG position.  My SRAM tester confirmed that this module as bad.  I did replace the module and ran a quick test of the board and seem to recall it booting fine (though it was late in the evening and I was tired).  When I tested the board tonight, I cannot boot the system when the L2 cache is enabled.  I must go into the BIOS to disable the L2 cache, then it boots fine.  If I boot with the L2 enabled, I receive the PC analyser code and screen shoot as shown in the attachments below.

When using the MSI-native AMI BIOS, my PC analyser card spits out: EA E8.  I assume that E8 is the last successful test and EA is the failing one.  Unfortunately, the poorly translated booklet which came with the PC analyser card has a blank box for code EA and E8. 

When I use MR BIOS in the afflicted board, I get code 28 24.  Using the MR BIOS reference code list found online,

Code: [Select]

28: HOOK 6. OEM specific, typically enables shadow, cache, turbo. and 

Code: [Select]

24: Set typematic rate.  A photo of the pc analyser code and screenshot are attached below.  The MR BIOS screen at boot is usually blank at POST, though it sometimes spits out that garbled mess.

What do you recommend testing?  Similar to what we did with the KBC - pin to GND cache in/out, pin to Vcc cache in/out? 

Lastly, a photo of the AMD 386DX pin mod to get the onboard CPU to float.  Luckily, and adjacent pin is GND.

EDIT: I may have located the cause - some shrapnel on the chipset.  All the rubbing of the multi-meter probe across the pins creates metal dust particles.  I'll test it again later to confirm.  I'm also uploading the CMOS switching circuit to the post with the PG circuit.

[Rasz]

I have noticed many motherboards, the MSI MS-3131 included, that there are missing capacitors.  There are solder pads and values silkscreened.  I assume this is a cost-saving measure, or sometimes when you want to exclude features on the board, e.g. no onboard audio.  Looking at the MSI board now, there are a few 0.1 uF caps missing.  Any value in soldering these in?

http://www.analog.com/en/analog-dialogue/raqs/raq-issue-116.html

I've always liked the convenience of Adafruit products.  I used to work more with the Arduino.   I do have a benchtop signal generator, but it only goes up to 2 MHz.  8K to 160M for $8 is a bargain.   

arduino code to control this clock chip https://vk3hn.wordpress.com/2017/02/02/arduino-and-si5351-dds-vfobfo/

EDIT: I may have located the cause - some shrapnel on the chipset.  All the rubbing of the multi-meter probe across the pins creates metal dust particles.  I'll test it again later to confirm.

this would be weird, more likely more cracked traces in the area, maybe under cache sockets

[feipoa]

I have a few arduino products left over, in particular an EtherTen from Freetronics, https://www.freetronics.com.au/products/etherten#.Whq4xrhzORM
I should also have a spare LCD, RTC module, multiplexers, thermistors, numerous 7400 series DIPs, and add-on solder board (goes on top of the EtherTen).  Love these little side projects.  The last project I did many years back was to make an online BTU datalogger for someone off-grid who was using a gasification boiler and a cistern for heating.  When I continue work on the SXL interposer, I'll probably order this little freq. gadget.  What I lack, though, is the opportunity to sit down uninterrupted for more than 1 hr.  Its really difficult to get in the zone under these conditions.  One of the issues I had with the Arduino is that when upgrading IDE's, code written with older IDE's doesn't always work outright, that is without code tinkering.  I'm probably doing something wrong.

I've listened to about 1 hour of that wireless guy's life as an engineer.  Absolutely fascinating.  I started watching while lying down in bed thinking it would be good material to fall asleep with, but on the contrary, it kept me up.

Sounds like the missing components is a result of muntzing, which occurs for 2 main reasons as noted in that URL you shared: 1) cost reduction, and 2) excess components as causing more harm than good.

I mention the electrical wiskers theory because I did notice a small blob bridging two pins of the 482 chip. I removed it, along with double checking all other QFP leads.  Upon doing so, the board worked with L2 cache again.  I noticed in the past that when I've run the multi-meter probes across tightly spaced leads several dozen times that the metal gets smashed and eventually bridges.  This caused much headache for me in the past.  The particular case with these MSI boards may have been left-over residue of solder from when I crossed the leads on the AMD 386DX to float that chip, or it may have been due too much probing, but regardless, there was a small pin bridge on the 482.  I still need to do further testing on this board to convince myself of this.  If it acts up again, I'll have a look at the SRAM traces.

Finally, I have added a double-stacked CR2032 battery holder in place of the rechargeable battery.  It is soldered in the same place, however, I have cut the trace which leads to Vcc and wired it to the EXT BATT header (small wire near R1 and D1).  Refer to the EXT_BATT_CKT on page one of this thread. I also had to desolder the KB2 header.  I don't think I'll ever need that, and if I did, I suppose I could solder the header on the bottom with a 90 degree bend.

My main complaint about this motherboard is that it lacks and async oscillator for the FPU.  The use is limited though.  I suppose if you were running a TI 486SXL2-50 with a 25 MHz FSB, you might want to run your FPU [async] at 40 MHz.

[Rasz]

I've listened to about 1 hour of that wireless guy's life as an engineer.  Absolutely fascinating.  I started watching while lying down in bed thinking it would be good material to fall asleep with, but on the contrary, it kept me up.

Computer History Museums Oral History series is pretty great.

Sounds like the missing components is a result of muntzing, which occurs for 2 main reasons as noted in that URL you shared: 1) cost reduction, and 2) excess components as causing more harm than good.

and 3/ being chabuduo and plain fraud. There is design optimization, and there is Chinese removal of fuses because $.02 more profit.

I mention the electrical wiskers theory because I did notice a small blob bridging two pins of the 482 chip...........If it acts up again, I'll have a look at the SRAM traces.

482 doesnt connect to cache, I cant imagine situation where computer with faulty 482 works without cache, but generates errors with cache on. The only common link is processor data bus, and short here would screw boot every time. Better do some percussive debugging on that board, try touching cache sockets while running etc.

[feipoa]

Yes, I know - I had the same sentiment as you concerning the 482 and would have been more convinced if it had been the 481.  But the order of events is too coincidental. Keep in mind, though, that I also cleared out anything which looked suspect between all leads of the 206, 482, 481, and AM386DX.  I did not swap the cache around between "cleaning".    That is, motherboard not working with L2, symptoms are repeatable from day 1 to day 2; while touching nothing else, I "cleaned" the SMD IC's; powered back up, no L2 errors. 

I'm not saying with absolute certainty that I've isolated the problem, but unless the symptoms reemerge, I'll be following the advice of this popular adage "if it ain't broke, don't fix it".   Of course, I will continue to test the system, move it around, press here and there, etc.  I intend to test an SXL2-50 at 55 MHz, a DRx2-66, and an IBM Blue Lightning DLC3 at 100 and 110 MHz.