Recently I had two faulty Sunset Riders (by Konami) PCBs on the bench for repair.The first board came from Portugal:

Board was watchdogging in an endless loop, sign that no valid code was executing by main CPU:

 

Doing the usual check on CPU/RAM/ROM circuit revealed that a data line of a WORK RAM was stuck low:

Pin was almost shorted to ground:

This is shared with main CPU (pin 1, data line D4) and other devices too.Using a short locator I measured resistance to GROUND of all common points:

The lowest resistance was on pin 7 of a 74LS253 @14B:

The IC failed the out-of-circuit testing:

The board booted up but failed the POST showing a bad device @15B on an upside down screen:

The device concerned is the ER5911 serial EEPROM :

Someone previously replaced and socketed it but managed to rip the rivet of the pad of its pin 4 (which is the data bit output) which lost connection with the rest of board :

Once restored the connection I had to re-initialize the EEPROM:

After this the board successfully booted into game with no further issue.First board fixed.

 

 

The second board was in a lot of faulty PCBs I bought:

It booted up but jailbars were present all over the screen:

Lines are a clear sign that something is wrong with the graphics data (in this case the tilemap).I launched a MASK ROM check which found a bad device @16K:

I was about to replace the device when I gave a look on its soldeside and found a deep scratch :

Under a microscope two traces appeared to be severed, they were indeed two data lines of the MASK ROM (pin 13 ‘D0’ and pin 28 ‘D7’).A quick check with a multimeter in continuity confirmed it.

I restored connections with some AWG30 wire:

No more complain of MASK ROM check :

Board 100% fixed and double repair accomplished.

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.

 

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.