IBM 5150 motherboard repair

[Skip94]

Hi all
I was getting one of my spare 5150's ready to move onto a new home when it failed
It was in the middle of booting, when it died to a black screen. Next power up, it sat on the blinking cursor for 5-10 minutes before I got bored and killed the power. Every subsequent power up, it shows no sign of life and produces a continuous tone from the PC speaker.
I have pulled the last 3 banks of RAM and the ROMs, no change. Pulled the CPU, no change. Only thing that stops the tone is pulling the 8284 clock generator, but I guess thats to be expected.
It seems the continuous tone is not a very common issue with the 5150 board, but reading through the 3 examples on -0degrees has so far not brought me any joy.
I did see U13, LS245 mentioned, so scoped that, all looks fine. I also checked U14 while I was there and found an issue, one of the outputs was held high all the time. Swapped it out for a good LS245 and the output is now behaving as expected, however, no change to the motherboard behaviour.
I'm now at a bit of a loss, but would like to try and diagnose the issue before hitting it with the parts cannon.
Any thoughts would be appreciated
Cheers
Andrew

 

[Endersending]

Check capacitors and power rails. Sounds like a capacitor might have shorted. Check that you have a clock signal on the chip next to the CPU. I can't remember what it is called but it's required for the CPU to start

 

[modem7]

Check capacitors and power rails. Sounds like a capacitor might have shorted

If a tantalum capacitor had gone short circuit, the power supply will not start and produce output voltages. With the motherboard receiving no voltage, there is no possible way that a continuous tone could be produced.

I have pulled the last 3 banks of RAM and the ROMs, no change. Pulled the CPU, no change. Only thing that stops the tone is pulling the 8284 clock generator, but I guess thats to be expected.

Correct.

It seems the continuous tone is not a very common issue with the 5150 board, but reading through the 3 examples on -0degrees has so far not brought me any joy.

You are referring to the web page at [here].

The page that points to that page is at [here]. Note that in the 'Continuous beep (tone)' row, possible causes other than a faulty motherboard are listed.

There are lots of possible reasons that can trigger a continuous tone. Generally, the continuous tone is something that happens on SOME motherboards, when the POST does not execute, or starts executing but (for some reason) terminates early.

I also checked U14 while I was there and found an issue, one of the outputs was held high all the time. Swapped it out for a good LS245 and the output is now behaving as expected, however, no change to the motherboard behaviour.

That would have either prevented the POST from executing, or halted the POST early.
Did you put back in the chips that you removed (CPU, ROM, etc.), although, the last three RAM banks won't be required ?

 

[Endersending]

If you have a clock and the CPU is known to be good it would have to be the ram. Doubtful the ROM chips are bad. Have you checked for bad traces on the motherboard? It would help to have a complete list of things you have checked starting at step 1. It has to be something simple. Make sure the processor has power. Sounds like the computer is going mad as soon as you turn it on like a major component is getting half way powered on and then dieing.

 

[Skip94]

Thanks

If a tantalum capacitor had gone short circuit, the power supply will not start and produce output voltages. With the motherboard receiving no voltage, there is no possible way that a continuous tone could be produced.


Correct.


You are referring to the web page at [here].

The page that points to that page is at [here]. Note that in the 'Continuous beep (tone)' row, possible causes other than a faulty motherboard are listed.

There are lots of possible reasons that can trigger a continuous tone. Generally, the continuous tone is something that happens on SOME motherboards, when the POST does not execute, or starts executing but (for some reason) terminates early.


That would have either prevented the POST from executing, or halted the POST early.
Did you put back in the chips that you removed (CPU, ROM, etc.), although, the last three RAM banks won't be required ?

Apologies, I should add some points.
The board is now on the bench and is being powered using a modern, known good power supply.
Everything bar the last 3 banks of RAM is back in the board.
The CPU and the 8284 have been tested in another PC.
I have checked that the CPU is getting a valid 4.77MHz clock, the reset line is behaving correctly and there are no signals that immediately jump out to be as being "wrong". However, my knowledge of repair is limited.
I have a pretty decent, modern scope, but am still learning how to use it properly!
I think my next step is to build an adapter to put a 28C64 into the ROM sockets and try running Ruud's diagnostic ROM. I think I'm expecting it to not even run, but I can at least rule it out.
Thanks
Andrew

 

[Endersending]

The steps to fix the motherboard are on minuszerodegrees.net Go through the steps from the start. there has to be a bad logic chip or bad first bank of ram.

 

[modem7]

I have a pretty decent, modern scope, but am still learning how to use it properly!

... the reset line is behaving correctly ...

So, per what is shown at [here]. In that example, the power-on-to-power-good delay is about 300 ms, which easily exceeds the minimum requirement in the IBM 5150 of about 1 ms.

I think my next step is to build an adapter to put a 28C64 into the ROM sockets and try running Ruud's diagnostic ROM. I think I'm expecting it to not even run, but I can at least rule it out.

