PCB Repair Logs – Page 91

Double Dragon repair log #7

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:

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:

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:

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 :

Comparing it in-circuit revealed it was faulty:

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

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:

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:

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:

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:

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.

Nemesis repair log #1

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)

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

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:

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 :

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

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

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:

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:

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:

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

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:

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

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:

Piggybacking it restored sprites completely:

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

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):

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:

Replacing it and inputs were all correctly working:

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:

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

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.

Twin Cobra Repair Log

PCB Repair Logs, Repair Logs 3 Responses »

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.

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!

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.

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…

Vendetta repair log #3

PCB Repair Logs, Repair Logs 1 Response »

Apr 142015

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

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

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

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.

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

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.

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

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

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

PCB Repair Logs, Repair Logs Comments Off

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 :

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

Older Entries Newer Entries