Out Run repair log #1

 PCB Repair Logs, Repair Logs  Comments Off on Out Run repair log #1
May 172015
 

Another board from my friend ‘robotype’, this is the time of a genuine Sega Out Run:

Out_Run_PCB

Once powered up I was greeted by a colored  stripes static screen:

watchdog_active

Since I already repaired an Out Run board with same issue I remebered that this is a symptom of active watchdog and infact this was confirmed by probing RESET and HALT pins on main 68000 CPU.I wanted to  use my Fluke 9010A troubleshooter but due the presence of a custom memory mapper between main CPU and RAMs (which, indeed, generates dinamically the memory map on boot) I wasn’t able to do it.

CPU_RAM_ROM

For first I read the four program ROMs and they were good.So I went to probe the CPU/RAM/ROM circuit and I found many CPU address lines tied LOW or HIGH.Piggy backing the two 74LS244 @IC136 and IC137 didn’t change nothing but when I did it on the two TMM2063 (6264 compatible) WORK RAMs @IC115 and @IC130 I got this screen in which I could descry the welcoming message of a successful boot:

6264_piggybacking

This lead me to desolder the two RAMs which were confirmed as faulty from my tester

6264_failed

So I could enjoy again the Magical Sound Shower!

 

 Posted by at 11:27 pm
May 102015
 

I had this PCB since many years, honestly I couldn’t remember when I got it or where.The only sure thing is that it was faulty.Condition was pretty good for a such ‘aged’ board but it was missing a BPROM @IC101 as you can see:

Double_Dragon_PCB

Original part is a Fujitsu MB7114, pretty impossible to find nowadays so I opted for a 82S129 which an equivalent one.After burned the device with the correct file supplied by MAME, I powered on the board and some times it got stuck on RAM/ROM TEST showing error on WORK RAM:

WORK_RAM_ERROR

Other times it booted into game but sprites were missing, could not coin up, screen was unstable and speed was kinda accelerated.When I got this strange behaviours, the fist thing I check is the main CPU, in this case an Hitachi HD63C09.Probing it I found that PIN2 and PIN4 were stuck LOW, they are respectively the NMI and FIRQ interrupt lines:

HD63C09_IRQ

So this meant that CPU was undergoing a request of interrupt from external devices (an interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention).As you can see from the above schematics these two signals are generated by a 74LS74 @IC73 so for first I went to check it and I found missing CLOCK and CLEAR signals input on PIN3 and PIN13 respectively.In particular CLOCK on PIN3 is the VBLANK signal and this is generated by a NAND gate of a 74LS00@IC70 on VIDEO board :

VBLANK_generation

Comparing it in-circuit revealed it was faulty:

74LS00@IC70_comparing

Once replaced it I got no more WORK RAM error and strange behaviours, game was playable but all sprites were missing:

no_sprites

This a common fault on all Double Dragon PCBs since object generation circuit is wide and made of many components (it occupies five sheets of the .PDF schematics).

So, following the schematics I checked this part of circuit and all was fine until I came across to this section:

OBJECT_generation

The 74LS86 @IC72 had stuck outputs and these are tied to some ADDRESS lines of a TMM2018 SRAM which had some silent DATA lines, too.So I prontly desoldered them and they failed once tested out-of-circuit:

first_fix

I thought my job was done but I was wrong since this improved the sprites but not fully restored as they still missed some lines symptom of missing DATA:

improved_sprites

So I kept to check the OBJECT circuitry until I come across the TMM2018 SRAM @IC20 which had four silent DATA lines (PIN14-PIN17).I piggybacked it and magically all sprites were restored:

sprites_fixed

PCB 100% fixed and another one preserved!

Just a note for future reference : there are five TMM2018 (6116 equivalent) sprites RAMs and they are @IC73, @IC81, @IC84, @IC120 and @IC7 on VIDEO board.

 Posted by at 10:22 pm
May 082015
 

This will be a long repair log so if you have better to do, come back later… 🙂

Got this Konami Nemesis PCB from my friend ‘robotype’.Board was in very good condition despite its age (it’s 30 years old)

Konami_Nemesis_PCB

but bought from him as not working and infact it was just so :

no_boot

All I got was this static scambled screen.First I checked main CPU 68000, it  had random activity on DATA/ADDRESS bus) but, worst thing,  it was was burning hot to the touch!

