Would you ever guess this is my favorite PCB to work on?
Had Arcade-Inferno's TMNT PCB on the bench this week. It was said to be working but had vertical lines across the screen so came south for some TLC.
A quick eyeball showed a couple of issues, the 1000uF 16v capacitor for the 12v rail feeding the amp was ripped off the board leaving just the leg stumps. These caps are usually knackered even if they are still there as they stick up so high they get knocked or wrenched to one side.
There was also a spot of corrosion on the tracks near the mask ROMs H27 and K27.
The board booted up, made an loud angry buzzing noise for 3 seconds, passed the self tests...
...and progressed to the game.
Yup - jail bars!
I flipped dip-switch 3, bank 3 to put the board into self test and rebooted. After a long think it came back flagging the H27 mask ROM as bad, which I promptly forgot to photograph. As this ROM is right by the corrosion spot I was fairly confident that this would be the fault, but with the multimeter set to continuity mode I could prove that pin 28, which was the most affected by the track corrosion, was still connected to everything it should be connected to, as were the other pins served by the other tracks that looked suspect.
A usual suspect for lines through sprites or graphics on Konami boards are the mask ROMs themselves, these chips are not ROMs that are programmed but are ROMs that are manufactured with the data structure built in. They are etched, as all ICs are, using light masks to expose certain sections of the silicon, while masking others off - hence the name. They are possibly sensitive to static and as they are mounted on the board edges they are likely to get zapped by static laden fingers, on other Konami PCBs that have mask ROMs on the edge as well as more towards the middle of the board, it always seems to be ones at the edge that die, potentially they are getting zapped.
If an address bus pin is damaged the data they output is always the wrong section of the data, and if a data bus pin is damaged you get missing bits in the bytes being sent out, which causes lines to appear in the graphic. People usually assume that when talking about 0s and 1s representing data that a zero is the default state, and a one is generated as required, when in fact it is the other way round. A ROM when completely blank contains all ones, and data and address lines are at logic high (ie 1) when resting. The zeros are slotted in by pulling the bits to ground, ie logic low. The white lines across the screen suggested that the offending bit was always set to one and was not able to be pulled low.
A quick scoot around the mask ROMs H27 and K27 with the scope showed there were no data pins that were tied high, or floating, so the mask ROMs looked like they were still ok.
Pressing hard on the 120 pin surface mount custom chips didn't have any effect either, this can annoy faults due to bad joints upstream of the custom chips, but it isn't guaranteed. If you have 119 legs firmly soldered in place and one loose the chip is so firmly attached that the bad leg doesn't move. Also if it has been loose for a long time oxide will have formed on the pad and the underside of the pin further reducing the likely hood of a good contact being made.
So I ran a plastic pin gently along the feet of the chip and the fault vanished as soon as pressure was applied to pin 26. The fault would stay clear for a while then would suddenly reappear. This behaviour can be due to the connection failing after a while, or because the data is held in RAM upstream while it is in use. If the data gets out of the chip while the leg is making good contact then the RAM buffer holds good data without the erroneous bit set to 1 that causes the lines. The leg contact may fail as soon as pressure is removed but the fault only reappears once the RAM is flushed and the ROMs are accessed again as the board cycles through attract mode and needs to re-use the RAM space.
This is next to impossible to see with the naked eye, even catching a shot of it is hard, I have about a dozen photos of this chip and only on this one has the flash caught at just the right angle to see that pin 26 has cracked free from the board underneath it.
Some flux and micro soldering of the affected pin (and its any neighbours and other suspect legs) cured the fault entirely.
The photo looks a bit messy, its a combination of the extreme shine of the new solder and the fact I hadn't cleaned the flux off yet.
The noise on first power up is the amp chip "motorboating", due to the missing smoothing capacitor on the 12V rail. This is there to ensure the 12v supply is smooth and free from interference. Without it the amp briefly oscillates as the 12v rail sags and recovers from the inrush current drawn by the stone cold amp waking up.
Fitting a 1000uF 25v capacitor from a road kill TV cured the issue, and will protect the amp chip from RF that can cause them to oscilate permanently while they cook themselves to death.
I also scraped back the corrosion on the tracks to bare copper and put a drop or laquer on the area to prevent further rot from taking hold.
Another common fault on TMNTs are the 74LS253 multiplexor chips that detect the control inputs (and dip-switch settings) and provide the data stream relating to control input activity for all players so I quickly tested those too. As with all arcade boards (well probably all, all I have ever met), the default state for any control line is logic high, ie a 1. When a switch is pressed, or a joystick directional switch is closed, this line is connected to ground (with a resistor in path to prevent a direct short on the power supply). The 3P and 4P input connector are as follows, and have all the inputs for the players (including coin and service) as well as system ground.
1 COIN SWITCH
3 P3 LEFT
4 P3 RIGHT
5 P3 UP
6 P3 DOWN
7 P3 JUMP
8 P3 ATTACK
11 P3 SERVICE
With the board set to test mode you can progress through to the input testing section.
I have a length of wire with a spike probe on either end for tests like this. With one probe on the GND you can connect each pin to ground in turn, if the test program notices the state change on all inputs (i.e. left, right, jump etc etc) then the multiplexor logic is working fine. In this case all inputs were working happily.
An interesting (well to me anyway) side note, this is probably one of the earlier TMNT boards, as it has one of the old style ceramic capped TTL chips...
...and also the factory mod bodge wire (that I assume was to fit an external reset button) that seems to be fitted to almost all TMNTs I find isn't present.
The capacitor at this location is usually replaced with a diode and a wire link to an unused edge connector pin.
Anyway - board fixed!