Some days ago I had on the bench this Wolf Fang: Kuhga 2001 PCB (known outside Japan as “Rohga – Armor Force”) , a good-looking horizontally scrolling shoot ’em up manufactured by Data East in the 2001 :
When I powered it up, I was greeted by this screen.
It was a clear lack on SYNC signal confirmed also by a measurement with a frequency counter on pin 13 solderside of the JAMMA connector.So, given the absence of schematics, I started to trace back the signal with a multimeter but couldn’t find where it was generated.Visually inspecting the board I found a suspicious crack over a trace :
My multimeter confirmed the trace was really severed.After patching it, the SYNC signal was restored but there were jailbairs on the sprites:
Sprites are stored in some 42 pin MASK ROMs :
I visually inspected the area and found another broken trace on solderside which lead to a data line of these MASK ROMs:
I promptly patched it with some AWG30 wire:
and sprites were restored:
But after this I realized that sound was missing at all.Diverting the audio signal to an external amplifier, I could hear both music and sounf FXs but there was no output from the TA8205AH amplifier on PCB :
So I decided to remove and replace it but , as for my previous Pitfall II repair, I was wrong, it was good.Looking at its datasheet, I could figured out how its mute circuit was made:
Checking the 220uF 16V electrolytic capacitor connected to pin 8 of the amplifier gave me a dead short across the terminals.So I desoldered and test it out of circuit having confirm it was really shorted:
I was recently sent an Asteroids PCB which I had previously bought back from the dead, the PCB had developed distorted vectors but still running.
Here is what the TEST screen looked like, the actual diamond shape was perfect but text was oversized and distorted;
The actual GAME mode looked worse;
Check out the giant asteroid!
I knew the problem was in the Vector State Machine (VSM) area, specifically the area which is responsible for handling object vectors, so I looked there first.
It was not long until I found a decoder (LS42) at 7E which seemed to have some pins stuck LO;
I desoldered the decoder;
I tested the decoder in my IC tester;
I then socketed and replaced with a fresh decoder;
A friend got a Gryzor PCB working but with problems on some of the sprites (mostly enemies and items with half of the horizontal lines missing).
The 4 GFX MASK ROMs were tested ok on another Gryzor PCB. Looking with the scope on the RAMs revealed nothing really suspicious.
I then piggybacked the RAMs around the GFX part and quickly found the faulty one.
It was the NEC 8644FU12 at location 14G. This RAM is a 4464 (64k-word x 4-bit, same type than the ones I replaced on my recently repaired Final Star Force).
Here is a picture of the PCB with the faulty chip highlighted in red:
Piggybacking it with a compatible TMS 4464-12 restored all the sprites.
In fact, the problem was so small that it was impossible to see any suspicious signal on any of the pins of that RAM with the scope (every signal looked healthy). I replaced the chip and obviously got the PCB running perfectly.
Had on the bench this Marchen Maze PCB (Namco System 1 hardware) :
On the power up I was greeted by this screen:
The RAM @D6 is a 6264 located on CPU board (fault was surely on this board since I succesfully swapped a good one) used in pair with another one @E6 , both are adressed by the near custom ’48’ which is a sprite address generator:
For first I went to replace both RAMs (sometimes the board booted showing an error also on the one @E6) but this didn’t cure the problem as well swapping a good known custom ’48’ had no effect.Probing these RAMs revealed some address lines stuck high.Looking at the schematics of Pac-Mania (which runs on same hardware) I figured out that adress lines from custom to RAMs are driven by two 74LS365 @H6 and @L6.
Parts mounted on the PCB were from Fujitsu which means high chance of failure:
After a quick test with my HP10529A logic comparator (which confirmed me troubles on all outputs) I decided to remove them.They both failed in my programmer:
This cleared the error on startup so board successfully booted into game but sprites were all blocky:
Judging from the kind of fault on screen, this, more than an addressing issue, had to have something to do with data.Always looking at schematics I noticed that data bits from the custom ’48’ and RAMs are routed to two 74LS377 @A3 and @A4 :
and from these to the custom ’39’ sprites generator:
Piggybacking the two 74LS377 I could partially restore sprites :
This lead me to remove and replace both.The desoldered ones failed when tested out of circuit :
Sprites back again in all its glory and board 100% fixed!
