Capcom Trojan PCB repair Log

 PCB Repair Logs, Repair Logs  Comments Off on Capcom Trojan PCB repair Log
Jul 212019
 

I got this board a few years ago when I got a Pac-Man cabaret cab that had been converted to Trojan.

The whole cab was sold to me as not working so I assumed the board wasn’t booting either I converted the cab back to pacman and put this board aside until this year

So I fired up the board and it booted up just fine. However there was absolutely no sound coming out.

One of the issues with this board is that there aren’t any schematics available for it.
Luckily the sound section is almost identical to Ghost n Goblins.
Since the traces are visible on the board, I drew them for help on the back of the board.
Crude but it helped figure out things a bit.

It’s got that same sound module (85H001) to drive two YM2203 (3 channel sound chip)
The signal is then fed to a YM3014 DAC, and LM324 Op-Amp and a final HA13001 power amplifier.

Probing the YM2203, YM3014 , LM324 I can see signal coming out of all these and into the input of the power amplifier .

 

However there’s nothing coming out of the HA13001 so I’m assuming this is the culprit here.
Removing it, half the legs broke off . No wonder it wasn’t working

I fitted a new one and the sound came back right away and I was able to enjoy a quick game of Trojan

A quick and easy one but you need these every now and then

And as usual, for those who prefer the video format:

Tatsujin Oh repair log #3

 PCB Repair Logs  Comments Off on Tatsujin Oh repair log #3
Jul 122019
 

Got in the mail today this Tatsujin Oh PCB (japanese release of Truxton II), a great vertical shoot ’em up released by Toaplan in 1992 :

The board was bought on eBay and according to the seller it didn’t accept credits.But actually, when I powered it up, it booted to a ‘TILT’ message screen and then kept resetting in an endless loop:

I have experienced this issue many times and the culprit was always him,  the “infamous” ‘HK-1000’ :

This custom IC handles all the inputs including SERVICE, TEST and TILT and it’s a very prone to failure part, especially the first ceramic revision (like the one present on this board) cracks very easily or goes internally bad.As you may know, I have done a reproduction of this custom IC so I installed a unit after removed the original part and put some round machine pin headers :

Board booted now into game and correctly played but audio was loud, especially explosions and other sound FXs :

As you can see in above video I could not even adjust the volume by acting on the 1K potentiometer :

So I removed it:

It was broken as it fell off in pieces :

I installed a good one:

Sound was fully restored, board 100% fixed.End of today job.

 

 

 Posted by at 3:55 pm

Out Zone repair log #8

 PCB Repair Logs  Comments Off on Out Zone repair log #8
Jul 112019
 

Received some days ago an Out Zone PCB for repair :

Board was marked as faulty with player 2 stuck in down direction and so it was when I powered it up:

Probing the P2 DOWN pin (19 solder side) on the JAMMA connector revealed it was floating as if it was not pulled-up :

Checking the relevant pin of the 4.7KOhm resistor array (which acts as pull-up) gave me a value of 3.8KOhm, there was something pulling it low:

The signal from the resistor array goes then to pin 4 of a 74LS240 @15M whose resistance to GROUND was only 2.2KOhm:

I removed the IC :

Although the chip was tested good out-of-circuit I replaced it :

This fixed the issue with player 2 but the board suddenly died while I was testing it giving me a solid black screen on power up.From the top of my experience with this hardware I know that the audio circuit must be running otherwise the board will not boot.When I checked the Z80 audio CPU I found the clock input stuck low :

The clock is derived from a 28MHz oscillator:

The scope confirmed there was no periodic signal from its output, ther oscillator was dead:

I pulled it out :

Fitted a spare:

Board booted up again with no further issues.Repair accomplished.

 Posted by at 9:51 am

ESP Ra.De. repair log #2

 PCB Repair Logs  Comments Off on ESP Ra.De. repair log #2
Jul 052019
 

Received an ESP Ra.De. board for repair for my friend Vic.

