Jump to content
Due to a large amount of spamers, accounts will now have to be approved by the Admins so please be patient. ×
IGNORED

Turtles In Time Repair Log


Recommended Posts

This is a board I have had on my to-do pile for years and years.

 

NiktII8h.jpg

 

Despite many clear-outs over that time, where the to-do pile has been burnt to the ground, this board has always stayed coz

 

1) Rare

2) Expensive

3) Turtles!!

 

...and as I had let on to my Turtles-mad kids that there was another TMNT arcade game, and that I actually had it, it was time to get it back on the repair bench.

 

I don't really remember where I got it, but it came with brown packing tape wrapped around the mask ROM end which had the fault description written on it. It had had some work done on it before I got it, a couple of chips had been replaced and one of the 1000uF capacitors by the amp wasn't original. Although it initially looks pretty tatty most of it is mostly superficial.

 

The ROM labels are all torn up which is usually a sign it has been loose in a box of boards and the solder side of another board has scuffed up everything.

 

5a3ar1Ih.jpg

 

The mask ROMs are covered it tape residue.

 

tz1cMQth.jpg

 

Plus it comes free with the stumps of some old hard-wiring to the edge connector.

 

9cHGS07h.jpg

 

The main fault was that it wouldn't boot, it would get to the RAM/ROM test and just freeze.

 

aU1xPzzh.jpg

 

Except when it would, about 1 in 20 power ups it would get past the RAM/ROM tests and start playing normally. On the occasions it would boot it would then run for hours and hours without any issue, but give it a power cycle and it would instantly get stuck at the RAM/ROM test again.

 

I'd had a few pokes around with this board over the years but I had always made the same mistake, I had totally ignored the sound section of the board. On almost every PCB I have met, the sound system plays no part in the self test, it just sits there totally separately waiting for signals from the main CPU section of the board to do it's thing. So a fault in the audio system won't normally stop a board from passing self-tests and playing, just often without sound. As the board did run fine I probably hadn't even bothered to dump the EPROMs as I had assumed they were fine, or it wouldn't run for hours on the occasion it would boot. I certainly hadn't dumped the audio CPU ROM...

 

6FBpsoxh.jpg

 

...as surely it would be fine.

 

Nup! Totally shagged according to my EPROM burner.

 

fP0WH8s.png

 

With a 27c512 EPROM burned and in place...

 

hMafvLMh.jpg

 

... the board would progress and complain about 15B.

 

wIaQGWBh.jpg

 

Which is this puppy.

 

xuI3sDfh.jpg

 

Konami games of this era have a small 8 pin EEPROM on the board which holds game settings, if the board hasnt been used for ages, or if you have changed the main 4 EPROMs to change between 2 and 4 players then it will report this chip as bad, but really it just needs to be reinitialized, by holding down the test switch during power on.

 

7ih4cBgh.jpg

 

It will then wipe and reinitialise this chip, after which the board would pass all tests and run, every single time!

 

QG7JZ2Uh.jpg

 

Fixed, or is it?

 

izaWyl8h.jpg

 

The game mostly looks fine, except some elements are the wrong colour, the title screen for one, and some of the characters during attract mode look red hot...

 

...kicking turtle...

 

j18PCR0h.jpg

 

...dropping pizza turtle..

 

vACGXQsh.jpg

 

...Splinter...

 

R9YDpW5h.jpg

 

...and Krang was solid green, while stealing the Statue of Liberty, which was black.

 

lvyOJQZh.jpg

 

Also the Turtle's mouths were blocky where they should be animated.

 

Ohwnv7th.jpg

 

The obvious thing to do is to run the built-in mask ROM check, but that came back clean.

 

V7bjVlZh.jpg

 

At this point I was feeling lazy, so I just went ahead and did a bulk Fujitsu eviction in the 74LS07 buffer section that feeds data into the three colour DACs.

 

B99OyQ9h.jpg

 

There are 30 buffer gates (triangle symbols) chained across the 5 chips and faults here can cause weird colour issues. Have seen it many times on TMNT boards, plus removing Fujitsu TTLs is never a bad plan if you want the board to remain fault free for many more years.

 

IKOR9jzh.jpg

 

