• Please review our updated Terms and Rules here

Faulty 5150 Motherboard

VeryVon

Miner 2049'er
Staff member
Joined
Oct 21, 2021
Messages
325
Location
Land of the Cheesesteak
Hello, recently acquired a 5150 in good condition, however no signs of life. I followed the excellent troubleshooting guide at minuszerodegrees.net and ascertained there was a short on the 12V bus, after which I replaced the capacitors to resolve that issue. Still no beeps though, so on to the faulty motherboard section...

Under closer inspection the board looks good, and I re-seated all the socketed chips save for the memory. The clock has the correct frequency, and it looks to have quite a bit of ringing to it:

1677445282024.png

However, no pulses on pin 13 of the 8253 chip, so on to the ground I/O CH RDY Procedure!

I have to stop here and say this whole troubleshooting section on www.minuszerodegrees.net is amazing and so well put together. It’s a great example to learn from and could be used as applied knowledge to other machines. Truly great stuff.

So I’ve verified that all of the things are true at the top of the I/O CH RDY Procedure: (I forgot to mention I burned a Ruud's diagnostic ROM onto a 2564, more about that at the very end)

• Motherboard proven as faulty; and
• Motherboard is not faulty in a way that overloads the power supply (see here); and
• No on-screen video; and
• No POST beeps from the IBM BIOS ROM; and
• You tried re-seating socketed chips; and
• A thorough visual examination of the motherboard did not reveal a problem; and
• No error beeps from the SuperSoft diagnostic ROM; and
• Use of a logic probe does not reveal pulses on pin 13 of the 8253 chip - see here. <---- Pulses would indicate that the IBM BIOS ROM (or SuperSoft ROM) is being executed
• You have verified that the 8284A chip is generating a 4.77 MHz clock signal, and you can observe that clock being received on pin 19 of the 8088 CPU, and observe it also being received on pin 2 of the 8288A bus controller chip.
• You have verified that the reset pin of the 8088 CPU is LOW.

p.s. I also verified all three voltages are present in each row of memory.

Everything up to step 9 of the procedure is good using the original 5700671 IBM ROM, but after that it gets muddy:
  • During Procedure 10 of 13 (exercising the data buses all zeroes) I can burn all zeros to a 2564, but when I run the procedure I get all ones on the data bus (directly on the eprom, and at the cpu)
  • Procedure 11 of 13 (exercising the data buses all ones) appears to work, but I don’t have confidence in it because the previous test also had all ones on the data bus.
  • I haven’t attempted 12 or 13 yet.
Important Observations:

Occasionally I noticed that there would be beeping, but the beep is so quiet it can barely be heard unless you put your ear very close to the speaker. It’s inconsistent and I can’t get the beeps now, and I didn't have them consistently enough to cross-reference to the diagnostic rom manual. At one point there definitely was quiet two-tone beeping. Very hard to hear though.

I just noticed that the 8284A chip is very hot. Not fry an egg hot, but if you hold your finger there for more than a few seconds you can feel it start to burn.

I’m using TMS2564-35 eproms and they seem to erase, burn and verify fine on the GQ-4X using the 2564(TEST) profile.

1677445629966.png

1677445669129.png1677445689589.png
1677445710744.png
 
The clock ..., and it looks to have quite a bit of ringing to it:
Was the ground lead of the oscilloscope probe connected to the ground pin of the chip under measurement ?

Occasionally I noticed that there would be beeping, but the beep is so quiet it can barely be heard unless you put your ear very close to the speaker. It’s inconsistent and I can’t get the beeps now, and I didn't have them consistently enough to cross-reference to the diagnostic rom manual. At one point there definitely was quiet two-tone beeping. Very hard to hear though.
So, inconsistent symptoms.

I just noticed that the 8284A chip is very hot. Not fry an egg hot, but if you hold your finger there for more than a few seconds you can feel it start to burn.
I brought out a 5150 motherboard. After 30 minutes of operation, my finger revealed the 8088 and 8284A as the warmest chips, with the 8284A being warmer than the 8088. The 8284A gets quite warm, but I was able to hold my finger on the 8284 for 30 seconds - more than that seemed pointless (I actually thought my finger was drawing heat away from the chip).

The fact that your 8284 is starting to 'burn' your finger is a worry. Do you have a known-good 8284A that you can swap in ?

During Procedure 10 of 13 (exercising the data buses all zeroes) I can burn all zeros to a 2564, but when I run the procedure I get all ones on the data bus (directly on the eprom, and at the cpu)
If the data out of the ROM is not as expected, there is no point then looking at that same data at the CPU.

Earlier, as expected, you saw EA hex out of the IBM BIOS ROM. So, what's going on with the 2564 EPROM! Your 2564 burning process is the same as mine, detailed at [here]. The 350 ns access time of your 2564's should not come into play for the 'Ground I/O CH RDY' procedure. Given that the motherboard symptoms appear to be inconsistent/unstable, I wonder if the /CE pin on the 2564 is now not being asserted, whereas it was before when you had the IBM BIOS ROM fitted. When you are seeing all ones, is the /CE pin low ?
 
Was the ground lead of the oscilloscope probe connected to the ground pin of the chip under measurement ?
In the scope trace I posted, yes. At first it wasn't but when I saw the ringing I moved it to the ground of the 8284. There was a little improvement but not much.
So, inconsistent symptoms.
Yes, and now I can't seem to get any of the quiet beeping again.
I brought out a 5150 motherboard. After 30 minutes of operation, my finger revealed the 8088 and 8284A as the warmest chips, with the 8284A being warmer than the 8088. The 8284A gets quite warm, but I was able to hold my finger on the 8284 for 30 seconds - more than that seemed pointless (I actually thought my finger was drawing heat away from the chip).
Thanks for checking that! Unfortunately I don't have a spare 8284 to test with unless I remove it from my 5160, I'll have to consider that depending on availability. I see some from china on ebay, but I don't trust them.
If the data out of the ROM is not as expected, there is no point then looking at that same data at the CPU.
Agree, I guess I was just doing it out of habit :)
Earlier, as expected, you saw EA hex out of the IBM BIOS ROM. So, what's going on with the 2564 EPROM! Your 2564 burning process is the same as mine, detailed at [here]. The 350 ns access time of your 2564's should not come into play for the 'Ground I/O CH RDY' procedure. Given that the motherboard symptoms appear to be inconsistent/unstable, I wonder if the /CE pin on the 2564 is now not being asserted, whereas it was before when you had the IBM BIOS ROM fitted. When you are seeing all ones, is the /CE pin low ?
/CE pin is confirmed low during all my testing according to your diagram, and I haven't seen it waver.