This was the video I was sent originally

This PCB had apparently had work done before but all we knew was the big 240 pin custom chip had been reflowed. This always makes me nervous because if it was destroyed somehow then all further attempts of repair would be for nothing unless I had a donor.
Visual check carried out of the board in general revealed nothing bad so hooked it up to the test. As expected we have no sync and the game does not appear to be running either. I confirmed this as the watchdog was kicking in.
Using the scope I probed the sync pin at the JAMMA connector and found a low sync signal of 13khz.
I started tracing the signal back but it went to the big custom chip that I already knew had been worked on, I also confirmed the main clocks and signal to the custom chip.
With no other ideas at this point I decided to tackle the game booting issue. The 68000 CPU was already in a socket so using the Fluke 9010 with a 68000 POD (Thanks Caius for the extended loan of his POD) I could start troubleshooting.
First off a BUS check revealed data bit 2 was tied low. In actual fact data bits 2 and 3 were shorted together.

I started tracing all the point where these data lines go and one by one started isolating them from the circuit. Once again my search led back to this big custom chip.
Reflowing these two pins on the custom cleared the fault.

At this point I took a closer look at this custom and found if I got the light in at the right angle I could see a lot of dried flux underneath.
Over time flux residue will dry out if not properly cleaned and it can go conductive.
I cleaned this and the bus test now passes. The ROM check between 0x0 – 0x7FFFF should be 1BBA which also passed.

The main RAM lies at location U39 & U40, 0x100000, 0x10FFFF. The Fluke reported a decode error on bit 1 which basically means there is a problem with the address lines.
Doing some manual reads and writes I could see that bit 1 of RAM U39 did not work. I replaced this and retested which then went OK.

I started my way through the rest of the RAM location as per the MAME driver.
The sprite RAM lies at U43 & U44, 0x400000, 0x40FFFF. Once again the fluke reported bits 5 & 6 tied together and once again I was led back to the same custom chip.
From here I just opted to reflow the whole chip. This cleared the issue with the sprite RAM. All other VRAM passed tests.
Retesting the PCB now resulted in a nice looking game for the most part but there was a strange strobing around test and lines that were white. Going into the test mode made this very obvious.
I couldn’t get a good video of this as it all looked fine on a camera.

To began with I thought this was all to do with my test monitor and the sync being a tiny bit high for it but I tested it on all my monitors and cabs and they all gave strange results.
I eventually went back to that custom chip and inspected all the pins again.
I couldn’t visually see anything but checking continuity on all pins against the adjacent pins revealed a short somewhere around pin 190. A further reflow of these pins resulted in a completed repair

One strange thing about this board is that on boot up it stays in a reset state for around 2 seconds which is the point where the sync reads 13khz. After that the sync steps up to 15.23khz and all OK.

Here is a layout of all the RAM locations on the PCB

 Posted by at 4:38 pm

Parodius DA! repair log #2

 PCB Repair Logs  Comments Off on Parodius DA! repair log #2
Jul 042019
 

Received a Parodius DA! PCB for repair, a shoot’em up and second title in the Parodius Series produced by Konami :

Board booted up and game was fully playable with sound but sprites were wrong:

First of all I launched a MASK ROM check which reported two bad devices @K2 and K8 :

They are, indeed, 4Mbit MASK ROMs that store sprite data processed then by the near ‘053244’ and ‘053245’ custom ASICs :

The result of the check didn’t imply the devices were really bad but also that they could be not reached.So I went to probe them and found that pin 1 of the MASK ROM @K2 was floating while same pin of the one @K8 was active :

Pin 1 is the highest address line of the MASK ROM and should be in common between the two devices whereas, at quick check with a multimeter, it was not.Hence the trace to pin 1 of device @K2 was interrupted somewhere.I added a jumper wire on solder side:

This did the trick, sprites were restored and board 100% working again.Repair accomplished.

 Posted by at 6:47 pm