Some outputs looked manky on the scope and I could annoy the fault to a certain degree by poking around.

 

aKqvQMAh.jpg

 

NjwyJ8Nh.jpg

 

nZb3IJph.jpg

 

The result of this was nothing, no change at all.

 

This is where it gets tricky, going over the video stage I didn't find anything else suspicious, some schematics would be really helpful here, but the TMNT2 schematics only has about 5 pages, the full set for a board this complex would be closer to 20, the rest is missing. One of the pages they did include is actually the video output, which was helpful in working back into the system looking for clues. The trouble was I couldn't find any clues.

 

10errmF.png

 

Probably the biggest pain was that the fault was only really obvious in a few areas where the colours were clearly wrong, and they only showed up for a few seconds during attract mode cycle. A major tactic in board repair is finding out where you can annoy the fault, with the fault flashing by for about 10 seconds every 2 minutes it was slow going.

 

It would have helped if the turtles had all been hot pink, or missing, but they were just slightly the wrong shade of green and everything else looked kind of OK.

 

With nothing looking like it was misbehaving with the video system shown by the TMNT2 schematics and having worked back through it from right to left I needed to keep going upstream, but the last inputs (CO0 - CO10) that feed into the LS157 multiplexers come from a page that is missing. By manually buzzing them out I could find that were outputs from the 120 pin Konami 053251 custom chip...

 

hYsdTGGh.jpg

 

... and by shorting pin 11 to ground I could annoy the fault very specifically, leaving most of the screen unaffected, i.e. Splinter and Krang were drawn correctly, with only slight disturbances elsewhere on screen.

 

But as the outputs all looked fine I was faced with a couple of options, either the 053251 itself was bad or it was getting bad inputs from somewhere. As I don't have a board I want to scrap for a replacement 053251, and it would be a pain in the arse to replace it, I only really had the "bad inputs" option, and with a 120 pin chip the schematics for the pinout would be a massive help, but the TMNT2 doco didn't have that page.

 

There are a few other games that use similar hardware and in the TMNT2 family there are two other popular games whose schematics have made it out into the wild - The Simpsons, and Sunset riders, although again neither are the complete set.

 

The schematics for the Simpsons does have the video output stage shown, and it does go one step back further and actually shows the custom chip, giving the pinout and the signal labels, even though the inputs go off to a missing page.

 

F0DNcKV.png

 

Time to draw this out...

 

qUrSdNb.png

 

...why bother to do this?

 

Firstly it doesn't take long, secondly it is hard to work from the schematic back to the real chip which such tiny pins, where one slip with the probe could dump 5V into the chip destroying it, but thirdly it lets you see patterns in the pinout that aren't immediately obvious from how the schematic was drawn. Once you have the pattern to work from, spotting anything odd is often a lot easier.

 

So going round the blocks of pins I could buzz them out family by family, and quickly found a suspect. Pins 30 to 38 are CI0 to CI18, were all connected to the 053244 custom IC at 3J on the other side of the board...

 

QDyY3jjh.jpg

 

...all except one. Aside from the missing one everything lined up on both customs but there was a gap where CI15 (pin 35) would fit.

 

URHzhXq.png

 

