I received from Portugal a couple of Space Invades DX PCBs, a game released in 1994 by Taito (more or less a port of the original Space Invaders, with a few new features).

Both boards were in very good condition but completely dead.Here’s the first one:

All I got on power up was a steady black screen.Probing the 68000 main CPU revealed the address/data busses were active but the three interrupts inputs (IPL0-IPL1-IPL2) were all in fixed high logical state.I traced these inputs back to a PALCE20V8 marked ‘D72-07’ :

Then I disassembled the fusemap of the MAME dump of this PAL being able to identify its inputs and outputs:

/** Inputs **/
Pin 1 = i0;
Pin 2 = i1;
Pin 3 = i2;
Pin 4 = i3;
Pin 5 = i4;
Pin 6 = i5;
Pin 7 = i6;
Pin 8 = i7;
Pin 9 = i8;
Pin 10 = i9;
Pin 11 = i10;
Pin 13 = i12;
Pin 14 = i13;

/** Outputs **/
Pin 15 = o15; /**(Combinatorial, No output feedback, Active low) **/
Pin 16 = o16; /**(Combinatorial, Output feedback output, Active low) **/
Pin 18 = o18; /**(Combinatorial, Output feedback output, Active low) **/
Pin 19 = o19; /**(Combinatorial, Output feedback output, Active low) **/
Pin 20 = o20; /**(Combinatorial, Output feedback output, Active low) **/
Pin 21 = o21; /**(Combinatorial, Output feedback output, Active low) **/
Pin 22 = o22; /**(Combinatorial, No output feedback, Active high) **/

Pin 20-21-22 were outputs to 68000 interrupts lines and they were confirmed to be stuck high along with all other outputs :

Although PAL was secured I tried to read it in my programmer, this would have at least told me the state of ‘health’ of the chip.Reading failed hence the chip was faulty:

I burned a GAL20V8 (GAL and PALCE are most of time interchangeable) with MAME fusemap :

Board booted up with no further issue.First board repaired.

 

The second board:

As said, it was completely dead.Probing the 68000 main CPU revealed the clock input was stuch high:

I traced it back to a 74F161 @IC51 which acts as a clock divider of the 32Mhz signal generated by the near oscillator :

There was nothing coming from the oscillator into the clock input (pin 2) of this 74F161 counter:

At first glance I thought the oscillator was dead but before replacing it I made a visual inspection on solder side.I found a dry joint on its output pin :

I promptly reflowed it and then powered up the board again.It booted up with no further issues.Double repair accomplished.

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.

 

 

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.