Topic: Another Teenage Mutant Ninja Turtles Repair Log  (Read 6742 times)

Author Message

0 Members and 1 Guest are viewing this topic.

Offline Womble

  • Amiga 4000
  • ******
  • Posts: 1190
  • Kudos 33
  • Gender: Male
    • View Profile
    • Aussie Arcade
Another Teenage Mutant Ninja Turtles Repair Log
« on: December 28, 2011, 04:03:45 AM »
Picked up a faulty TMNT board a couple of months ago on eBay.



All it did when powered up was give a pulsing white screen and a clicking noise from the speakers.



This is the classic "stuck in watchdog" fault. Something is stopping the main CPU system from running the program and the watchdog system is noticing the lack of activity and is regularly kicking

the CPU to try to start it, over and over again.

The board was in good nick, a couple of the mask ROMs had already been replaced with EPROMs but it had been neatly done. These contain graphics data so would not stop the board from booting if they

were faulty or even completely missing.

The 1000uF electrolytic on the 12V rail had been bashed to one side, ripping one leg out internally.



Very common on Konami boards as they used very tall thin caps that are always get knocked about.

The most common cause of failures on Konami boards from the 90s is Fujitsu TTL chips, that seem to lose their internal connections to the legs. If its an output pin that is disconnected then you

either get a floating pin, or a stuck pin depending on what is upstream of the chip. If its an input pint that gets disconnected internally then the chip just does the wrong thing, and if its the

5V or ground pin that is lost then the chip does very odd things and is usually very sensitive to touch.

A quick scoot round the board with my logic probe found a single floating pin on the 74LS245 at E24.



The DIR pin was high with the board in this state so pin 9 was an input pin, this tracked back to the LS273 at E27...



... and the output pin there was floating.

So I fired up the de-soldering iron and took it and the mashed 1000uF cap off the board, and replaced them.





The effect of this seemed to be nothing, still a blank white screen, although the watchdog timer was no longer barking, and by going around the board with the scope there was a lot of activity

which suggested the board was now running.

While probing around I ended up at the pair of MSM2018 SRAM chips at F23 and F24, they looked active but the A15 address pins was very sensitive to touch. On touching it with the scope probe the

board rebooted and I got the first signs of life...



... at which point the board froze.

On a TMNT board this suggests the board is failing to get through the RAM/ROM tests at all before crashing, and as the first ones it tries are F22 and F23 I started there. Their outputs looked fine

on the scope, as did their inputs, so before taking them off I went for the piggy back approach.



This is by no means guaranteed to work as if both chips are able to strongly drive the outputs and if they are doing different things then they fight each other and the data is corrupted, but it

sometimes gives you useful clues, and it did for this board.





At which point the board froze again.

So I took the MSM2018s off the board and tested them, they both passed, which at this point was not what I was hoping for. To be certain they were not the issue I soldered the TMM2018 piggy backer

chips onto the board and the board gave a rather odd RAM ROM pass screen and fired up.







The screen was very washed out but they game was now running and I did have something to look at. The theme tune was a constantly repeating block of corruption, the sample sound effects were also

completely messed up but the game was now running. To get rid of the row I flipped the "attract mode dipswitch" to off but it had no effect, so I just turned the volume down.

The video shows the three main faults, no colour, mashed theme tune and mangled samples.

http://www.youtube.com/watch?v=32hXP_IIOsI&feature=youtu.be

As for why the RAM chips passed their test off the board but were causing issues on the board I can only assume it is a speed issue, the tester is probably not driving the chips as hard as the

board does, or it could be that they work fine solo, but not as a pair.

Now I had a virtually monochrome TMNT board to work with...





... I was still focusing on the SRAMs I had replaced as these are the palette SRAMs, and interrupting their address bus lines did cause flickers of colour to reappear.



So I went back to the address line that was so unstable before and traced it back to pin 12 on a Fujitsu 75ls157 chip at D15. The ICs on this board are so tightly packed that my logic comparator

cant clip around any ICs but I could just get a faint enough connection from above for it to say that pin 12 was not working properly. So out came the 157 and it went a tested on from a scrap

board, which brought back the colour...





... sort of anyway.

It now looked rather like an Amstrad CPC game, very 8 bit in style. Have seen this before and it is usually the 74ls07s...



