Bosconian repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on Bosconian repair log #1
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 on Haunted Castle repair log #2
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

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

Probing the 2Mbit MASK ROM revealed no activity on data and address bus, all pins were stuck high so I removed it:

MASK_ROM@D5_removedJPG

and replaced it with a 27C400 (with doubled content since no 2Mbit MASK ROM replacement exists).This restored all sound samples.End of job.

 Posted by at 9:12 pm
Dec 262015
 

Yes, yet another Rainbow Islands on the bench!

Rainbow_Islands_PCB

Once powered up the board, I was greeted by this static screen:

no_boot

The watchdog was active sign that there were troubles in main code execution.For first I dumped the program ROMs and they were good (although they were from the Extra version so board was actually an hybird since C-CHIP was the one from the normal version).Then I passed to analyze the WORK RAMs (two Toshiba TMM2063) and I found weak signals on data lines of both:

weak_data_lines

This lead me to remove them, they both failed when tested in my programmer:

WORK_RAMs

With good WORK RAMs the board successfully booted but sound was missing at all:

Fitted a missing 1000uF 16V capacitor @C84 in the sound section was not enough to restore sound:

Missing_1000uF16V@C84_

I noticed that the RAM of the Z80 audio CPU was another TMM2063 which seems to be very unreliable part (like Fujitsu TTLs, I’d say..) so I went to piggyback the one @IC44 and sound was restored.The chip failed the out-of-circuit testing:

6264@IC44

Yes, yet another Rainbow Islands PCB saved from scrap pile!

 Posted by at 7:31 pm

CPS1 A-BOARD (old revision) repair log

 PCB Repair Logs  Comments Off on CPS1 A-BOARD (old revision) repair log
Dec 252015
 

I got this CAPCOM CPS1 A-BOARD (the old hardware revision) from my friend Joachim for a repair:

A-BOARD_OLD_PCB

He said me that board had some input problems.This was confirmed once I powered it up since most of player 1 and 2 controls were irresponsive but, after few times I cycled power, suddenly the board lost the red color:

missing_red

I started to troubleshoot first the input issue.As usual I inspected visuallly the board and found some corrosion near the JAMMA edge, some of the traces from the involved input pins to custom resistor/capacitor arrays and 74LS245 were eaten:

traces_corrosion

This was confimed also using my multimeter in continuity test.With some patching work and jumper wires I restored the connections and after this all controls were correctly working:

patching

As for the red color issue, schematics for this hardware are available so I went to look at the involved circuit:

palette_circuit

I found weak data signals on the two CXK5814 SRAMs (compatible with the TMM2018 suggested by schematics and PCB silkscreening) @4D and 5D (good on left, bad on right) :

data_signal_comparison

Since the data bus is shared between these two chips I could not know which was exactly the bad chip affecting the other so I piggybacked both them and when I did it on the one @5D, the red color was restored.So I desoldered the chip and it failed the test in my programmer:

CXK5814P-45L@5D

Fitted a new SRAM chip fixed the board completely.

 Posted by at 7:43 pm