Yes exactly what's going on with these 2564 EPROMS?! So strange. Purchased from the UK so I'm fairly confident in them, and I can verify what's on them with the GQ-4X. The bus works perfectly with the IBM BIOS, so it doesn't make sense everything would go high when the 2564 is in play.

I'll reset tomorrow and try again, do a few more burns and try a few more things, maybe move on to steps 12 & 13 to learn something new. I also have one of those inexpensive 8 channel USB logic analyzers I can snoop the bus with and take some recordings with PulseView.
 
/CE pin is confirmed low during all my testing according to your diagram, and I haven't seen it waver.
So, what about the Vcc pin? (And perhaps use the oscilloscope.)

Yes exactly what's going on with these 2564 EPROMS?! So strange. Purchased from the UK so I'm fairly confident in them, and I can verify what's on them with the GQ-4X. The bus works perfectly with the IBM BIOS, so it doesn't make sense everything would go high when the 2564 is in play.
As independent verification, do you have a breadboard? Using the 2564 in it, you could ground the /CE pin, and put the address of the reset vector onto the address pins, and then see what comes out of the data pins.
 
Uh... in that picture you have a 28 pin EPROM in a 24 pin socket with pins hanging out over the edge unconnected. It's not going to boot that ROM.

You need a Motorola 68764/68766 EPROM which is a 24 pin direct plug-in type or make an adapter to hook up pins 28 and 1 of the EPROM to Vcc, pin 2 of the EPROM to 20 of the socket, and pin 27 of the EPROM to ground. Pin 22 of the EPROM (normally plugging into pin 20 of the socket should be connected to Vcc.

And yes, it's normal for that 8284A to run very uncomfortably hot.
 
Uh... in that picture you have a 28 pin EPROM in a 24 pin socket with pins hanging out over the edge unconnected. It's not going to boot that ROM.
@channelmaniac yea I know right! I wouldn't have thought to do it, but minuszerodegrees.net has an article on how! Would have never thought of that myself :)
The data sheet of the TMS2564 includes, "The TMS 2564 is compatible with other 5-volt ROMs and EPROMs, including those in a 24-pin package."

Use of the 2564 in the IBM 5150 was bought to our attention by member jafir - see [here]. I gave it a go, and it worked nicely.

Outstanding research for me is the access time. From the 'TMS 2564-45 JL' data sheet floating about online, the TMS2564 can be as slow as 450 ns. Is that too slow for the IBM 5150? Per [here], IBM do not indicate a minimum specification. Like Jafir, the TMS2564 that I acquired, have no speed indicator printed after the '2564'.

( Other EPROM/EEPROM substitution options for socket U33 are at [here]. )
 
As independent verification, do you have a breadboard? Using the 2564 in it, you could ground the /CE pin, and put the address of the reset vector onto the address pins, and then see what comes out of the data pins.
Results from the breadboarding session are in. I wrote hex 55 to one of these 2564's and did some testing. 0101 data didn't come out until I applied 5V to pin 28, so I'll create a small jumper wire, burn the diagnostic ROM and try again!

1677519561470.png
 
That's interesting because the data sheet seems to indicate that pins 26 and 28 are jumpered together internally. I wonder if that's damaged on your chip? There is a warning that says not to use the jumper for PC Board current.
 
That's interesting because the data sheet seems to indicate that pins 26 and 28 are jumpered together internally. I wonder if that's damaged on your chip? There is a warning that says not to use the jumper for PC Board current.
Indeed that could explain it! (damaged chips) and I have been thinking what else could be wrong with them, although they seem fine on a breadboard. I created the diagnostic ROM and tried with the jumper, but alas still no beeps.

I wrote all hex 55's on a chip as in step 12 of the ground I/O CH RDY Procedure and I'm getting differentiated readings on the data bus now, but what I noticed is the logic tester is silent on the low data lines (Q7, Q5, Q3, Q1) I checked the voltage on those pins and it's a bit high? (see below) During the breadboard experiment logic testing was audible for high & low.

Q7 - .82 V
Q5 - .78 V
Q3 - .76 V
Q1 - .74 V

The even lines are as expected, 4.6V. Ground looks good, Vcc is 5V
 
I wrote all hex 55's on a chip as in step 12 of the ground I/O CH RDY Procedure and I'm getting differentiated readings on the data bus now, but what I noticed is the logic tester is silent on the low data lines (Q7, Q5, Q3, Q1) I checked the voltage on those pins and it's a bit high? (see below)

Q7 - .82 V
Q5 - .78 V
Q3 - .76 V
Q1 - .74 V
Per [here], Q7 is expected to be interpreted by receiving chips as neither high nor low. All are unacceptable (output voltage not below 0.5V)

During the breadboard experiment logic testing was audible for high & low.
Of note, on the breadboard, the 2564 is only driving your logic probe, whereas, when the 2564 is fitted to the 5150 motherboard, the 2564 drives all chips on the external data bus (diagram at [here]).

Rhetorical: Is this fan-out related? If so, why would the fan-out of your 2564-35 be less than the fan-out of the 2564 (no dash suffix) that Jafir and I have? I cannot see a fan-out figure in the data sheet for the 2564-45. Did you try a second 2564-35 in case one is 'flakey'?

Rhetorical: Is there something abnormal on the external data bus? If so, how is it affecting all bits, and not just one?

Rhetorical: A grounding issue of some kind on the motherboard? The ground pin of the U33 socket not adequately grounded? With the 2564-35 in the U33 socket, any change in behaviour if you connect the the ground pin of the 2564-35 to a nearby chip?
 
That's interesting because the data sheet seems to indicate that pins 26 and 28 are jumpered together internally. I wonder if that's damaged on your chip? There is a warning that says not to use the jumper for PC Board current.
Out of curiosity, I brought out my box of spare chips, located the 2564's (no dash suffix), and did a resistance measurement between pins 26 and 28 of them. All measured about half an ohm.

And to my surprise, I discovered some 2564-35's. They too measure about half an ohm between pins 26 and 28.

Indeed that could explain it! (damaged chips) ...
More than one chip 'damaged' in the same way! I am thinking, how did that happen.
 
Outstanding research for me is the access time. From the 'TMS 2564-45 JL' data sheet floating about online, the TMS2564 can be as slow as 450 ns. Is that too slow for the IBM 5150? Per [here], IBM do not indicate a minimum specification. Like Jafir, the TMS2564 that I acquired, have no speed indicator printed after the '2564'.
Having discovered today that I have some 350 ns version of the 2564, the 2564-35, I programmed a 2564-35 with the 10/27/82 revision of IBM 5150 BIOS, then tested that on a 5150 motherboard.
It seemed to work okay. At every cold boot (I did about 10), I would see the flashing cursor, and watched as a boot into Cassette BASIC happened.
 
Ok finally have something! Still no beeps, but something on the screen!
Yay !

Still no beeps, ...
A failure related to the 8253 timer chip.
Per [here] and [here], the 8253 timer chip is involved in speaker operation.
And with the IBM BIOS ROM fitted, presumably step #8 at [here] failed, resulting in the POST simply halting the CPU.

Referring to the diagram at [here], do you see a 1.193 MHz clock on the three CLK pins of the 8253 ?
 
So, what is Rudd's diagnostic up to when it tests 8253 channel 0? It is writing/reading values to/from I/O port 40h. Refer to the diagram at [here]. Therefore, when the 8253 channel 0 test is being done, we expect activity on the /CS, /WR, and /RD pins. See that?
 
Broke out the logic analyzer for this one. Here's what the overall activity looks like from boot to halt:

5150 8253 Chip Trace.PNG

Here's a magnified view of what the pulses look like in the middle:

5150 8253 Chip Trace Zoom 1.PNG
 
Roughly looking into Ruuds DiagRomV2.asm I can see the routine is reading, writing and then comparing bits interfaced to the 8253. I'm also having a look at the 8253 datasheet. At this time I can't quite grok if the 8253 is failing, or something else is stomping on the bus. I'm not very familiar with IBM bus protocols either, I'll have to do some digging on that.

Code:
;**  Common routine for checking the channels of the 8253 timer
; in:    DX = address of channel
Check8253:
    mov    ax,dx            ; AX := address of channel to be tested
    and    al,3            ; we only need the first two bits
    ror    al,1
    ror    al,1            ; bit 1..0 -> bits 7..6 = counter
 
    mov    ah,al            ; save counter bits
    or    al,34h            ; read/write counter bits 0-7 first,
                    ;    then 8-15
                    ; mode 2 select - rate generator
    out    43h,al

    xor    cx,cx            ; CX := zero
    mov    bx,cx
   
    mov    al,cl            ; AL := zero
    out    dx,al            ; write bits 0..7

    nop
    nop

    out    dx,al            ; write bits 8..15

    mov    di,4
.L20:
    nop
    nop

    mov    al,ah            ; AL := counter
    out    43h,al            ; latch command

    nop
    nop

    in    al,dx            ; read counter bits 0..7
    or    bl,al            ; save read value

    nop
    nop

    in    al,dx            ; read counter bits 8..15
    or    bh,al
    cmp    bx,byte -01h        ; result is OK?
    je    .L30            ; yes, ->
 
The question is, which of the following is the case:
Possibility #1: 8253 is good, but the signals/address/data to it is bad; or
Possibility #2: 8253 is bad; or
Possibility #3: 8253 is good, signals/address/data to it are good, but the data out of it is being 'damaged' on its way to the CPU.

I rarely 'dive in deep' initially. Probability also comes into my consideration. In your situation (timer channel 0 test failing), if using a logic probe, I saw activity on the 8253's:
- /CS pin; and
- /WD and /WR pins; and
- A0 pin; and
- XD pins (external data bus),
I would probably, at that time, decide to swap in one my known-good 8253's, and add an IC socket whilst I'm at it.

I appreciate that not everyone has known-good 8253's 'ready to go'.

If that didn't fix the failure of the 'timer channel 0 test', then I would start 'diving in deep'.

For example, per [here], both the BIOS ROM and 8253 use the external data bus, and so, as an initial test of 'possibility #3' above, I might do all 13 steps of the procedure at [here]. A pass would not be conclusive though - imagine a bad solder joint on one of the 8253's data pins.

To test 'possibility #1', I could write some code to go into my own test ROM. The code would continuously write and read I/O ports 40h (counter 0) and 43h (mode). Written would be the values of 00 and 55 and AA and FF. I then use my logic analyser to see if the signals/address/data going to the 8253 are as expected.

If all that is as expected, I then put the '8253 test' code from Rudd's diagnostic into my own ROM, modifying the code so that I get an indication of exactly at which point in the code, the failure occurs at. What I then do depends on where the failure occurred.
 
Back
Top