The Bi-Weekly British Backtrack – Disco Fever Pinball Restoration 04
by, 03-02-2012 at 03:38 PM (1402 Views)
OK, OK so I missed the usual Bi-Weekly entry a fortnight ago but, like Microsoft and their Cloud Services, I blame it on the leap year so expect the same thing to happen again in four years time. Now that normal service is resumed I need to segway from the Leap Year to Pinball.
Speaking of Pinball, I was feeling like I was getting nowhere with this thing, and I was clear that the most important and the most difficult things to fix are the CPU board and driver board, and the ones in my game were no exception.
Like I said, the driver board is really an extension of the CPU board and they can be treated pretty much as one unit. The driver board controls the solenoids, lamps and switches, and the CPU board with its 6802 microprocessor controls the rest of the game through a series of PIAs (Peripheral Interface Adapter). The PIAs have addresses like RAM or ROM chips do and the game ROMs access them to see what is currently happening in the game and what solenoids are firing etc and will do things like update the scores when targets are hit.
On System 3 games like mine there are four PIAs, one on the CPU board that controls the score displays and three on the driver board, two of which control the solenoids and the lamps and one that reads the switches. If a PIA fails and is not readable then the game will lock up and will not work. That’s another reason why the two boards can be treated as one, because the CPU board cannot "boot" without the driver board attached. Not normally anyway but there are special ROMs that you can use to test them separately.
One of the most common failures of these boards is the connector strip that joins them together, and it’s reported that they can fail after as few as twenty five cycles, that is, removing and reattaching the driver board twenty five times, so I checked all of the pins and pin joints and reflowed the solder on a few of them that appeared to have slightly dry or cracked solder joints so that I got as good a connection as possible. Then I could focus on the boards themselves.
The most obvious thing about my driver board was that there were some heat damaged areas and it had plainly been very hot at some point, and probably over a period of time, as there was the traditional blackening of the connectors for the G.I. circuit, so all of those transistors in that area, and in fact beyond would need testing.
Parts of the driver board are made up of pairs of transistors that drive the solenoids located around the playfield, the transistor pairs are made up of a TIP120 and what’s referred to as a pre-driver transistor, a 2N4401. The lamps are driven by a different transistor, a TIP42 paired with a pre-driver 2N6122, and it is possible to test them with a multi meter but it is not always 100% accurate.
If any of the TIP120s are found to be faulty, and some of mine were (in fact quite a lot of mine were) particularly in that heat damaged area, it’s best to replace them with a more modern TIP102 which does the same job but under much less stress and will tend to last longer.
All of these transistors are driven by a 7408 chip, and you can also test those chips because sometimes a transistor being tested in circuit can test as bad while it is good, which means that the relevant 7408 chip is bad, so it’s important to test each part of the circuit in the right order, and only move on when you are happy that the previous components are good.
One of the issues with Williams machines of this era in particular is simply the way these boards were designed and interacted with each other. The fact that some PIAs were on one board and some were on the other, meant that the 40 pin connector between the boards was not only carrying voltage data or blanking data, but it was carrying memory addressing data, and if that got interrupted, even momentarily, the game would lock up. If the game booted and one of the components such as the solenoid PIA is not in the precise mode that it should be then it does not just affect the solenoids controlled by the PIA, the whole game locks up. Not only that, but because the game doesn’t boot properly, the post boot Williams diagnostic LEDs are rendered useless for diagnosing the issue.
It’s possible to “semi boot” the CPU board without the driver board attached which should make the two CPU LEDs blink on and off before staying on, so if then installing the driver board and rebooting causes the LED to stay on then it’s quite likely that the CPU board is fine and there are problems on the driver board.
A good way to test these two boards is to use a test ROM, one of which is called Leon’s Test ROM, and what this ROM does is ignore any other ROMS that are connected and sends consistent and known signals to various parts of both boards (though it’s probably best to boot with just the CPU board initially and test it on it’s own before attaching the driver board as well). It’s also best to remove the fuses for the Solenoid circuit and the Lamp circuit located on the power supply board as the ROM also cycles those, and we don’t want to energise them at this stage. You should also remove the power going to the sound board as the PIA outputs could toggle the sounds too.
So with Leon's test ROM fitted and the CPU board booted and running, or at least the reset and clock sections of it, both LEDs on the CPU board should be blinking about once a second and the two score displays may also flash a “0” in sync with them. The ROM is now testing all the PIAs by putting them “high” and “low” repeatedly, and you can test this high and low signal on every input and output pin on the PIAs with either a test LED or a logic probe.
You can also make your own test LED by soldering a 150 ohm resistor to the flat side of an LED and a piece of wire with an alligator clip to the other side of the LED. Then you would normally attach the clip to a +5v supply and use the resistor lead as a test probe which will strobe the LED in unison according to the signal sent from Leon’s test ROM. Obviously you would need to check each output and input on each PIA to ensure that they are not faulty.
So, armed with my new logic probe and test LED I booted Leon’s Test ROM and went about testing the PIAs, not forgetting that some of the pins on the PIAs are data lines which would be pulsing and those have to be tested with the logic probe rather than with the test LED. Needless to say if any of the PIAs are faulty (you guessed it, some of mine were) replace them and put a socket on the board before fitting a new PIA 6821 chip to the socket. The problem with testing components like this in situ is that something else on the circuit could affect the results, so always bear in mind that it is possible for a PIA to test as bad when it is good and vice versa.
Leon's test ROM also alternates the Blanking signal on pin 37 of the CPU board’s inter connecting strip so you should test that too, because with the driver board connected, the flipper relay flipper should click in unison. If it doesn’t it could either be because it is just slow to energise or because the blanking signal is either missing or is too short in duration for the relay to energise. This isn’t really a problem with Leon’s ROM, but when the game boots normally with its own ROMs the blanking signal needs to be set to high. If the solenoids in the game will not fire it could be because the blanking signal is set to low, so what you can do as a quick and easy visual test for this is to solder a test LED permanently to pin 37 on the inter connect strip. If it lights when the game boots then the blanking signal is as it should be.
It is vital for the blanking signal to be high or the game will not boot because that is how the CPU board and the driver board do their interpretation of the POST (Power On Self Test) and tell each other that the ROMs and the PIAs are good, so once the CPU ROM program thinks everything is good it sets the blanking signal to high which allows the game to boot. Obviously if the signal does not go to high then none of the solenoids, bulbs (other than G.I.) or score displays will work. It’s annoying but it’s a failsafe to protect the sensitive parts of the game, so rather than have a wrongly booted CPU board locking solenoids on and blowing components, the game just doesn’t fully boot.
In short, if any of the PIAs are bad they can lock up the CPU when the game boots, so test them and change them, and if it still locks then the likelihood is that the problem is caused by either shorted transistors that drive the solenoids, blown 7408 chips that drive the transistors or again the PIAs that drive the 7408s. Most commonly the PIA that will die will be the one that controls the switch matrix or the solenoids. The lamp matrix PIA seems to be fairly resilient. Most of all, test components multiple times and ensure the results are consistent, and if they aren’t then look at the usual suspects, the 5101 RAM, the 6810 RAM and that inter connecting strip.
All this diagnostics and repair is fine and dandy assuming that you have the ability to hold a soldering iron still and solder well enough to replace I.C.s and sockets without burning a hole through either the board or yourself and I am just about able to do that, but with this project I found that I reached a point beyond which I couldn’t continue. I tested, I replaced, I tested again, I replaced again, and I got to a point where I had to admit defeat. I couldn’t get the damn thing to boot properly.
I knew beyond doubt that the Power Supply board was working as it tested perfectly on every point that required testing. The problem was the CPU Board and the driver board. I formed the opinion, based on test results, that the PIAs were good, that the 7408s were good, that the transistor pairs were good and that the interconnecting pins were good, but the damn thing just wouldn’t run as it was supposed to. I guess at that point you could say that I took the easy way out. I sent the boards away to be repaired. Now normally that would be a very expensive business, something like £100 minimum and an hourly rate after that, but I had a cunning plan, and more importantly I knew somebody who had a working System 3 machine and who was more than capable of testing and repairing my boards for me. It seemed only fair that I send them to him and allow him the chance to fix them because after all, it had been him that had talked me into buying the bloody thing in the first place, so the least he could do was help me to get it running.
The man with a plan was no other than my co-host on the RetroGaming RoundUp Podcast “Scott Schreiber”, and having done this before on his own machines, Scott was able to go about things slightly differently and use each of my boards on their own in his known working System 3 machine “Gorgar.” What Scott found was that I had made a reasonably decent attempt at repair, and one that had every chance of success were it not for the state of the boards themselves.
He found a couple of broken traces on the driver board, but more importantly he found that at some point, it was as though the board had been flexed, because it gave up very inconsistent results as though the traces themselves were damaged and would sometimes make a connection and sometimes not. Rather than chase errors around on this board he felt that it would be wiser and much less time and labour intensive to simply replace the board for an identical one that he had spare and that only had a minor issue and then to use my temperamental, flexed board for spares.
Now armed with a fixable board and a repaired board the repairs and the testing went much more smoothly and he was able to run both of my boards in his Gorgar machine. All that remained was for him to send them back to me and for me to replace them in my own machine and see if the game would boot now, or if there were further problems either on or under the playfield that would stop it from running.