Yup, another IBM 5160 failed motherboard

[modem7]

Pin 13 gives red 5 V, instead of pulses. So definitely a problem?

It is informing you that either:
* The POST is not starting, or
* The POST is starting, but not getting as far as step 13.

Can I check if the CPU is halted?

Yes, but that will not inform you of what caused the halt, or when the halt occurred.

I checked with the other ROM chips. It did not work. But then these other ROM chips are from upgraded MB from 16-256 to 256-640 by IBM. So it is another version of the ROMs 1986 compared to 1983 (the failed one) and this upgraded MB has some extra cables around the ROM chips. So I am not sure it was compatible?

The "extra cables" on your 'upgraded' 256-640KB board will be IBM's rewiring to accommodate 27256 type ROM's. Some photos in links at the bottom of [here].

The 05/09/86 BIOS on a 64-256KB motherboard should, at the least, start and display something. I will put the 05/09/86 BIOS into my 64-256KB motherboard, and report back.

PB7 on 8255 shows no state. The logic probe diodes are all dark.
It is supposed to be high?

At power-on time, PB7 will be an input. Per step 5 of [here], the POST configures the pin as an output. So your measurement indicates that if (and if) the POST is running, it is not getting as far as step 5.

And when I say that there is "clock" actually 3 diodes are on: red, orange (pulse) and green. It is not just blinking the orange one (pulse). Maybe when the frequency is too high is like that. It is the 3 instead of a pulsing orange diode.

The manual for your logic probe will tell you what it displays for different things.

[modem7]

Can I check if the CPU is halted?

See post #22 at [here].

[tonata]

Thanks!

The 3 pins 26,27,28 S0,S1,S2 are all high. So this is a HOLD state. Here it is called "passive" and it means "No Bus Cycle".
Ready pin is HIGH.

In the past there was some suspicious behavior of 8255A, but it still worked OK. Could this be explained by a defective IO chip 8255A?

Maybe I can measure the clocks with oscilloscope of the other chips and rule them out?

[modem7]

The 05/09/86 BIOS on a 64-256KB motherboard should, at the least, start and display something. I will put the 05/09/86 BIOS into my 64-256KB motherboard, and report back.

I did that, and as expected, I saw a RAM count-up on the screen. So you can rule out a faulty BIOS ROM chip as the problem cause.

In the past there was some suspicious behavior of 8255A, but it still worked OK. Could this be explained by a defective IO chip 8255A?

The 8255A would have to be faulty in a way that interferes with operation of the address or data buses. Quite a few chips can do that.

(The "suspicious behavior of 8255A" that you refer to will be what you observed during the time that we were fixing your 'keyboard port does not work' symptom. From memory, the 'suspicious behavior' was later explained by a detailed look at what the POST does with PB6 and PB7 under certain failure modes of the keyboard interface circuitry.)

[modem7]

For the IBM 5160, the sequence of events that occurs before the POST starts is shown at [here]. To verify that ALL of that is happening, you would need a range of different test equipment (and the knowledge of how to use them).

[tonata]

8284 pin 10 goes from high to low.
So I see that chips are taken out of "reset state". The CPU pin 21 is low. The 8255 pin 35 is low. U21 pin 8 is low.

So now I can check if the 8088 is sending to the 8288 'Read Data from Memory' which is S2,S1,S0 = 1,0,1

How to test U14/U16/U17 ?

I can check if /CE goes to LOW on U18 to see it the ROM chip was successfully accessed.

[tonata]

Here there is a very cheap logic analyzer: https://www.amazon.fr/AZDelivery-Log...ef=sr_1_1_sspa
It is rather popular.
With this one I can detect how each pin changes on every IC, right?

[modem7]

So now I can check if the 8088 is sending to the 8288 'Read Data from Memory' which is S2,S1,S0 = 1,0,1

A logic analyzer. Again, like any test equipment, you will need to gain the knowledge of how to use it. You have a functioning 5160 motherboard and so you can use that for learning, and to see what the logic analyzer is expected to show on your faulty 5160 motherboard.

How to test U14/U16/U17 ?

In the day, we used an 'in-circuit logic IC tester'. For example, to test a soldered-in 7403 chip, we informed the tester that:
* a 7403 chip was being tested; and
* which pins of the chip that the circuit tied HIGH; and
* which pins of the chip that the circuit tied LOW.
We then clipped the tester's IC clip onto the 7403 chip then ran the test. The test would last a second of so.

That in-circuit test of the 7403 could have be done manually, temporarily tying input pins HIGH and LOW as required to verify the operation of each of the 7403's four NAND gates. Time consuming, and I always worry about the fact that in tying an input pin to HIGH or LOW, somewhere on the circuit, the output of a TTL device is being tied HIGH or LOW; is there a possibility of damage? I have used the technique over the past, say, 10 years, (usually to simulate a failure, rather than as part of failure detection) and have not (yet) seen damage.

Sometimes when I am fault finding a 5150/5160 motherboard that does not appear to be starting the POST, a quick look using my logic probe will reveal some activity on the address and data buses. Let us assume a 5160 motherboard. As an example, on U16 (a 74LS244 quad driver), I see activity on the (joined) enable pins, activity on all gate input pins, but one of the output pins shows no activity. Being TTL circuitry, it is very unlikely that something connected to the output pin is causing the problem, and so I would replace U16 with new.

For a transceiver on the data bus, you may see activity on all expected pins, but the problem may be that for one or more gates, the transceiver is not driving in one direction. Use of a logic analyzer will pick that up.

On the motherboard shown at [here], not only were there faulty chips, but battery leakage had caused faulty vias as well.

I can check if /CE goes to LOW on U18 to see it the ROM chip was successfully accessed.

So, like the text written at [here], activity on the /CE pin only informs you that the address decoding logic is sometimes asserting U18's /CE pin.
Activity gives good confidence, but maybe the address decoding logic is faulty, only decoding some of U18's address space.

[modem7]

Here there is a very cheap logic analyzer: https://www.amazon.fr/AZDelivery-Log...ef=sr_1_1_sspa
It is rather popular.
With this one I can detect how each pin changes on every IC, right?

Only 8 channels. That is quite limiting.

Okay for for something like [this], where only 4 channels are needed (POWER GOOD, PA0, PA1, PA2).

But, for example, what if you wanted to monitor the addresses and data lines of the U18 ROM, to verify that the addresses in and the data out is as expected. U18 has 14 address pins and 8 data pins. So, at the least, 22 channels. Then if you plan to use POWER GOOD or RESET as the trigger, you will need another channel. You will need to monitor the /CE pin as well, so you can tell which addresses on the address bus are being used by U18, and on the data bus, the time slots that are expected to contain U18 output data.

And when looking at the output of the ROM, you need to cater for the 8088's 'prefetch' mechanism.

And for channel count, the requirement gets greater for 16-bit systems (more address and data pins). But, in some cases, there is at least one workaround for insufficient channel count. At [here], I am monitoring the address and data pins on the BIOS ROM's of an IBM 5170, but my logic analyser does not have enough channels to simultaneously monitor all address lines and all data lines and some other things. So, in one operation I monitored all address lines and half of the data lines, then in another operation, changed to monitoring the other half of the data lines, then I manually pieced together the information.

[tonata]

The logic probe sampling frequency is 2 MHz. That is not enough? I need like 10 MHz sampling frequency to capture data been transmitted at 4.77 MHz ?