Yes, after what you have done so far, Ruud's Diagnostic ROM (RDR) is a good thing to try. A possibility is that RDR might start and then, due to a problem, stop before you see anything on-screen. That can be detected by, per [here], observing checkpoint 33 appear. The preferred device to observe 33 is a parallel/LPT reader device, because a significant amount of code needs to successfully execute before 33 is sent to the COM1 (serial) port.

If RDR is not starting, then then the next thing to try is the procedure at [here]. Note the 'Test equipment required' section.

 

[Skip94]

So, per what is shown at [here]. In that example, the power-on-to-power-good delay is about 300 ms, which easily exceeds the minimum requirement in the IBM 5150 of about 1 ms.


Yes, after what you have done so far, Ruud's Diagnostic ROM (RDR) is a good thing to try. A possibility is that RDR might start and then, due to a problem, stop before you see anything on-screen. That can be detected by, per [here], observing checkpoint 33 appear. The preferred device to observe 33 is a parallel/LPT reader device, because a significant amount of code needs to successfully execute before 33 is sent to the COM1 (serial) port.

If RDR is not starting, then then the next thing to try is the procedure at [here]. Note the 'Test equipment required' section.

My power on to power good delay is 275ms. And the behaviour of the PG and reset lines is exactly like your diagram.
I made an adaptor and installed Ruud's diagnostic ROM. I fitted the IBM MDA adapter and used the parallel port on that for a parallel port POST code reader. That shows nothing at all.
However, I want to test this setup on my working 5150 before committing to any results. It is a very cheap POST code reader and the only other time I used it, on a stone dead PS/2 model 80, I also didn't get any results on it, so I don't 100% trust it.
Next, I did the 'ground I/O CH RDY' procedure. All is fine up to step 6. The CS line on U33 is high, rather than the expected low. I've now got to call it a day and go to work, but next I'm going to study how the CS signal is generated.
Thank you for you help, I really appreciate it
Andrew

 

[modem7]

Next, I did the 'ground I/O CH RDY' procedure. All is fine up to step 6. The CS line on U33 is high, rather than the expected low. I've now got to call it a day and go to work, but next I'm going to study how the CS signal is generated.

The reference diagram is at [here].

That diagram shows pulses/activity on various lines, but in the 'Ground I/O CH RDY' procedure, the signals will be static. You are expecting:

U6 (8288) pin 7 = LOW

U14 pin 1 = HIGH (i.e. gate from 'A' pins to 'B' pins)
U14 pin 4 = LOW
U14 pin 16 = LOW

U46 pins 1 through 3 = HIGH
U46 pin 4 = LOW
U46 pin 5 = LOW
U46 pin 7 = LOW

 

[Skip94]

Ok, so I have made some mistakes in this troubleshooting. Lesson learnt, always double check everything!
So originally I replaced U14, which appeared faulty on the scope. I then refitted all the ROM chips and tested. Nothing. I now realise that I had the ROM chips in the wrong sockets. U33 in U29, U32 in U30, etc, etc.
Anyway. I fiddled around with it for a bit, before initially posting on here.
At some point during my tinkering, I had accidentally swapped back in the faulty U14. I definitely put a good one in when I first tried it, but obviously the wrong ROMs gave the illusion of being faulty.
Testing this morning showed some very odd signals on U14 as per Modem7's instructions above, which lead me to find the wrong U14 fitted. Swapped that out and suddenly Ruud's diagnostic ROM would give one beep, then a continuous tone of a much higher pitch than the initial problem tone. It would also click the tape relay.
Plugging an MDA card in would result in the original "low" continuous tone.
Plugging a CGA card resulted in one line of text saying "Ruud's diagnostic ROM" etc, and the high pitched tone as above. It is almost as if it is freezing as it starts.
For a laugh, I put the original BIOS ROM back in the correct place this time and to my surprise, it booted straight into BASIC, with only the errors for missing keyboard, no -5v and the 2nd-4th banks of RAM missing.
I shall do some more testing this evening to see if I can get Ruud's ROM to work properly and to check it all behaves correctly.
However, I have to say a massive thank you for the help on here, especially to Modem7. Your instructions and site are so incredibly helpful, that as someone who's background is definitely not in electronic engineering, I can follow, understand and learn. Just this little bit of prodding around has really helped my understanding of the principles and methodology behind working on these systems.
Andrew

 

[modem7]

For a laugh, I put the original BIOS ROM back in the correct place this time and to my surprise, it booted straight into BASIC, with only the errors for missing keyboard, no -5v and the 2nd-4th banks of RAM missing.

For that to happen, quite a lot of code needs to successfully execute.

... is to build an adapter to put a 28C64 into the ROM sockets and try running Ruud's diagnostic ROM.

How confident are you in that 28C64 and adapter ?