Repair Logs – Page 36 – JAMMArcade.net

Dragon Breed repair log

PCB Repair Logs Comments Off

Jan 052018

Received today from Germany some faulty PCBs for repair, there was this Dragon Breed boardset (on Irem M72 hardware)

Sprites were glitched with jailbars thru them:

Sprites data are stored in four 28 pin 1Mbit MASK ROMs (Toshiba TC531000) located on top board:

Due the fragile nature of these devices I was pretty sure that there was a faulty one but I was wrong since dumps turned out to be good.Analysing them with a logic probe I noticed that data line D0 (pin 11) of the MASK ROM @IC49 was stuck low, measuring its resistance to GND gave me only few Ohms:

Since device was good there was clearly something forcing the pin low, most likely a short (not ‘dead’ though).I traced the involved pin back until I came across to this scenario:

Here’s a close-up under a microscope:

The capacitor @C62 was bended and its terminal connected to GROUND was accidentally lented on the pad of the trace tied to the data line.I straightened the capacitor, this cleared the short and hence sprites issue, simple but effective!Job done.

Rolling Thunder repair log #3

PCB Repair Logs Comments Off

Dec 242017

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.

Dogyuun repair log #1

PCB Repair Logs Comments Off

Dec 192017

Got from Portugal this almost mint but not working Dogyuun PCB, a shoot ’em up released by Toaplan in 1992:

On power up, after the system got initialized, board sat on a black screen.Main 68000 CPU was halted at this point,no sign of activity on all busses and control lines:

Usually this happens when a device (most of times RAMs) in the CPU address space doesn’t answer to initial check.So I went to probe RAMs and found that the two Mitsubishi M5M5178 @U46-U47 (8k x 8bit static RAM compatible with 6264) had /OE and /WE lines stuck (they are addessed by one of the GP9001 ASIC so the are VIDEO RAMs)

When I went to piggyback the one @U47 the board successfully booted and entered in game:

The chip obvioulsy failed the out-of-circuit test:

The game was fully playable but while testing I noticed some of the player 2 inputs didn’t work, in particular LEFT RIGHT, BUTTON 1 and 2 were responding at same time when one of them was activated.This can be clearly seen in the input check of TEST mode:

Checking with a logic probe the relevant pins of the JAMMA edge connector revealed that they were floating when usually they must stay in HIGH state when not activated (and then LOW when input is activated).Pull-up resitors or resistors array are used most of times to keep the inputs in HIGH state.When I went to check with a multimeter the 4.7K array @RM7 I found no reading from pin 5 onwards :

So it was most likely internally cracked.Indeed, once removed, it fell off in two parts:

Fitting a good one cured the issue.Board 100% fixed.

TH Strikes Back repair log

PCB Repair Logs Comments Off

Dec 102017

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 :