Stun Runner repair log

 PCB Repair Logs, Repair Logs  Comments Off on Stun Runner repair log
Mar 292015
 

Had Muddymusic’s Stun Runner PCB for a long long time awaiting repair.
I put off looking at it because of how test bench unfriendly it would be to setup.
I did have most of the original loom to use but the audio section also used 13v AC and a test bench typically doesn’t have that.

I ordered a small 240v – 12v transformer and eventually set to work in hooking this thing up.
After half a day of messing around I had what I thought was a Stun Runner test rig.
While I had all the connections going to the right places and things like that I soon realised that the speakers I were using in now way suitable to check the sound and also my test bench monitors seem to be getting really picky about what they display properly.
In the end I settled for a black and white picture but I wasn’t too worried as the fault I was looking for was audio related.

The fault was that in game the music didn’t play and the engine tone played at a constant tone.
With my almost useless setup I could hear exactly this. I did a quick heat check with my finger on the audio PCB to check if any of the chips were getting hot and to my surprise all the sounds and music came back when I prodded the M6295.
IMG-20150310-WA0005

I powered down and reflowed the chip and all was working again.
I soak tested it as best I could and called it a day.

Muddymusic has now got it back and has confirmed the sounds and music are now good.

Mar 242015
 

About a month ago I purposely purchased a non working Gyruss off eBay to repair myself for fun. This repair would later inspire me to develop the Gyruss test rom which is currently being developed right now.

Symptoms: Game watch-dogging. Only gets as far as the grid test pattern, sometimes partial then resets perpetually.

$_57

First thing was to check the voltages from various +5v rails on the bottom board. Voltages were measuring quite low, around 4.7v. I have read that low voltages would also contribute to  this behavior. Adjusting the +5v didn’t help.

Next step was to verify all the game ROMs via romident which checked out good. Cleaned pins on all socketed chips, no change. Probed Z80 main CPU, confirmed barking reset line.

Removed both Z80s which tested good in known working Galaga board. Installed IC sockets and re-installed Z80s.
Began process of purging all Fujitsu branded ttls before troubleshooting with some Fujitsu branded ttls still remaining.

Four 74ls163s that are used for memory addressing the 2149 srams tested bad on my Micromaster LV48 device programmer ( but they turn out to be good after fixing the game and re-substituting the 163s back in. The ls161s that I had lying around seemed to work fine as well ). Caius said that these are difficult to test out of circuit so the result of the tests performed by my not so trusty Micromaster LV48 almost lead me in the wrong direction with this repair.

With the 161s installed the symptoms were exactly the same which prompted me to look at other areas as I didn’t believe these would cause the fault, these chips seem to be associated with the video display.

I checked some non Fujitsu ttl logic around the main CPU & 2kx8bit SRAMs. 13E & 14E ( LS245 ) tested good. 17C,5J,3J ( 2kx8bit SRAM ) tested good, 2J tested BAD ( 2kx8bit SRAM ).

@ 0x00000H expected 01, read 00

I was pretty sure that I found the culprit. Bad work ram would definitely cause this kind of issue.

Socketed 17C,5J,3J & 2J ( SRAMs). Replaced 2J with a Sanyo LC3517.

Retested with good results.

photo(1)

Tube Panic repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on Tube Panic repair log #1
Mar 222015
 

Some days ago I got two Tube Panic PCBs for a repair.I never heard about this game before, it’s a shooting ’em up game with an impressive graphics for its era (produced by Nichibutsu/Fujitek in the far 1984) and an hypnotic music.You fight with your ship through  trippy, intergalactic tubes and periodically, you’ll have to dock with a mothership for bonus points and power.

Anyway, let’s start with the first board repair:

Tube Panic#1

As you can see from picture above, owner labeled this board “NO SPRITES,NO INPUTS” but once I powered it on I got instead  strange behaviours, sometimes the game crashed, sometimes played  accelerated with blocky sprites.Here is a capture video of the issue:

As usual I started my check to CPU/RAM/ROM section.In these hardware there are three Z80 CPU, two of them are the main/slave and the third is the audio one.Probing the slave Z80 with a logic probe I found that its /INT line was silent.Traced it back to a 74LS74 @F5.Testing it with the HP10529A logic comparator revealed that output PIN5 was giving troubles and this output was indeed tied to /INT line.Desoldered and tested out-of-circuit it failed miserably:

