PCB Repair Logs – Page 24

Truxton II repair log

PCB Repair Logs Comments Off

Aug 032018

Yet another Truxton II PCB (overseas release of Tatsuin Oh) on the bench and always from Portugal :

The board was stuck on boot on a colored striped static screen :

Main 68000 CPU was not running, both data/address bus were inactive.For first I checked the ‘GP9001’ custom GFX controller (QFP 208 pin ) which is a common issue on hardware that use it:

I found some lifted pins:

Reflowing them didn’t lead to any improvement.The board uses the ‘infamous’ custom ‘HK-1000’ custom (the early fragile ceramic revision) which handes inputs :

A closer inspection revealed the IC was damaged, some pins were broken at package insertion so beyond repair:

As said, the ‘HK-1000’ handles inputs but a faulty one can prevent the game to boot because some CPU address lines are used to generate the enable signals for it.I removed it:

Without the custom the board successfully booted up but obviously game was not playable due not working controls:

So I installed two strips of 2.54mm female machined pin headers in order to host a reproduction of mine:

The last issue I had to fix was some rustling background noise:

With the help of my audio probe I quickly figured out the sound was clean before reaching the 2.2K sound potentiometer :

I replaced it and this restored a clear sound.As ‘icing on the cake’ I removed an ugly hack to use a quartz instead of an oscillator and installed the proper part:

Yes, yet another Truxton II PCB fixed!

Tatsujin Oh repair log #2

PCB Repair Logs Comments Off

Jul 282018

Another board from the ‘portughese’ box : Tatsujin Oh, a great shoot ’em up released by Toaplan and known outside Japan as Truxton II.

Board was booting but sprites were mostly missing and other GFX glitches present too:

There was an obvious reason of this.The custom ASIC ‘GP9001’ (which is the graphics controller of the system) was damaged : some pins were missing, other bridged, two traces going to it were ripped too.

Here’s a close-up under a microscope:

Given the extent of the damage the only possible solution was the replacement of the ASIC which is a very delicate operation (not for everyone…) because of its package (208 pins in a QFP package with very fine pitch).For this purpose I’ve been sent by the owner a dead FixEight PCB as donor:

I removed the damaged part and cleaned the area preparing it for the trasplant:

The spare removed from the donor board :

After soldered it I took care of rebuilding the ripped traces using some AWG30 wire :

Testing was successful, board 100% fixed.

Metamorphic Force repair log

PCB Repair Logs Comments Off

Jul 252018

Received today from France this mint Metamorphic Force (Japan version)

I have been told by the owner that sound was missing.This was confirmed once powered the board up, it was mute:

The board uses the ‘infamous’ ‘054986A’ hybrid audio module which in this case showed sign of corrosion due to capacitors leakage:

Insted to try to repair it I decided, in agreement with owner, to use a reproduction of mine wich means a better reliability and lifespan:

I removed the old module and installed some 1.778mm female machined pin headers:

Lastly fitted the reproduction:

Sound was back loud and clear.End of today job.

The Simpsons double repair log

PCB Repair Logs Comments Off

Jul 242018

Received from Portugal a couple of faulty The Simpsons PCBs.The first one:

When powered the board up I experieced sprites issue, some parts were missing:

The MASK ROMs test reported three bad 8Mbit devices which store sprites data :

This was almost unlikely so further investigation was needed.All the sprites generation is accomplished by two ASICs : the ‘053246’ which generates addresses to the MASK ROMs and the ‘053247’ which reads their data.But, unlike other Konami PCBs with similar design, the data lines of the MASK ROMs are not directly tied to the ‘053247’ but some 74LS373 octal d-type latches are in the middle (two of them receive the whole 16-bits of each MASK ROM)

I opted for a ‘shotgun method and replaced all of them.The MASK ROMs check no longer complained and reported all devices as good:

Board completely fixed:

The second PCB:

The board was failing the POST reporting two bad devices @6G and 7G:

They are respectively the ROM and the RAM of the Z80 audio CPU circuit .

The 1Mbit ROM was socketed so I pulled it and found that one leg was missing:

I rebuilt the leg and dumped it in my programmer but I got inconsistent readings so I replaced the device.In this way the board booted into game but graphics were wrong.The sprites were missing as well as the backgrounds incomplete and with bad colors:

I ruled out the MASK ROMs by performing a check :

At this point there was not much to test, graphics generation is entirely accomplished by custom ASICs.There is one especially whose functions could be related to the issue :

The ‘053251’ is a priority encoder which takes on input different layers of graphics as well as some priority bits and outputs 11 bit of palette index plus two shadow bits (info taken from MAME source)

Probing the output pins with a scope revealed weak signals on most of them:

I removed the IC preparing then the area to accomodate the spare part:

I took it from a donor Premiere Soccer board:

This restored graphics.Board fully working again.

Toaplan (Vimana – Out Zone) double repair log

PCB Repair Logs Comments Off

Jul 222018

I’ve been sent from Portugal a box of faulty PCBs for repair with some Toaplan stuff inside like Vimana and Out Zone (both japanese revision)

Vimana :

Board was booting and played fine except for some little glitches on background:

Backgrounds data are stored in four 28 pin 1Mbit MASK ROMs:

Devices were dumped fine except the one @ROM3 which gave inconsistent readings.Loading the file into MAME emulator reproduced the issue exactly:

I replaced the faulty MASK rom with a 32 pin 1Mbit non-JEDEC EPROM (adding the missing sockets)

Board 100% fixed:

Out Zone :

Board booted but sprites were garbled :

Probing a row of RAMs revealed /CE pins on three of them (the two 6264 @13A-14A and the 6116 @16A) were receiving no signals :

At a closer inspection I found a burnt trace going under them:

I removed two of the three involved RAMs:

Tracing back the burnt trace I figured out it was a GROUND signal that should have been daisy-chained to the /CE lines (grounding also address lines A10-A9-A8 of the 6116) of the three RAMs enabling the chips.A couple of jumper wires did the job:

Older Entries Newer Entries