Today I dumped the PALs (three secured PAL16L8) from a Sky Wolf PCB (bootleg of Airwolf).Devices are located on CPU board.Dumps have been successfully tested on GAL16V8 targeting devices.
I got two rare boards manufactured by Alpha Denshi for repair : Equites and Splendor Blast
Here’s Equites :
Board played fine except for jailbars on some sprites (look at explosions and first enemies on the ground in the below video):
All the GFX generation circuitry lies on bottom board:
A lor of TTLs were from Fujitsu (especially multiplexers 74LS157 and 74LS153) so I went to check them with my logic comparator.All passed the test except for the 74LS153 @8C:
I desoldered it:
The chip failed when tested out-of-circuit:
I added a socket and a good chip:
No more glitched sprites and board 100% fixed:
Here’s Splendor Blast:
This was a little tricky.When I first powered the board up, watchdog was active, the self-test was failing in all program ROMs and in the ‘ALPHA-8303’ MCU RAM:
Doing a visual inspection of PCB I noticed that one of the two custom SIL marked ‘ALPHA-INPUT84’ was wonky :
It came off in my hands when I touched it:
I powered the board without this component and board successfully passed the self-test so I resoldered it (most likely it was corrupting the main 68000 CPU data bus since some lines are shared with it) :
As I said, the board entered in game but some sprites showed jailbars:
The three sprites ROMs are in bottom board:
I dumped them and they were good.With my multimeter I figured out that address bus was shared among the three EPROMs while data bus was in common only among ROM 5 and 7.But I could not measure continuity between pin 15 (D3) of these two.I removed the devices from sockets and found a severed trace underneath:
Patched it and board 100% fixed.End of job.
Today we have some new PLD dumps.
‘robotype’ dumped the third PLD on an EspGaluda PCB, it’s marked ‘0315’ at location U33.He also confirmed that the EspGaluda dumps of the devices @U31 and U32 work also on DoDonPachi Dai Ou Jou (both ‘vanilla’ and ‘black’ version) providing the correct labelling too.
‘frsj8112 sent in dumps from a Dream Soccer ’94 PCB (on Irem M107 hardware).
All dumps have been tested as working in a GAL16V8 targeting device.Thanks to them for the contribution.
Lastly, we found that Street Smart and Prisoners of War (P.O.W.) share the same PLDs, they are in same location since hardware is identical.
Got this Wonder Boy (on Sega System 1A board revision) for a repair:
On boot I was greeted by this static garbage screen:
Main Z80 CPU had /HALT line asserted and no activity on data bus.I dumped the program ROMs and they were good.So I thought this was a good chance to use my Fluke 901A troubleshooter.According to memory map in MAME source the WORK RAM lies from 0xc000 to 0xcfff of the Z80 address space:
AM_RANGE(0xc000, 0xcfff) AM_RAM AM_SHARE("ram")
When I ran a long RAM test I got an R/W error at the beginning :
The WORK RAM is in form of two 2016 chips @IC135 and IC136 (so each one is 2K or 0x7ff in hex) :
So I performed a test from 0xc800 to 0xcff which was successfully accomplished:
This meant the chip lying from 0xc000 to 0xc7ff had to be bad (the 74LS245 between the data bus of Z80 and RAMs were good since bus is shared among the two RAMs).I hooked up the Fluke probe and looping a write of some values I could identify which RAM chip lies in which address range.The one @IC135 lies from 0xc000 to 0xc7ff while IC136 from 0xc800 to 0xcff.As further proof, I wrote random values in some memory locations from 0xc000 to 0xc7ff and reading them back they didn’t match the written ones meaning the memory locations were faulty.So confident I removed the RAM @IC135:
It failed miserably when tested out-of-circuit:
Fitted a socket and a good chip and board sprang to life with no issue.Another classic game preserved.
Got this Aliens PCB for a repair.Board was not in great shape, quite dirty :
When I powered it up I was greeted from this screen repeating in an endless loop sign that board was watchdogging:
The self-test reported two bad devices, in the case a 1Mbit MASK ROM @C24 contaning program code and a 2018 palette SRAM @E15 :
I dumped the MASK ROM and my programmer warned about a possible damage of the device:
I programmed an EPROM replacement and at same time replaced the palette SRAM @E15.The error @C24 was cleared but the SRAM was still reported as bad.Probing it revealed its PIN 21 (/OE) was stuck high.I could trace this signal back to pin 6 of a 74LS32 @E13, this was also confirmed by schematics (thanks again to ‘frsj8112’ for providing them)
I desoldered the 74LS32 and it failed when tested out-of-circuit (in gate n°2/pin 6, indeed):
In this way I could succesfully pass the self-test and enter in game:
Some backgrounds and sprites were corrupted so I launched a MASK ROM check which reported bad devices:
Dumping them revealed they were really bad except for the ones @J2 and J8 which were good.I replaced them with 27C400 EPROMs.While I was doing my tests another RAM suddenly failed :
I promptly replaced it:
After reflowed the two custom ASIC sprites generator ‘051960’ and ‘051937’, MASK ROM check reported all devices as good:
Backgrounds were perfect but some sprites were still garbled
Since the sprites MASK ROMs were all good and ruled out the two sprites custom generators as well as connections among them, I went to check the control lines of the MASK ROMs.When I probed the 74LS04 @F13 which generates the /OE signal for the devices @J2 and J8 :
my logic compator warned me about a trouble on pin 8:
The problem was confimed by the scope (input pin 9 on the left, output pin 8 on the right of the below picture)
I removed the IC and it failed exactly in the pin 8 (the output of gate n°4)
Fitted a good IC and success!Board completely fixed!It was a long job but it was worth it to save this great classic.Ah, I forgot, obviously the two bad TTLs were from Fujitsu…