74LS74#1

74LS74#2

Replaced this bad 74LS74 restored correct behaviour except for some little sprites issue which I traced to a 74LS298 @G19 (not actually faulty) which multiplexes data from sprites ROMS .So this first board was 100% OK:

Let’s pass to the second one which was labeled as “flashing”:

Tube Panic PCB #2

Actually it played fine except for the screen that was all blurry:

While doing my usual visual inspection I came across a very hot (I’d say ‘burning’) IC @I17, an HM4864 DRAM (64K x 1).Probing it all address lines were active as well the data IN pin but its data OUT pin was stuck LOW so data didn’t came out from device.Piggybacking a pin-to-pin compatible TMS4164 restored the graphics.Infact chip failed its out-of-circuit testing:

HM4864_out_of_circuit_testing

Like the first board also this one suffered from slight sprites issue due the 74LS298 @G19, it seems to be a congenital problem to this kind of hardware.

Double repair in a shot!

 Posted by at 10:09 pm

Altered Beast repair log

 PCB Repair Logs, Repair Logs  Comments Off on Altered Beast repair log
Mar 042015
 

Today I received a batch of some faulty PCBs and among them there was an original Altered Beast boardset:

Altered_Beast_PCB

Once fired up all was working fine except for the colors, they were clearly wrong (kinda pinkish):

colors_issue

For first I went into TEST mode.In all Sega System16 games(that support it) you can enter in TEST mode by pressing down at same time TEST,SERVICE and P1 start switches.But color RAM test was passed successfully:

Color_RAM_TEST

Near the two 6264 color RAM @J9 and J10 I noticed a couple of 74HC273 which input were connect to data BUS of the RAMs (as they latch input data).Probing the one @L11 revealed some outputs stuck HIGH though inputs were toggling fine.Piggybacked it and colors came to normal (well, almost, sky apart) :

colors_piggybacked_74HC273

Time to desoldering and testing it out-of-circuit:

74LS273_out_of_circuit_testing

Replaced it and board was 100% fixed.Job done.

 

 Posted by at 8:22 pm
Feb 152015
 

Got this original Taito/Toaplan Rally Bike PCB for cheap:

Rally_Bike

Seller claimed that it was working fine except that it didn’t coin up with both players.So, I was confident that it would have been an easy repair (but in hindsight I can say not really..).

When I started my troubleshooting I found none of the inputs (and dispwitches, too) were working.Checking all JAMMA connector pins with a logic probe revealed they were all fine (high when input is not activated  and low when button/direction switch is pressed) so resistors arrays were doing their job but something happened after and the signals could be not propagated.Tracing back the inputs I found that they were tied to inputs of some 74LS240 near the JAMMA connector.Probing them revealed that outputs didn’t change they state when inputs were activated because all the enable pin (PIN1 and PIN19) were stuck high.All these enable signals were tied to some outputs of a 74LS138 which I tested good out-of-circuit.So, I was in a dead end and giving up but doing some research about Toaplan hardware I came across this page:

https://allyourbase.toaplan.org/hardware/index.html

where it said that Z80 audio CPU handles not only sound control but also all I/O reading:

Toaplan_hardware.gif

So I started to probe the digital audio circuit and found thath some address lines of Z80 (and so also of the connected RAM/ROM) were stuck low as well all data lines of the YM3812 sound synthesis chip were in high impedance state due the /CS pin stuck high.The audio ROM was dumped fine and piggybackinbg the 6161 RAM had no changes at all but when I made it over the YM3812 suddenly the game coined up and started a game.I swapped it for a good one and all the inputs were working again.But sound was totally missing, only some hissing noise sign that the main MB3730 amplifier was good at least.Since digital part of audio circuit was fine, the fault was located in analog section.Probing the YM3014 DAC and the LM358 OP-AMP I could measure only 2.45V across their power pins sign that there was almost a short on thes two ICs:

LM358_YM3014_powering_test(1)

Infact, after removing them, I could measure the right voltage on the power pads:

LM358_YM3014_powering_test

Replaced both YM3014 and LM358 restored full sound.End of job.

 

 Posted by at 3:27 pm