Apr 212015
 

Recently, I picked up an ‘untested’ Twin Cobra PCB off of eBay. As most of us are aware, when something is advertised as ‘untested’, 9 times out of 10 its completely broken. This Twin Cobra was no exception to this rule.

twin_cobra

 

Out of the box, the game booted up to a flat black screen, zero activity at all. When I see this on unknown condition boards, the first thing I do is give it a thorough visual inspection. I generally look for rust/corrosion, deep scrapes and gouges severing traces, physically damaged capacitors and IC’s, etc. Right off the bat, I noticed the the Koyo 28mhz crystal at X1 was hanging on by a thread! The other three had snapped off at the base of the crystal, so it was time to find a replacement. I was able to find a donor crystal in my parts boards.

 

I desoldered what was left of the original crystal, and then I installed the donor. The donor is slightly faster than the original, but it should be OK until a proper replacement arrives in the mail.

       

 

The rest of the board looked good – no gouges, no other damage so to speak. At this point when I powered it up, the game sprang to life!

twin_cobra4

 

Everything appeared to be working as expected, so I coined up and tried a game. Almost instantly, the next fault presented itself. Some (not all) of the sprite layers were incorrect. When the tanks aimed at towards 7:00, their turret would disappear completely. When larger tanks were destroyed, their remnants would take priority over my helicopter.

 

I knew something was at fault either with the ram or layer priority sections of the video board. From here, I started reading up on the mame driver, as well as the memory map for Twin Cobra posted on Toaplan.org. From what I could tell, it looks like sprite priority is controlled by the bipolar roms present on the TP-011 SUB (graphics) pcb.

 

I gave the 82S123’s a closer look, the bipolar rom marked B30-22 on the parts side of the PCB had a factory defect! There was a small solder bridge connecting pins 5 and 6. I fired up my soldering iron and removed the bridge.

twin_cobra3

 

Fired the board up, all faults were cleared! Game now works 100%. It’s mind-blowing to think that a game manufactured in 1987 has only played properly some 28 years later. This Toaplan masterpiece lives to fight another day! Until next time…

 

 

Apr 142015
 

Had this board for a while now but hadn’t looked at it.
IMAG1239

On booting the board up I got completely messed up graphics.
IMAG1238

On my pre power up visual inspection I somehow missed the damage and solder blob on the 052109 tilemap generator.
IMAG1240

I removed the solder using solder braid and straightened the legs up best I could with some fine tweezers. It took a while as I didn’t want to snap the legs off but I ended up with something I was happy with.
IMAG1255

Fixing that gave me the graphics back but there were jailbars present.
IMAG1242

Jailbars are usually a sign of a failed ROM and as the two MASKROM’s have previously been replaced for a pair of 27C400 EPROM’s I thought it was best I check these out first.
Both turned out to be fine so the next step was to check the address and data line to see if they were active.
Again I could find no problems here.

I then found the test menu which runs a self test on these ROM’s. The ROM at location 16I gave a different checksum each time I ran the test. A changing checksum can be a sign of a floating data pin. I already knew the data pins were active and that the ROM’s were good so I set to work with the multimeter checking continuity between the EPROM and the 051962 tilemap generator which these data line go to.
Eventually I found data pin 8 did not make it to the 051962.
IMAG1243

I was able to patch this underneath the EPROM so it would be hidden (and protected).
IMAG1244

On powering up all the jailbars were gone and the board is fixed.
IMAG1253

Lei Shen Zhuan Thunder Deity Biography (Chinese hack of Battle Garegga) repair log

 PCB Repair Logs, Repair Logs  Comments Off on Lei Shen Zhuan Thunder Deity Biography (Chinese hack of Battle Garegga) repair log
Mar 292015
 

First of all, my apologies for the kilometric title but this seems be the correct one according to MAME which has emulated this game after my dumps 🙂

A friend of mine sent me this Battle Garegga bootleg PCB for a repair :

rsz_battle_garegg_bootleg

saying it had bad sound.Infact it was scratchy and noisy:

Besides, sometimes it muted completely.Regarding this last issue, I traced it to a bad YM2151 FM (actually a rebadged version marked ‘PD2001’) sound synthesis chip, once replaced it I got no more mutings.As for noisy sound, connecting the analog output (PIN12) of the YM3012 DAC (a ‘KA3002’ rebadged chip also here) to an external amplifier revealed that sound came out distorted.

Replaced it fixed the sound completely

 Posted by at 11:10 pm

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)