A quick fix for a PCB that seems to develop always same issue judging from my experience and other repair logs.Received this Snow Bros for a repair:
It was playing fine but some sprites suffered from flickering (it’s hard for my camera to capture this, see from second 5 of below video) :
Maybe you can understand better from this picture provided me by the PCB owner:
The sprites are generated by the Pandora custom chip which read data from a MASK ROM and write them to four 4464 (64K x 4bits DRAMs) :
When I went to probe these dynamic RAMs with my scope all was good except one data line (D2, pin 3) of the one @IC24, signal was weak and stuck high compared to an healty one:
Confident I removed the chip which failed when tested out-of-circuit:
PAL UpdatesComments Off on Joe & Mac Returns PAL dumps added
Jul212016
Today I dumped the three PLDs from an original Joe & Mac Returns PCB.Devices were unsecured 18CV8 (two of them configured as registered and one as GAL16V8) so I read them in a standard programmer and then reversed equations into GAL devices.Keep in mind that two dumps require to be burned onto a GAL18V10 and one onto GAL16V8.
Actually board was a factory conversion from a Zero Wing board (hardware revision ‘TP-015’).When I powered it up, I got nothing of screen, neither the black and white wavy lines sign of the system being initialized like it happens in this Toaplan hardware :
Probing the 68000 main CPU releaved it properly received /RESET signal as well as clock was present.As usual I did my check on CPU/RAM/ROM data/address bus and all was fine.But I went to check the clock signal of the Z80 it was stuck high:
The clock is generated by a 28MHz oscillator then divided by a 74F163 and inverted by a 74LS04 before reaching pin 6 of Z80 with a frequency of 3.5 MHz:
On this kind of Toaplan hardware the Z80 commands not only the sound system but also the I/O, this would explain why the whole system didn’t get initalized since the 68000 could not find the Z80 running.Confident I went to remove the 28MHz oscillator :
Got this orginal Hellfire PCB (by Toaplan) for a repair:
After some initial problem due dirty sockets of program ROMs and oxidized JAMMA edge connector which caused missing boots, I was greeted by this scenario:
Sprites were wrong, garbled and stretched all over the screen.This part of graphics is generated by the custom ASIC ‘FCU’ :
I did a reflow of it but this didn’t lead to any improvement.Probing around I found a 6116 SRAM with some data lines stuck low:
Chip failed once tested out-of-circuit:
But still no big improvements.Testing TTLs with my logic comparator I found a 74ALS169 counter @3N with bad outputs:
Its output pin 15 was almost shorted to VCC (only 7.9 Ohm measured)
Once removed, the chip failed miserably :
Finally the sprites were correctly drawn but blocky :
I noticed that, if I pressed down the ROM 9 @4E, sprites were 100% restored:
Removing the EPROM revealed oxidation on socket pins:
Had this original Double Dragon II – The Revenge in my faulty boards pile so I deciced to take a look it hoping to fix it and complete the trilogy in my collection:
Once powered it up I was greeted by this static garbage screen:
A static screen is a clear sign of some trouble in the main code execution.So, for first, I went to dump the program ROMs and found a bad device which game me different checksum at each reading.Since my ROM set was an undumped japanese one, I was forced to convert my board into the US set which is available.This did not lead to any improvement so further investigation was needed.When I removed the EPROMs, I noticed that the socket @IC63 (the one of the bad EPROM) was oxidized:
I decided to replace it.When , before installing the new one, I was checking all the connections, I found an eaten trace underneath which should have tied pin 2 of the 74LS138 @IC64 (which generates the /CE signals for program ROMs) to pin 9 of a 74LS273 @IC71:
Once restored the connection board finally booted up but with severe sprites issues and corrupted/missing sound FXs:
Probing RAMs on video board I found some data lines stuck low on a TMM2015 @IC83 :
This was due two broken traces on solderside which I promptly patched:
This improved a little the issue giving back the missing lines to sprites but they were still wrong and garbled.Looking at MAME source, I could figured out that one of the two Z80 (the one @IC50) on top board is used as sprites CPU which takes data from a 27512 EPROM @IC37 and write/read them on a 6116 SRAM @IC24 :
Probing this static RAM (actually a Sanyo LC3517BSL compatible with 6116) revealed weak signals on its address bus:
Once removed the chip, it failed when tested out-of-circuit:
With a good RAM chip all the sprites were correctly restored :
So I moved to troubleshoot the sound FXs issue.Samples are played by an OKI MSM6295 @IC74 with takes data from two 28 pin 1Mbit MASK ROMs @IC39 and IC40:
Probing the two MASK ROMs revealed that data came out when requested so the problem had to be in the OKI MSM6295 chip which played them badly.I removed it :
and put back a good one:
This restored ADPCM samples.Board 100% fixed and board trilogy complete!
This restored ADPCM samples.Board 100% fixed and board trilogy complete!