Pac-Man repair log #2

I recently asked on UKVAC if anyone had a Pac-Man PCB I could borrow in order to test the recreations of the two custom chips I made for the CPLD replacement device.
JonHughes replied and a few days later I had not one but two PCB’s to play around with.
One was pretty much stripped of parts but the other was complete and even had the TTL versions of the two customs.
I already have a JAMMA adapter for this that I made for my first Pac-Man repair so I was all ready to go.
Visual inspection revealed nothing to be concerned about so I went ahead and fired the game up.
I got nothing. The game was absolutely dead. I checked for activity on the CPU address and data bus but they were static.
Checking the clock pin also showed up no activity. Probing around the clock section suggested that the crystal had died so I went ahead and replaced it but this didn’t help.
There was a small build up of old flux around capacitor C4 so I went ahead and cleaned this up. The clock signal came back!

So now I had this my clock back and activity on the address and data bus lines but I still had a blank screen and it wasn’t making any noise. I also confirmed the board was not watchdogging.
Since the Z80 CPU is already socketed I decided to use the Fluke 9010 to check the ROMs/RAMs. Here is where a little problem came as the TTL custom replacement covers over the Z80 so I fitted a few header to the pins to raise it up enough to fit the Fluke pod.

With the Fluke connected I quickly verified the ROM’s and RAM’s were fine. It also verified that the connections between these chips and the Z80 were good.

Next step was to work backwards from the RGBS pins at the edge connector.
There was obviously no video output.
I found there was no activity coming out of the 74LS157 at 3A but some activity going in and to/from the connecting chips.

Checking the strobe pin (pin 15) of this chip I found the signal was stuck HIGH which basically means the chip was disabled.
Checking the 74LS00 at 4C showed I had activity on pin 12 but pin 13 was stuck HIGH. This being the /VBLANK it was clear that this was not correct.

The /VBLANK signal is given out by a 74LS74 chip at 5M.
Checking the signals on this chip I found the clock signal was stuck LOW.

This clock signal is 16V signal that is generated by a couple of 74LS161 4 bit binary counters.

According to my logic probes there was no activity on pins 11 and 12 of the 74LS161 at 2R (the one that generates the 16V and 8V signals) but seeing as though this chip was already in a socket and it tested good in my chip tester I didnt believe what the probe was telling me so I fired up the scope to take a look at those pins.

This is a good clear example of signal contention. You can see that the signal is trying to rise up but only getting to about half a volt. Knowing that the chip is actually good out of circuit confirms that there is another signal driving it low.
I found that pins 11 and 12 were shorted together.
I couldn’t see anything really wrong physically on the board where these two signals went so once again I opted to clean off the small bit of old flux I could see and once again this fixed my problem.
Although I’ve read about old flux causing issues I’ve never actually seen it myself until now so this has been a lesson learned for me.

Now I got this.

The game is actually running here but there is garbage on the screen. If I left it running all the sprites came on the screen and were complete.
Before moving on I decided to test out my CPLD implementation of the syncbus controller custom. This gave me the same output so was confident it was OK. Now I though I’d try out the VRAM addresser replacement too and I got this.

All fully working with sound too.
The actual cause of the earlier fault was created by me as I had bent 2 pins on the VRAM module during one of the many remove/replace cycles I had done. I since confirmed this works fine too.

That’s this board fully working and the two replacements confirmed working too.

Thanks to JonHughes for providing me with these boards.