Heroes in a half-shell! With the impending release of the new Teenage Mutant Ninja Turtles film in Cinemas this September, we figured it’d be a perfect time to coax our friend Womble into sharing his circuit whispering with none other than Komani’s fine arcade bash of the same name. It’s all kinds of missing sprites and active pins as we delve into this PCB repair…
Had a TMNT PCB on the bench this weekend, It’d been found in the bottom of a TMNT cabinet bought some time ago that was running a Simpsons PCB.
The fault was described as it giving a white screen which flashed regularly, which is what the board was doing when I got it, but it wasn’t quite what I expected. The board would boot with a burst of a chugging (aka motorboating) noise from the speaker, give a white screen which would be stable for 5 seconds, it would then flash (PCB resetting), remain stable for another 5 seconds and then reset. Rinse and repeat ad nauseam.
Normally when you get a TMNT board doing this the flashes are very rapid, half a second apart with a regular ticking in the speaker. That is classic watchdog behavior of a board unable to even boot up, the watchdog timer expires during a period of inactivity on the buses, indicating the CPU has crashed, so the reset signal is sent to repeat the whole process over and over again. In this case, the long pause on this board meant it wasn’t crashing and was actually running the power on self test, reporting it had found a fault, then rebooting itself. The only issue was that it was doing it blind, where the test results should have been was only a white screen.
A quick eyeball of the board detected a few things, the factory-fitted bodge wire had been cut, this looks like an aftermarket bodge but every TMNT I have ever seen, except one, has this done to it. Its not completely clear from the schematics what this achives, potentially it allows an external reset switch to be fitted to an unused pin on the JAMMA edge connector.
The board had the usual physical damage to the 1000uF 16V decoupling/filter cap on the amplifiers 12v rail, this stands up so tall it is usually knocked over or torn off altogether. Even if it looks fine you usually fine one of the legs is torn off inside as it had been wrenched over. When straightened up the ripped off leg slides back inside and it looks fine, but they are usually ruined. Flexing the cap gave a popping noise from the amplifier output so it was clearly knackered as its connection internally was not stable.
Knowing the board was playing blind the first point of call was the palette Static RAMs (a pair of TMM2018 45nsec SRAMs )at PCB locations F23 and F24).
These contain the colour information for anything on screen, no data output from these, or the wrong data, can lead to complete white out.
Poking the scope at the data bus pins showed this…
…technically not “floating” and noisy enough that the logic probe detects activity (demonstrates why a scope is infinitely better than a logic probe for actually seeing what is going on) the pins are active, but it is putting out junk that doesn’t represent data at all.
The total white out is due to there being no data input into the colour logic, so the colour inputs are always high downstream, a trick to nudge the system is to inject junk data onto one of the data lines. Bridging D0 with the next door address line put rubbish into the system and the screen lit up.
The scraps of graphics all over the place is totally normal, all TMNTs do this as the RAM test routine seems to use gfx ROM data, on a working board the palette data should hide this.
So, F22 and F23 are flagged as bad, pretty much expected, however these tests cannot be taken literally, the “BAD” result really only means “I tried to write XX to RAM address location Y, but when I tried to read back from Y I didn’t get XX”, there’s a lot else that can go wrong aside from the RAM chips themselves, by far the most common on Konami boards of this era is the control logic or track damage.
A poke around the /CS (chip select) /OE (output enable) and /W (write enable) control pins that drive the SRAMs showed that the chips were in a valid state, ie /CS was low (chip active), /OE was low (outputs active on the bus) and /W was high (chip in read mode), therefore the output pin should have been active, or at least high or low. The control lines were all static which initially looked suspicious, so I did a quick backtrack up the control logic looking for any issues in the TTL but found nothing amiss, the 74LS157s that drive the address bus on the SRAMs were all active, the control line logic tracks back to a 74LS32 at H11, a 74LS04 at H18, and then onto a 74LS138 at H25 (all Fujitsus) but everything looked fine.
The only remaining candidate for the fault was the SRAM chips themselves, which based on the manufacturer (Motorola) and previous TMNT repairs would not have been where I would have guessed.
One trick that is common with logic faults is the piggybacking of known good chips onto suspect ones. This risks destroying the new chip if the old chip is faulty in certain ways, in this case the old chip’s outputs were effectively unhooked from the bus and the chip did not appear to the shorted, so piggybacking is a valid approach.
Piggybacking a NOS Toshiba TMM2018 on F22…
…got me this…
Adding another to do the same on F23…
gave a full bill of health…
…and the game started.
Hmmm, something not quite right here, no logo…
…and no character sprites.
Unsurprisingly, the sprite RAM is another MCM2018N45, at G8, which apparently passed the RAM/ROM tests according to the output. These quick tests are often very basic and in some cases may outright lie, in this case I doubt the board even tries to test this chip as its outputs were just as stuffed (i.e. completely) as the palette RAM pair.
Another chip from my stock piggybacked…
… and everything was restored.
To make it permanent the old chips were desoldered, and sockets with new chips installed.
Desoldering on Konami boards can be a pain, my desoldering station needs an overhaul an I could not get the holes to fully clear. As I had no doubt the original SRAM chips were dead I ended up cutting the legs off and removing them one by one, brutal but it saves the PCB the torture of constant heat cycling.
Final fixes to the reinstall bodge wire, and the amp capacitor
I also put the board through the full mask ROM tests and verified the 3P and 4P inputs were all working, a common fault is the death of some of the input multiplexor chips which take the player control inputs.
This board is a bit of a rarity in the fact that it didn’t have a single Fujitsu TTL fault, and a complete set of three dead Motorola 2018 SRAMs, usually its a tonne of bad logic and everything else is mostly OK.