Repair Logs – Page 45 – JAMMArcade.net

Wild West C.O.W. Boys of Moo Mesa repair log #3

PCB Repair Logs Comments Off

May 032017

Today I received this Wild West C.O.W. Boys of Moo Mesa PCB for repair:

PCB was faulty, initial RAM/ROM check failed showing a ‘SOUND SYSTEM BAD’ error and then resetted :

Sound circuitry was already reworked: two RAMs, the Z80, the YM2151 and the ‘054539’ ASIC were replaced, the ‘054986A’ module was socketed too.But this was not enough to locate the fault :

The sound system reported as bad is ruled by a Z80 CPU, probing it revealed its pin 16 (/INT) was asserted, this meant the CPU was undergone an interrupt request stopping execution of code.It was time to use my Fluke 9010A.When I performed a BUS test, it reported address bit 15 (pin 5 of Z80) tied LOW:

This doesn’t necessarily implies the address line is shorted to GROUND but also that something is forcing it low.But in my case it was really shorted (only few Ohms of resistance to GROUND measured)

Doing some continuity test on a good board I could figured out that pin 5 of the Z80 is connected only to pin 5 of the PAL ‘054744’ @E7 and pin 1 of the 74ALS157 @C7 so in my faulty board one of these IC was bad :

For first I intentionally cut the trace going to pin 1 of the 74ALS157 @C7:

This actually cleared the short to GROUND of pin 5 of the Z80, hence the TTL was internally shorted.Tested out-of-circuit it obviously failed:

Now board could pass the RAM/ROM check and enter in game:

But sound was very faint, barely audible.I was forced to set volume to maximum to hear something:

The ‘054986A’ module was already recapped with thru-hole electrolytic capacitors:

A faint sound meant the main amplifier was working but something was wrong in pre-amplification performed by the 4558 OP-AMP on the underneath of the module.So I went straight and replaced it with a compatible LM358:

Sound was back loud and clear!Job done.

Truxton repair log #3

PCB Repair Logs Comments Off

Apr 262017

Another faulty Truxton PCB on the bench:

These were the issues: sprites were totally absent, sounds was loud and screen was disturbed by some wavy lines

Interferences on video are a common issue on this board, usually they are caused by electrolytic capacitors with increased ESR (especially the filter ones connected to +12V line).On my board the capacitor @C1 connected to +12V was previoulsy replaced:

But who replaced it managed to break the internal connection to GND of its negative terminal, you can see in the below picture that pads (and internal rivets) were ripped off:

The capacitor lost its GROUND reference hence it was not operational.This also explained why sound was loud: the amplifier was oscillating due the missing function of this capacitor (the role of these capacitors in audio circuit is indeed to avoid dangerous oscillations of components) and this affected the video too.I restored the connections, this cured both loud sound and video interferences so I moved on to troubleshoot the lack of sprites.Object data are stored in four 1Mbit 28 pin MASK ROMs :

Probing the address lines revealed they were all stuck low and hence data lines too.Address lines come from outputs of some 74LSALS163 but they resulted good when tested in circuit by my logic comparator.Probing around revealed nothing abnormal until I came across this custom chip (DIP 42 package) marked ‘TOAPLAN-02 M70H005’:

All the pins from from 1 to 21 ( not counting pin 21 which is GND) were toggling but all the ones from 22 to 42 on the other side (except pin 29 GND, and 23-42 VCC) were stuck, these were most likely the outputs.I compared the behaviour on a good board and had confirm that the stuck pins had to be active hence the custom was dead.I desoldered it and I found a ‘GXL-02’ silkscreening under the chip:

I remembered I had a couple of other Toaplan boards I harvested (Hellfire and Out Zone) with same silkscreening on PCB but different marking (”FDA MN53007T0A’) of the custom chip:

Power supply pins were the same so was worth a try.And I was successful, sprites were back:

Later I found that this custom is used on many other Toaplan boards but under different labels.For example, it’s ‘T.T-2’ on Twin Cobra :

‘WT2’ on Wardner:

‘L-02’ on Sky Shark:

‘12.02’ on Rally Bike:

Flicky repair log #2

Apr 222017

Quick repair this one.
Game booted to a black screen, sometimes garbage on screen and could see/hear the watchdog doing its thing.
This board was running the encrypted version of the game with its custom Z80 CPU.
As the CPU is socketed I just plugged the Fluke straight in and ran the usual tests.
All the ROM’s passed but work the RAM failed

The schematics are the same as for Star Jacker and the RAM could easily be located

Tested the RAM out of circuit and sure enough my tester flagged up address pin A8 as being disconnected so it matched the Fluke’s output too.
I replaced the RAM and fire up the game

The sound and controls both work fine and my work here is done.

Mach Breakers repair log

PCB Repair Logs Comments Off

Apr 212017

Received this Mach Breakers PCB from a friend for a repair (it turned out to be an undumped World revision, I alread submitted it to MAME)

Game was released by Namco in 1994 and runs on a powerful hardware platform called ‘NB-2’.Here is ovrview:

Main CPU: Motorola 68EC020 32-bit processor @ 25 MHz
Secondary CPUs: C329 + C137
Custom graphics chips: GFX: 123, 145, 156, C116 – Motion Objects: C355, 187, C347
Sound CPU: C351
PCM Sound chip: C352
Control chip: C16

The board was faulty, most of sprites had jailbars:

Sprites data are stored in ten 16Mbit MASK ROMs (Fujitsu MB8316200B in SOP44 package) located on the MASK ROM daughterboard:

Probing them with a scope didn’t help much since each column of devices has shared address and data busses.So I proceeded in this way.I created some empty binary files (2MByte each one) and loaded them one at a time in MAME in order to reproduce the issue and pinpoint which devices were bad.When I did it for the ones @8A-8B-8C I got pretty same artifacts under emulation:

So I went to remove these MASK ROMs starting from the one @8A of the column :

And I hit it since I was not able to get always same CRC when dumping it so device was really bad.Replacement for the MB8316200 is a Macronix MX29F1610 Flash EEPROM which has same pinout (except for pin 1 and 44 which are used for programming)

Luckily I was able to find among my spares a donor board where to take the devices from :

Time to program it using a SOP44 to DIP adapter:

After soldered it on board I got a big improvement, jailbars were gone away but there were still dots on sprites:

Again I went to corrupt the MAME ROM files and I could pinpoint which was the involved device: the one @4C.I removed it :

I dumped it several times and obtained different CRCs at each reading, it was really bad.As further proof I loaded one of these bad dumps in MAME and I was able to reproduce exactly the issue:

I programmed a new MX29F1610 EEPROM as replacement, this fixed completely the board:

Not only bad TTLs from Fujitsu!

Zupapa! (Neo-Geo MVS conversion) repair log

PCB Repair Logs Comments Off

Apr 202017

Got for repair this Neo-Geo conversion cart of Zupapa! a platform released in 1994 only for MVS system and not on the Neo-Geo AES home console :

Most of graphics were blocky:

I opened the cart:

As I said, the cart was a conversion from a donor hardware, this requires the ROMs to be replaced with game code and data plus some other modifications like adding some ICs and jumpers.Doing a visual inspection on work done I found nothing of abnormal until I came across this:

One of the zero Ohm resistors used as jumper required by the conversion was badly soldered.I put it in place and magically all the graphics came back:

A simple but effective fix!

Older Entries Newer Entries