Feb 202018
 

Hi everyone, I’ve been a long time follower of jammarcade.net for several years and I’ve received a lot of help and advice from both Porchy and Caius. A big thank you to you guys! 🙂

Caius then approached me and asked if I wanted to contribute with my own repair logs of the games that I have resurrected from the dead and I thought that would be fun 🙂

So for my first post I thought i would document the repair of a Irem Battle Chopper. Pretty obscure and rare game that is hard nails, as always when it comes to Irem games.

The PCB was in pretty good condition but was missing some color. It displayed mostly blue graphics and faint red and green.

Having worked on M72 hardware before, I knew that color output was handled on the middle board in the PCB stack.

I started with measuring the RGB signals on the JAMMA edge with my oscilloscope, I could verify that the signal of R and G were absent.

Having access to the R-type schematics, I checked where the RGB signals came before it arrived at the JAMMA edge.

 

As you can see it derives from the custom KNA91H014. Bad news I thought, but when checking the outputs with the oscilloscope, all the outputs looked fine. So I then started measuring the resistance of the resistor networks (RA13, RA14 and RA15) and they also checked out ok.

Everything in that areo seemed to be ok, so I started to look more into the schematics and found this on the same page as the snippet above

When checking the outputs of this 74LS38 at location IC67 with my logic probe, I could see that red and green were floating. And I could also verify that they were both shorted to ground.

I then desoldered the 74LS38 and could then verify it as bad in my TTL tester

These 74LS38’s aren’t that very commonly used on arcade pcbs, at least in my experience, so I needed to wait for a replacement to arrive. In the meantime I added a socket on the PCB for easier access for the future.

With the replacement in place, I booted up the game and lo and behold, all colors are back 🙂

A good and rare game back in its full glory.

Tricky Doc repair log

 PCB Repair Logs  Comments Off on Tricky Doc repair log
Feb 162018
 

Received from Austria this Tricky Doc PCB for repair, a weird game released by the spanish Tecfri in 1987:

The board had severe graphic faults (and missing sound too)

The faults affected mostly the sprites :

So I went to dump the four devices (27128) that store this part of graphics and I found a bad one :

I was checking the sprites generation circuitry when I noticed that some address lines of the ROMs were tied to a 74F138 while all other ones to some 74LS157.I compared the board with a bootleg with identical layout and found that the 74F138 was wrongly installed, actually a 74LS157 must be used instead:

Checking around I found a fried trace that should  have connected to VCC pin 9 (/LOAD) of a 74LS163:

But all these findings lead to little improvement, graphic issue were still noticeable.So moved on to troubleshoot the lack of sound.With an audio probe I found that sound was present before reaching the main amplfier, a Philips TDA1510, but then I got silence on edge connector pins:

It turned out that the amplifer lacked the GROUND connection (so it was no powered) so I added a jumper wire from its pin 7 to a near point.I also installed some capacitance (a 15nF mylar capacitor) between input pin 2 of the amplifier and GROUND to shut down some buzzing noise.

Back to the GFX issue, there is a row of eight 2148 RAMs (1K x 8-bit device) involved in sprites circuit:

The two on top were really burning hot to the touch.A quick check with a multimeter revealed some data lines were nearly shorted to VCC:

They obvioulsy failed when tested out-of-circuit:

This was the status of the board so far, sprites were still glitched:

I started to check ICs in-circuit using a logic comparator and doing piggybacking too.When I put a good IC on top of the 73F374 @2G :

the graphics were completely restored:

Probing the IC with a scope revealed the outputs were floating (inputs on the left of the below picture)

I removed the IC and, altough my testers reported it as good, I replaced it.This cured the issue and fixed board completely.As title of the game suggests, it was a “tricky” repair but was worth it in order to salveage a such unusual board.

 

 Posted by at 9:44 pm

Konami Viper repair log

 PCB Repair Logs  Comments Off on Konami Viper repair log
Feb 142018
 

I’ve been playing around with a couple of Konami Viper PCB’s that Olly sent me recently.

The idea was to get a working PCB for his Silent Scope Fortune Hunter.
This board set was non booting and a quick visual inspection showed some signs of ‘man-made’ damage.
First was the 3793-A voltage sense IC was a bit mangled which had lifted most of its traces. Chances are this was causing the PCB to not boot as this chip is responsible for making sure the voltage levels are what they should be.

As its a small pin count it was fairly easy to patch up the traces.

The second issue was the DS2430 IC has been removed. Luckily this was provided in a small bag so I was able to refit it (after dumping it). This IC is in a TO-92 package and is responsible for providing one aspect of the security on this hardware. I never took any pictures of this but its only 3 legs to solder and there was no damage.

After dealing with these the PCB booted right up
Taking pictures of this was really hard due to the amount of glare my cheap screen gives.

From here I can get the game to boot up but I cannot test beyond that. I will send this PCB back to Olly and hope it works out for him.

 Posted by at 3:33 am

Sunset Riders repair log #7

 PCB Repair Logs  Comments Off on Sunset Riders repair log #7
Feb 102018
 

Still another “portughese” PCB, a Sunset Riders :

The board was unstable, most of times it didn’t boot and kept resetting (watchdog active), some times after some reboots it got past the self-test and entered in game but sprites were missing.If I pressed/flexed the board, they appeared.Here’s a video for a better understanding:

I noticed someone previously tried to fix this issue by reflowing the two sprites generator ‘053244’ and ‘053245’  (forgetting to remove flux residuals )

The reflow was done properly but it was not enough, anyway there was for sure a bad contact in this area. At a closer inspection I found that a pin of the near ‘054358’ custom had its pad detached from PCB, this caused intermittent contact with its trace.Here’s a close-up under a microscope:

I promptly restored the connection, in this way the board booted all the time with sprites too.But playing the game I noticed some little glitches :

The glitches got worse if I put my fingers on the solder side of the two palette SRAMs (2K x 8-bit devices)

The one @14D was already replaced and socketed, probing the other one @13D with a scope revealed unhealthy signals on some data pins  :

This lead me to remove the device and test it ouf-of-citcuit where it failed:

Replacing the RAM fixed board completely, another successful repair in the archive.

 Posted by at 11:07 pm

Aliens repair log #4

 PCB Repair Logs  Comments Off on Aliens repair log #4
Feb 092018
 

Got always from Portugal this Alien PCB:

As often happens on this hardware the sprites had jailbars thru:

Board uses 4Mbit MASK ROMs to store GFX (sprites and background) data that are quite prone to failure.I launched a MASK ROM check that reported a bad device @K8:

I removed it and my programmer warned me about pin 13 (data line D0).I tried the dump in MAME and I could reproduce the issue :

I replaced the MASK ROM with an equivalent 27C400 EPROM :

This fixed issue and board completely.End of job.

 Posted by at 10:56 am