So I decided to replace and socketed it (faulty one showed a resistance of only 65 Ohm across VCC and GND).With a new CPU fitted situation was a little improved but still some address lines were stuck LOW or HIGH.Fired up my Fluke 9010A with a 68000 POD and I could successfully test the WORK RAMs (four MB8464).So there was someting that drove the address lines.Piggybacking the 74LS244 @17L on CPU board I could descry the RAM/RAM initial check and comparing with a good one from MAME,  ‘CHARACTER RAM’, ‘VRAM 1’  and ‘VRAM 2’ were apparently reported as bad:

RAM_ROM_TEST_comparing

Probing the VRAM 1 ( TC5533 @ A15 and C15) and VRAM 2 (TC5533 @ D15) on VIDEO board revealed that their enable lines were stuck HIGH.These signals are generated by a 74LS138 @6J which I tested good with my HP10529A logic comparator then are routed to a 74LS10@16J :

enable_lines

this gave me troubles on PIN8 when compared with a good reference chip.Testing it out-of-circuit confirmed it:

74LS10@16J_failed

Replacing it cleared the VRAM 1 and 2 error but still CHARACTER RAM was reported as bad:

74LS10@16G_replaced

Character RAMs are eight 4416 DRAMs on the VIDEO board.Probing them I found that the three ones @2A, 2B and 4A had two DATA output lines stuck high while all address line were toggling properly.Once desoldered I tested them out-of-circuit and they failed miserably.Replacing them cleared the error on startup:

TMS4416s

Finally I could pass the RAM/ROM TEST and enter into the game but clearly there was more work to do on.As you can see from pictures above screen was greeenish symptom that blue color was wrong.This color is digitally generated from this part of circuit:

blue_generationst

So I probed the 74LS09 @5K with my logic comparator which gave me troubles on all its outputs.It failed once tested out-of-circuit:

74LS09@5K_testing

Colors were restored but sprites were completed missing replaced by vertical lines across the left half of the screensprites_issue

Object RAMs are sixteen 4164 and probing them revelead that three of them (@2G-2H-6H) had stuck DATA output (PIN14).They were bad tested out-of-circuit:

TMS4164

But sadly this improved sprites a little as you can see:

improved _sprites

So I went again to probe object RAMs and found that all write enable lines were stuck high!There are two WR lines and each one is shared by eight DRAM.With the help of schematics I traced them back to a 74LS244 @13G which had some stuck outputs:

object_RAMs_WR_enable_line

Piggybacking it restored sprites completely:

sprites_restored

Graphics were perfect now game has no sound and two inputs were stuck as confirmed by I/O TEST:

stuck_inputs

Looking at schematics I traced COIN1 back to a NEC PS2401 optocoupler @2H, piggy backing it cleared the fault so I replaced it.Piggybacking the one @2E for 2P SHOOT2 didn’t fix anything so fault was elsewhere .Between JAMMA edge inputs pin and PS2401 optocoupler there are some protection diodes (1S1588 type):

inputs_circuitry

Probing the one @D1 connected to the 2P SHOOT2 revelead it was almost short-circuited as it showed a forward voltage drop of few mV compared to a good one:

1S1588@D1_comparing

Replacing it and inputs were all correctly working:

inputs_fixed

Lastly : the lack of sound.Probing the digital audio circuitry I noticed that Z80 and two AY-3-8910 sound generator were missing clock and this is  generated by a 74LS367 @11G on CPU board:

Z80_AY-3-8910_clock_circuit

Comparing and testing it out-of-circuit confirmed it was bad:

74LS367@11G_testing

But still had no sound at all.So I went to probe the analog section.Diverting the input of the LA4460 amp to an external amplifier I could hear sound so I replaced it.But some music tracks were clearly missing.From MAME source: sound is generated by a Konami SCC ‘005289″ ,a two channel sound generator indeed, each channel gets its waveform from a prom (4 bits wide).Address lines A0-A4 of the prom run to the 005289, giving 32 bytes per waveform. Address lines A5-A7 of the prom run to PA5-PA7 of the AY8910 control port A, giving 8 different waveforms.PA0-PA3 of the AY8910 control volume.

Probing the two 6301 BPROMs I found that address lines A5-A7 of the one @7A were inactive and, as described in MAME, they are addressed by the control port A of a AY-3-8910.This lead me to replace the AY-3-8910 chip @7E and this fully restored the sound.Board 100% fixed!

Just a quick note : all the TTL replaced were by Fujitsu manifacturer.

 Posted by at 10:09 pm
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