PCB Repair Logs – Page 73

Final Star Force repair log

Jan 062016

Recently got this Final Star Force PCB with graphical glitches on the sprites.

This game uses a motherboard (pictured above) and has a romboard on the other side fitted with no other chips than the game’s ROMs.

All the ROMs were tested ok on my programmer and cleaning the connectors and looking at the signals, everything seemed fine with that romboard.
The motherboard has a rather simple layout with a lot of RAMs, some ASICs and a few TTLs. After a few hours looking for suspicious signals, I finally found the faulty ones.

There is a row of 12 Sanyo LM33464G RAMs (64k-word x 4-bit). Two of them were bad (the ones at IC22 and IC33). Piggybacking them with new ones partially brought back clean sprites, even if there were a few glitches remaining. These glitches totally disappeared after replacing the RAMs.
As these models of RAMs are a bit uncommon, I took compatible TMS4464 as replacement (highlighted in red):

Here are before and after pictures:

Haunted Castle repair log #3

PCB Repair Logs Comments Off

Jan 052016

Another Haunted Castle repair after the recent one from Corrado.

Board was in good shape :

Haunted_Castle_PCB

But it showed jailbars on sprites, besides the sound was missing :

sprite_issue

So I started to probe the two 4Mbit MASK ROMs containg sprites data and I found a bad signal on pin 28 of the one @J5 (good on the left, bad on the right) :

MASK_ROM@J5_data_line_comparison

I desoldered the MASK ROM and my programmer reported, indeed, troubles on pin 28 while I tried to read it :

768C04@J5_bad

Loading the dump in MAME I could reproduce exactly my issue :

issue_reproduced_MAME

With a programmed 27C400 as replacement of this MASK ROM the sprites were correclty restored so I went to troubleshoot the missing sound.With my analog scope I found weak signals on some data line of the 2018 SRAM @F2 (which the Z80 audio CPU accesses to) :

data_line_2018@F2_comparison

I promptly removed this SRAM which failed when tested in my programmer :

bad_MCM2018@F2

With a good RAM fitted the sound were restored but music was noisy and scratchy :

The FM sound generator is a Yamaha YM3812 @D5 which is connected to an external YM3014 DAC @C4.Probing its digital output (PIN 21) revealed differences compared to the healthy signal from a good board pictured below :

good_serial_data_YM3812@D5

So, I removed the chip and installed a good one :

YM3812@D5_removed

This restored a clear sound.Job done, board 100% fixed!

Bosconian repair log #1

PCB Repair Logs, Repair Logs Comments Off

Dec 282015

I got this original namco untested pcb as a part of a deal.

As always happens, untested =not working and infact upon booting up it was totally dead with only a fixed static screen.

I was not too worried because I had a Dig Dug by Sidam which I use for spare parts and there are also schematics available (by Midway).

So I began my troubleshooting.

I checked the clock on the 3x z80s and it was missing.

Traced back to a dead output of a 74128@6B. The input coming from custom 07xx was OK.

clock

I started to search for a replacement and I took my Dig Dug pcb but in place of the 74128 there was a socketed 7402.

Bad luck, someone put wrong TTL as a place holder….

I then discovered that this 74128 is not common at all and it is used only on early namco pcbs.

I decided to contact my friend Charles Mcdonald to have a suggestion how to make the pcb boot just at least to see if it hadn’t other faults.

He told me that this 74128 is a really weird choice because it is used to drive signals over long distances and a 7402 is the equivalent to drive lower mA, but I had to disconnect the R5 100ohm resistance.

In the end the guys at SIDAM made this “modification” on purpose to the original Namco design!

So I fixed the clock problem installing a 7402 and lifting provvisorily the resistance.

Foto 26-12-15 12 20 49

After booting up, unfortunately the game had another issue:

Foto 21-12-15 23 21 28

Foto 21-12-15 23 21 32

Foto 21-12-15 23 21 52

After some studying of the pcb schematics and some short circuiting I discovered that beneath these stripes there was the black background with the

stars correctly generated by the custom.

Worth of note is the score part of the display that was good.

On the video pcb there were 4x 4kx1bit rams 2147 which I didn’t have as spares (Dig Dug uses another video board) , two of them were running very hot .

Tested with the logic probe they were pulsing correctly.

At this time it was clear that the problem came from around there because shorting some pins changed the coloured stripes.

Disabling the CS line of the rams, restored good backdrop, stars and enemies but your ship and missiles disappeared.

So it was clear that these stripes where the “scattered” colours which should have been combined to make the ship correctly coloured.

I decided to test with the logic comparator the 74174@7D which is mixing the bits from the rams : it reported some bad pins.

mixing

When I changed it I got no better results, but I got another positive feedback that the problems came from the circuit near the rams.

If I left out completely the chip from the socket I got good backdround and no ship.

The enemies and bases are part of the background circuit.

All the TTL which were used to address the rams were good so it was clear that some or all the 4x 2147 rams were bad.

At this time I decided to give up and to order some new rams in the hope that the problem was really there.

Just before placing the order I decided to take another look at the 2148 ram @4J which on my pcb was not placed and I thought of a schematic mistake.

rams

Now everything was clear : Namco prepared already the pcb to accept one 2148 ram which is 1k x 4bit instead of 4x 2147 rams, 4 k x 1bit !

The highest addr lines are not used so it can really be used as a replacement!

I had a lot of 2148 rams so I immediately desoldered all 4x 2147 rams and placed @4J the 2148 ram

Foto 26-12-15 11 50 24

Foto 26-12-15 12 16 02

Finger crossed and when the game booted up I was finally welcomed with correct colours!

Foto 26-12-15 12 15 34

Haunted Castle repair log #2

PCB Repair Logs, Repair Logs Comments Off

Dec 282015

Got this pcb from a friend of mine for a repair

haunted

The pcb had already all the sram chips repaired and some flying wires underneath because of broken traces.

Upon boot up, it constantly reset with this message:

haunted1

First thing was to test the socketed sram chip 6264 near the 2 big customs but as expected they were good.

Tried to flex the pcb and it booted with wrong palette sometimes

haunted2

Surprisingly once it booted it could be played with wrong palette all the time until the next boot.

So the code did only a check at the beginning.

After pressing and flexing everywere I found out that the game booted only when I pressed the Hybrid module 007327

I discovered looking underneath that the module has some small srams and looking at the schematics this is confirmed.

haunted_007327

I turned out that one pin had a subtle loose contact. I reflown brutally everything to make it more resistant against shocks.

haunted3

Booted the game and I was welcomed to a perfectly working game

haunted4

haunted5

Aliens repair log #1

PCB Repair Logs 2 Responses »

Dec 272015

I had on the bench this Aliens PCB:

Aliens_PCB

Board had sever sprites issue:

sprites_issue

I performed a MASK ROM check which reported two bad 4Mbit devices @K2 and @K8:

MASK_ROM_check

I was able to exactly reproduce the issue by using two dummy ROM files in MAME:

0001

So, without further delay, I went to remove these devices and install two 40 pin sockets for the 27C400 EPROM replacements:

sprites_MASK_ROM_rework

With these replacements fitted sprites were perfect but I noticed that sound samples (like voices of main character or enemies) were missing:

Sound samples are stored in a 2Mbit MASK ROM @D5 (which is not checked by the self-test) and its data are processed by a custom marked ‘007232’ which is a PCM controller:

007232&MASK_ROM