...which are in the last stage of the video output, they buffer the stream of data that go to the 052535 Konami SIP packages that assemble the RGB signals before they go to the JAMMA connector. Now

the board was busy these chips had input signals, but a couple had no corresponding output activity on some pins. As there were only four of these I just replaced the lot.





Success!

Time to address the sound issues, I had met the corrupted theme tune issue before so I knew how that part of the board worked. The theme tune lives as a sample in the mask ROM at D5, this ROM's

address lines are controlled by three 74ls393 chips...



... which are arranged in a counter cascade fed by the small blue crystal nearby. When given a single activation signal these chips count through the entire address space of this ROM in binary

causing it to empty its entire contents straight into the digital analogue converter to be then sent to the amp chip as audio. Its a very simple system that takes no CPU time or infact has any

connection to the CPU, which is why the ROM at D5 cannot be checked by the RAM/ROM tests, it is on completely isolated buses.

All three of these 393s had jammed outputs so I replaced the lot. This didn't fix the problem though, the audio was now a fairly constant roar. The clock signal from the crystal was fine, the

activation signal was operating correctly and the counter cascade was counting. The only thing left in this subsystem was the mask ROM itself so I took it off the board...



... and tried to read it as its equivalent EPROM, a 27c400. The reader complained it had about a dozen bad pins so I fitted a socket and programmed a EPROM to replace it...



...which brought back the theme tune in full.

At this point I moved the board to one of my cabs for a play test, my test bench hasn't had the control/coin/start buttons wired up for ages now. The game would coin up and start, but I had no

"right" or "jump" controls, so back to the bench it went. I had suspected there would be issues as the player controls are read by the same pack of 74ls253 chips as the dip-switches, and the

attract mode audio dip was already faulty.



Replacing the A27, C25 and E26 brought back the lines I knew were bad, but as there were almost certainly other dips or controls that were missing on the other players I replaced them all.

The only remaining fault was the corrupted sample sound effects and voices, and this issue was somewhat inconsistent, sometimes the audio was fine, other times the sfx were bad again.

Looking at the schematics the speech is created by a NEC D7759 at D18, and the data for these effects live in the mask ROM at D18. Aside from a couple of 74LS273s (both Fujitsus) the system was

fairly simple, if you ignore all the triggers and control lines hitting it from elsewhere in the sound section. I went looking for any signs of missing signals, floating or stuck pins but found

nothing. The D7759s clock signal seemed to come and go which seemed wrong as the crystal is strung across two of its pins directly, but the clock signal did the same on a working TMNT so that

turned out to be a dead end. As did the mostly silent clock signals on the 273s, the main problem was that these sounds were only played for about ten seconds during each attract mode loop which

made tracking down the fault a bit slow. Having found nothing obviously wrong with the 273s, or the clocks I started to suspect the mask ROM itself. This is another mask ROM that has no direct

connection to the CPU so cannot be checked as part of the inbuilt tests. So I de-soldered it and put it in my 1Meg mask ROM adaptor.



This lets me move the A16 pin from the mask ROM to where it should be on a 27c1000 EPROM, and also move the 5v pin out a couple of legs to its EPROM position so I can read these masks as if they

were an EPROM as I doubt any readers would support these masks natively.



...and in this case the data dump came back as being a healthy sound ROM.

While it was off the board I powered it back up and was met by the same mangled samples, which meant that either the data wasn't getting to the D7759 or the D7759 itself was bad. Again it came down

to which was the more likely of the two and if you have a Fujitsu TTL as a contender it will always win. So the 74ls273 at B16...



...came off and tested as being pretty well knackered...



So a Hitachi replacement from a scrap board went in, along with the original mask ROM



and the fault was cured.

Board fixed, not quite the quick fix I was hoping for :)
Sic Transit Gloria Atari

Offline AndyRCM

  • >=))))º> GO FEED THE FISH! <º((((=<
  • Administrator
  • Amiga 4000
  • ******
  • Posts: 9646
  • Kudos 50
  • Gender: Male
  • Manic Jet Set Willy
    • View Profile
    • Retro Computer Museum
Re: Another Teenage Mutant Ninja Turtles Repair Log
« Reply #1 on: December 29, 2011, 11:41:19 PM »
Karl (billdooruk) will definitely love this one . . . his favourite game! ;)

Nice work as always mate. :) A
"I could see the faces of those who led pissing themselves laughing" - Funeral Pyre by The Jam