Received from Spain this faulty Vulcan Venture PCB (export release of Gradius II on the glorious’ Konami Twin16 hardware) 

This is what I got once powered it up:

Graphics were all corrupted, you could barely recognize the self-test procedure which failed all the time causing the reset of the whole system in an endless loop.I focused my troubleshooting on VIDEO board:

Like the CPU board, also the VIDEO one was almost fully populated with Fujitsu TTLs  but before going thru them I started to probe the various RAMs.I found one 62256 @8L with dead outputs:

This finding lead to no improvement.So I fired up my logic comparators and started to probe TTLs.Sequentially I was able to locate these faulty ones, all of them on VIDEO board and from Fuitsu:

• 74LS153 @9H

 

• 74LS157 @2F

 

• 74LS244 @5W

But the board was still not booting :

Shorting some data/address lines of two 6264 SRAMs @3A and 3B changed the garbage on screen so this was the path to follow, the problem was in the tilemap generation circuit which these RAMs are part of :

Probing the RAMs revealed that the R/W lines (pin 27) of both were stuck high, according to schematics these signals come from a 74LS27 @4B:

 

My HP10529A logic comparator confirmed troubles on two outputs of this 74LS27 which failed when tested out-of-circuit:

Now board succesfully passed the self-test and entered in game fully playable with sound but all graphics had very noticeale jailbars:

Most of graphics data is stored in four 4Mbit MASK ROMs:

While dumping them my programmer reported troubles for the ones @10L and 10M:

 

Replaced them with two 27C400 EPROMs fixed the issue and board completely.

Evil Konami (and Fujitsu) defeated again but war is not over.See you to next battle…

Received from Spain this faulty Rolling Thunder PCB for repair:

Board was not booting stuck on a static garbabe screen with some background sound noise (which seems a common issue on this PCB)

After ruled out all the custom ICs, few was left to test.The background sound noise very likely  suggested a problem in the digital sound circuit that on this hardware must be working for proper operation of the whole system.Probing this circuit with a logic comparator revealed nothing abnormal until I tested a 74LS257 @7C, I was warned about a problem on its output pin 12:

 

Also comparing with a scope this ouput with the one of the reference IC gave discrepancies, signal was not properly toggling (good on left of the below picture)

Looking at schematics pin 12 of this 74LS257 outputs the address line ‘A0′ to a 6264 static RAM @3F tied to the custom ’30’ which controls the sound system:

Sure enough I removed the TTL which failed the out-of-circuit exactly in pin 12:

After replaced the TTL the board successfully booted, no further issue were found so 100% fixed.

 

Received from Uruguay this ‘TH Strikes Back’ PCB (a.k.a. Thunder Hoop 2 by the spanish Gaelco)

Board played with all the graphics scrambled and messed up:

Doing a visual inspection I found a severed trace on solder side:

Patching it restored graphics but playing the game I noticed that the sound samples were all wrong and played randomly:

Samples are generated by the usual OKI MSM6295 PCM chip, given the high rate of its failure I went straight to replace it:

This gave me correct sound.But while testing the board, it suddenly committed suicide:

Like many other Gaelco boards this PCB uses for protection a Dallas DS5002 MCU which executes code stored in battery backed-up SRAM.When the contents of the SRAM get lost due a low battery or other problem the board will no longer boot showing on boot the “COPROCESSOR NOT READY” or “COPROCESSOR BAD” error:

Thanks to the work of MAME devs (Peter Wilhelmsen and Morten Shearman Kirkegaard) who dumps the contents of the SRAM now we can revive most of the Gaelco boards.The usual procedure to do it is well known and can be found on the net but it won’t work for some games that use a special register like Thunder Hoop 2.I was warned of this by Peter Wilhelmsen himself, he explained me how to properly desuicide this board (I will cover this topic in a proper post).I did it and board booted again but freezed everytime I started a game:

This issue had nothing to do with the Dallas DS5002 MCU, board was properly desuicided so I started to look elsewhere.Using a logic comparator in 68000 main CPU area I found a 74LS373 @D16 (involved WORK RAMs addressing) with a stuck LOW output (PIN 6).Measuring resistance to ground of this pin gave me only 10.9 Ohm sign that internal junction was almost shorted :

Once removed the TTL it failed the out-of-circuit testing in that exact pin:

Fitted a good TTL fixed the board definitively.Thanks again to Peter Wilhelmsen for his precious help.