There is no guarantee that the pinout on the 053244 would be entirely logical (I can't find a schematic showing that chip in use), but CI15 didn't connect to anywhere else on the custom IC and as it was in the middle of a logical grouping of signals it didn't make sense for it to be left out...

 

....and I up am up against the image limit per post, (also can't reply to my own post right away) so part 2 will have to wait a bit.

Link to comment
Share on other sites

Cheers Frank - the 40 image limit bites me from time to time.

 

Anyway - Part 2

 

As the unconnected pin wasn't tied to 5V (so not going to smoke the 053244 if it was joined), and I had no schematics to verify whether they should be connected, the only thing to do was to connect them together with a run of hookup wire and see what happened.

 

7n8buPuh.jpg

 

bPjP3Y4h.jpg

 

FC5C2duh.jpg

 

Bingo! Clearly the track between these two pins has let go somewhere in its path across the board.

 

QcYkfTch.jpg

 

Kicking Turtle is green again...

 

lf3GRfqh.jpg

 

... the pizza dropper is back...

 

fIU5y7lh.jpg

 

...and Splinter isn't burning up.

 

mZvUgNHh.jpg

 

Krang and the Statue of Liberty are now in glorious Technicolor...

 

UEKY7drh.jpg

 

...and the animation blocks are gone.

 

X2UaCpIh.jpg

 

All good, except for that long loop of wire flapping about, guaranteed to get caught on something and will probably rip a custom chip off if it does. Time to hide it, and my usual method is to route it under chips and between legs to keep it well out of the way.

 

IPdLq82h.jpg

 

One of the chips that had been replaced before (the 74LS245 at 8J) was right in the path I needed, and the chip they had used didn't have enough clearance underneath to run the hookup wire, so I ended up replacing it with one that matched its partner at 8K. Otherwise I'd be left with another loop to get caught on things, some people use hot glue to stick wire links down but I prefer to just knit them into the board.

 

X23grUxh.jpg

 

With enough clearance under that chip the wire link can run straight as an arrow up under the sprite customs, loop round the legs of the sprite SRAM chip at 1J and end up right at pin 115 on the 053244 custom chip.

 

umHIqhah.jpg

 

With that squared away all that remained was to converted it to the two 2 player version to match my cabinet, by burning four 27c010 EPROMs for the main code (yep - need to find some proper stickers in my stash)...

 

2YGur8Lh.jpg

 

...and to make it pretty again by getting the silver texter and the old tape gunk off. The Mask ROMs at 3K and 3L are a bit chewed up on their surface from their time in someone's junk bin but all in all it cleaned up pretty well.

 

amDddJbh.jpg

 

Job done!

 

QcYkfTch.jpg

Edited by Womble
Link to comment
Share on other sites

The actual fix seemed really simple, I guess the hard part is diagnosing the fault.

 

Basically, you:

 

- Reprogrammed 1 x audio chip.

- Reinitialised 1 x chip via a factory power on/test button cycle .

- Tied 1 x pin high that wasn't properly connected to where it should be. Why was it not connected, bad trace?

 

I'm curious as to how it was able to run with these faults every so often?

Link to comment
Share on other sites

Kinda - the track I ran between the customs was to bridge a broken data track, it's not being tied high. I guess a track has given way somewhere between the two, probably a via actually. There was a suspect looking one under the LS245 I replaced, possibly its that one but it wouldn't buzz through in either direction.

 

As to how it ran when it did manage it, I can only assume the ROM did work sometimes, or the fault is right on the threshold of something. As long as the board was able to get through the self test it seemed happy to run, with the colour fault anyway. The EPROM is totally unreadable according to my burner even if I tell it to ignore errors, it just spits out a 64KB file full of 0101010101010101010101010101010.

 

What's odd is the board is able to test that ROM and can report if it is bad, so why it was able to wedge the board I dunno.

 

The actual fix seemed really simple, I guess the hard part is diagnosing the fault.

 

Almost all repairs are, you just need to find what simple fix is required. :)

Edited by Womble
Link to comment
Share on other sites

"A major tactic in board repair is finding out where you can annoy the fault"

 

do you do this by shorting pins to ground?

 

It can be anything really, from physically tapping the board, to heating or cooling the component, or interfering with the signals, even touching the pcb can annoy some faults where a pin is floating. Shorting something to ground is one way, but you have to be careful not to short anything that is directly connected to the 5v or 12v rail to ground. If you do then you create a dead short and unleash the fury of the PSU into the loop you have created, the weakest part will then nominate itself as the fuse and vaporize. I tend to prefer shorting an active data line to ground, or two active data lines together. This corrupts the data and will crash the board if you are poking in the CPUs subsystem, but if you are in the gfx system it will impact something on screen. I use the scope probe to suss out the area looking for clues, then often will use the probe tip to bridge things and see what happens, but only when I know what I am shorting.

Link to comment
Share on other sites

It can be anything really, from physically tapping the board, to heating or cooling the component, or interfering with the signals, even touching the pcb can annoy some faults where a pin is floating. Shorting something to ground is one way, but you have to be careful not to short anything that is directly connected to the 5v or 12v rail to ground. If you do then you create a dead short and unleash the fury of the PSU into the loop you have created, the weakest part will then nominate itself as the fuse and vaporize. I tend to prefer shorting an active data line to ground, or two active data lines together. This corrupts the data and will crash the board if you are poking in the CPUs subsystem, but if you are in the gfx system it will impact something on screen. I use the scope probe to suss out the area looking for clues, then often will use the probe tip to bridge things and see what happens, but only when I know what I am shorting.
Cool. And I take it your using the datasheets of the chips to determine which pin is a data line yeah?

 

Sent from my SM-G6100 using Tapatalk

Link to comment
Share on other sites

Not usually no, I probably shouldn't call them data pins, what I meant was I/O pins, not connected directly to 5v or to the ground rails, although grounded pins are usually pretty safe, as long as you don't short them to 5v, then you will blow something on the board.

 

Datasheets aren't available for any custom chips as they were never sold outside the company that made them, hence the need to find a schematic that showed the 053251 in use so I could checkout what the pins were labelled as, you can usually get some clue from the pin names.

 

Basically pins on chips breakdown like this.

 

Vcc - 5v - connected directly to the PSU 5v - Danger lives on these pins as the PSU will dump upto 10Amps into any short for as long as the PCB, chip, track or component can take it, which will be milliseconds before it smokes.

Vss - GND - connected directly to the PSU ground.

Control pins - pins that set the chip to do something, or disable it when held either high or low, most TTL chips have control lines that are marked with slash, or a bar above them on any datasheet that denotes "active low", so the chip is disabled when that pin is held high. These are often hardwired to PCB ground if the board needs that logic element to always be active. Some control pins will be tied to 5V such as the second chip select on a 6264 SRAM which uses an "active high" input.

I/O Pins - pins that are driven (input) , or drive lines (output) high or low, or both, these may be very busy, or may only switch once in a blue moon.

 

Any pin that is sat at logic high level is dangerous, it may be held there as it is tied to the PSU (most dangerous), or held high via a pull up resistor (to limit current), or just because the ouput is logic high. The only way to tell is to find the datasheet if there is one, or to disconnect the PCB and measure the resistance to the 5V input on the JAMMA edge. If the resistance is very low then that pin is directly wired to the 5V, some chips can take this on their control lines but only because they were designed to internally. I wouldn't ever assume a custom chip is built with current limiting resistors on its input, mainly because you only get one chance, once that chip is smoked it's smoked and you need a donor board to find an unsmoked on.

 

Basically it’s very dangerous to do it blindly, you will create more faults than you find, and possibly wreck the board,but... when and where you know it is safe to do it it can be very useful.

Edited by Womble
Link to comment
Share on other sites

I really love repair and restoration threads.

 

Amazing work! That game was definitely worth the time and effort in saving.

 

I am a huge TMNT fan too. Im 34 and over the last couple years found all my old turtles toys from growing up, which were scattered at my parents place in their attic. Since that time I've been buying parts for my figures and vehicles etc to complete them and have them all on display at my place now in the game room. Ill have to update my games room thread with some pics.

 

I really got to get into gear and look into TMNT/TMNT2 for my arcade machine, but was thinking a Raspberry Pi to JAMMA maybe

 

Anyway, thanks again for sharing

Link to comment
Share on other sites

Great thread, love the methodical and clean repair, also like the use of excel to map out the custom chip! I could with doing that on a neo-geo board.

 

What gadget/software was you using to check the EPROM? i'd be interested to see more on that side of things.

Link to comment
Share on other sites

  • 2 weeks later...
Great thread, love the methodical and clean repair, also like the use of excel to map out the custom chip! I could with doing that on a neo-geo board.

 

What gadget/software was you using to check the EPROM? i'd be interested to see more on that side of things.

 

Thanks!!

 

It's an old Wellon VP-280 eeprom reader/burner. Useful bit of kit, the 280 is long discontinued, but the health check function is pretty much standard on all USB burners. I also have a Data I/O 29B and Unipak 2 for the really really weird stuff I meet from time to time, but that's a massive pain in the rear as it is huge, noisy and needs a DOS PC to drive it with any ease.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...