Early 5170 Not POSTing

[modem7]

- 8 DATA PINS: Considered good because 1. Successful running of the 'ground I/O CH RDY' procedure; and 2. Post #27 indicates that you see activity on all 8 pins (ruling out bad solder joint and damaged trace).

Related to this.

The 'ground I/O CH RDY' procedure does not check the data path of XD bus --> CPU. (E.g. bytes read from the 8254 chip)

At [here] is something for you to try out in U27/U47 EPROM's, together with your POST card. It will check the data path of XD bus --> CPU. The Zip file includes a DESCRIPTION.TXT file, something that should provide everything that you need to know.

 

[KLund1]

Ok I burned the eproms and ran your code.
I do get and error 99
The codes show 00 FF 40 99
I get the same result from both 8254's I have. So I believe that the problem is not with the 8254's but elsewhere.
I understand the signals go to several places. Do those read back numbers give an idea where the next candidate chip might be?
I do not mind pulling and replacing chips.

 

[modem7]

Ok I burned the eproms and ran your code.
I do get and error 99
The codes show 00 FF 40 99

A reference diagram is at [here].

Per the DESCRIPTION.TXT file for the TEST5438 code:

1. "SENDS VARIOUS BYTES (00/FF/55/AA) TO THE 8254 TIMER CHIP, EXPECTING TO READ THOSE SAME BYTES BACK."
So, chips U67 and U113 are in that data path (80286 --> 8254 --> 80286).
Other chips (not shown in the reference diagram) control the operation of both chips.

2. The error sequence of [00][FF][40][99] means that:
- Step 1: 00h was sent, and 00h successfully read back, then
- Step 2: FFh was sent, but 40h read back instead of the expected FFh.

Pity that you don't have a logic analyser. You would be able to see if:
- FFh was getting to the data pins of the 8254 chip during the I/O write operation;
- FFh was then coming out of data pins of the 8254 chip during the subsequent I/O read operation;
- If the above two good, where the FFh was getting 'lost' on its way from the 8254 to the 80286.

I understand the signals go to several places. Do those read back numbers give an idea where the next candidate chip might be?
I do not mind pulling and replacing chips.

Try U67.

Some people may say, "But U67 must be good because data is being successfully read from the EPROM's." That is good confidence for data heading to the 80286, but U67 also needs to pass data in the other direction, from the 80286.

I'll knock up some other code, code that runs in a loop. In that way, you can look for activity on the /CS pin of the 8254, and the various control pins of U67 and U113. Confidence only.

 

[modem7]

SENDS VARIOUS BYTES (00/FF/55/AA) TO THE 8254 TIMER CHIP, EXPECTING TO READ THOSE SAME BYTES BACK."

Oops. I wrote about the wrong chip.
The "THE 8254 TIMER CHIP" should be "THE FIRST 8259A INTERRUPT CONTROLLER CHIP (U114)".
Sorry about that.

I'll knock up some other code, code that runs in a loop. In that way, you can look for activity ... and the various control pins of U67 and U113. Confidence only.

Presumably, testing U67 is on your to-do list, or perhaps you have a replacement on order.

I have created the code that runs in a loop so that looking for activity on the various control pins will be easier.
It is at [here].
The Zip file includes a DESCRIPTION.TXT file, something that should provide everything that you need to know.