This is the second board Enrico gave me for repair, a Data East game from 1990, the first chapter of the Dark Seal legacy, also know as Gate of Doom, here is the PCB:
After a quick and dirty test, the board is experiencing several issues, wrong/missed colours in the text layer:
The text is unreadable it shoud be bright white, you can see the issue also on this image:
All the text were black, and nasty jailbars were present on the back graphics plane, and as the demo goes on also the sprites plane were totally or sometimes partially missed, and the background reports wrong/missed colours too. You can look at these issues on the following picture:
I started investigating by the usual visual inspection of the PCB. A deeper look at the soder side reveals the first damage reported by the board:
A scratch cutted some traces, it was very thin and sharp so the issue can be fixed by removing the protective shield painted over them and by reflowing the traces with the soldering iron without patch wires over the board:
With my magnifing glass i looked also at the component side of the board, and with the help of a needle a spotted also some lifted pins on a custom IC, also the traces under the IC seems to be lifted but fortunately they were not damaged, so i reflowed them:
These fixes recovered, the text and background colours and the missing sprites ingame:
Now the text is ok, and the sprites and background too :
But, jailbars still there … so the board need further cares. Jailbars can be caused by several issues, a bad eprom, broken traces, broken logic, broken data buffers, and so on … i started looking and the maskrom where the involved graphics are stored following the data path with the scope. Probing around i should able to identify the right maskrom, usually you should look at the schematics, sometimes they are well documented also on the MAME driver source, but when these methods doesn’t work you should get hands dirty and use other uncoventional methods for the series … “don’t try this at home!”. But safety first! So don’t worry Enrico no harm has been done to your board! 🙂
I succesfully identified the maskrom where i must look at, and i found one stuck line on the 74LS273 latches near it on red square, probably this should be the culprit for the jailbars. So i go on and i looked at the solder side for connections to and from the suspicious latch chip with the stucked line:
These are clear signs of oxidation and/or corrosion, a closer look after the cleaning reveals a broken trace under the dirt.
You can see other damaged tracks on the left but they are in working order. There is not enough room to apply a safe and robust patch in place so i had to use a small wire.
It’s time to test the board again … i powered it up and …
Yeah! No more jailbars and the board is fixed! Another case closed!
… and now … “Go forth brave adventurers and may the gods guide you!” 🙂
UPDATE: looking at the board i found a damaged volume pot in working order but hard to adjust due to its conditions:
Probably someone has been used a screw gun against it in the past to pump up the volume! 🙂
I received three boards from my friend Enrico for repair, this is the first one a bootleg board of Legend of Hero Tonma:
Legend of Hero Tonma is a side scrolling platform game released by Irem in 1989 on his M72 hardware platform.
Powering up the board ends up with this scenario:
… a solid white screen on boot, so i had to start the troubleshooting by inspecting the NEC V30 cpu, an 8086 pin compatible CPU. Here is its pinout taken from its datasheet:
Looking at its control pins with the scope didn’t reveals anything useful to solve the boot issue, so i had to deeper investigate on the address and data bus. Anything seems to be healty except when i put the probe on AD0 pin 16, the signals look weird. So i’m pretty confident and removed the CPU from its socket. Doing this reveals a very loosen socket, so it must be replaced to prevent further issues. Once the CPU has been pulled off, i can spot 2 broken traces under the CPU, one of them goes to/from pin 16. I promptly fixed them:
The CPU socket wasn’t in good condition so i removed it:
… and replaced it with a brand new one:
Now i’m ready for the smoke test, fingers crossed as usually and power feeded to the board. I was greeted with a solid black screen, a sign that something has been changed, but the board is still in not working, but i lightly heard some kind of music coming out from the speakers, pumped up the volume, and yes, the board is running i can coin it up and start a new game, but it still playing blind.
Touching around the board restore temporarly the background and the sprites, so i had to spot the failure. It ends up with a loosen contact on the flat cable connector that join the the PCBs.
So i removed, cleaned and reflowed it on the solder side. I powered up the board again and …
Yeah! It works! Now it’s time to a deep test ingame! 🙂
Here is the second game in the amazing Pang series from Mitchell Corp, i bought it for cheap on ebay few months ago, and it was sold as working … obviusly it didn’t! : )
Notice: This repair took place few months ago, so due to my age, my memories may be inaccurate 🙂
The board has been delivered very bad packaged, by the way there was no apparently damage almost on the top side, but on the bottom side i found a little surprise!
Damn! The seller said the pcb was in very good condition, as you can see, obviusly it wasn’t. Always ask for extra picture before buying! By the way it has been sold as working so why wait? So just power it up!
$#!@$*! This pink screen is a clear sign the board has been committed suicide due to the lack of energy on the battery. This was so obvius because if you also look at the battery and measure its voltage it was less than 1 volt. This confirmed the suicide.
So i must introduce the suicide/desuicide protection of the Capcom boards, because the Michell Pang game series has been developed on Capcom hardware. This kind of protection involves a special CPU with an internal battery backed RAM where decryption keys were stored, so the CPU while running is able to decrypt on the fly the main program code, but if you ran out of battery power you loose your game. If you want to read more about this look at “The Dead Battery Society” site …
The easy solution is to make few modification to the PCB and burn double size decrypted program code EPROMs, but before proceding i must deep test the board for other failures.
So before apply any modification to the board, i remembered i should have a Pang PCB laying around somewhere … it is the 1st chapter of the saga and it’s running on the same hardware, but it was an original board with a decrypted program romset that can be able to run on a standard Z80 CPU or a cleared (suicided) KABUKI CPU. So i was able to deep test the board before apply any modification to it by simply swapping out the EPROMs from the decrypted PANG ad fit them on the SUPER PANG BOARD with a regular Z80 CPU. I double checked the just fitted EPROMs and i powered UP the board and …
… good news and bad news. The good news first, the board is “almost” working, but as we remember it has been sold as “fully working”! And then the bad news … it still need to be healed some way.
The strange colours are probably due to a malfunctioning colour RAM, this seems to be a common issue on these boards. So i looked at them with the scope and spotted a RAM chip with weak signals on its data bus so i was confident and replaced it. Testing the 6116 SRAM confirmed it was damaged.
As you can se, an ugly job has been done in the past to the board.
The light green zone below the removed RAM chip is a consequence of a very bad fix. A previous owner or repairer demaged it by probably using an hot air gun or solder iron at too high temperature, for a long time and in the wrong way. The PCB layers due to the high temperature tried to unstuck and disconnect each others, fortunately this wasn’t happened to this board.
I fitted the proper IC socket and replaced the colour RAM with a compatible one and test the board again …
… much better! I perform some test but the board cannot be coined up, after some investigation, the culprit resides on a little custom SIP module marked CR084, probably a mixed resistor/capacitors array, it was missing a leg!
The IC socket wasn’t soldered yet. So i removed the SIP custom module and fixed it.
Here is the custom SIP module schematics, maybe someone could find them useful …
The previuos owner probably have been tried to fix this issue, with a very bad job, damaging the board and ending with this patches …
During the process some traces has been be damaged and these patch wires have been applied. So i decided to clean this bad job too, so on the other side once cleaned we can see the cutted traces and the missing vias under the 74LS367 chip …
I fixed all the broken traces and vias and placed an ic socket and resoldered both ICs. Finally i cleaned up the board from the solder flux and patch wires … the board now is clean and fixed!
At this point i had to deep investigate and looking for a better desuicide solution.
I found few interesting info posted on a forum by and arcade collector and researcher named Eduardo. I followed some links and finally i spotted his site where he wrote a series of articles on the KABUKI CPU (a custom Z80). He analyzed this security cpu in full detail, and successfully reverse engineered it.
So with this precious and detailed informations i picked up my breadboard fitted my always trusted ARDUINO and i started coding a sketch to revive/reprogram the KABUKI CPU and then the game.
At the time i was working on this board Eduardo have a KABUKI Desuicider Device vailable for sale, but i can’t wait, and i love to do these things by myself. The reprogramming procedure has been very well documented in his youtube video, and the decryption keys can be found on the MAME driver source, so i start coding.
In a couple of hours i have a working release of my Kabuki-Revival! Now some magic took place … and just to make a long story short i ended up with this …
Battery replaced, and CPU decryption keys reprogramming in progress …
Then i checked the original EPROMs dumps and they were all good, i fitted them in the proper sockets. Also the re-secured KABUKI CPU must be seated on its socket with no power failure otherwise the internal security RAM would be cleared again and decryptions keys would be lost. The power were feeded from the onboard battery through the wires with the test clips on the proper CPU pins.
I supplied the power to the board … fingers crossed …
Wow! The desuicide software/procedure seem to have worked! This is a very good news! But the board remained stucked on the RAM check. The board with PANG EPROMs worked well, so the issue should be software related. The SUPER PANG EPROM dumps were good too, so i started looking at the MAME driver source code here.
On the very first rows we can read:
Notes: Super Pang has a protection which involves copying code stored in the EEPROM to RAM and execute it from there. The first time the game is run, you have to keep the player 1 start button pressed until the title screen appears. This forces the game to initialize the EEPROM, otherwise it will not work.
So i keep the player 1 start button pressed ad powered up the boards, fingers crossed again, “RAM OK” test screen, and …
BWOOOOOOOOOOOOOOOOAAAAAAAAAHH! Yes it worked! Now, the Buster brothers can start destroying the bouncing balloons again and save the Earth!
Board fixed and case closed!
All the credits for this “resurrection” goes to Eduardo Cruz, thank to his huge work of reverse engineering this board can keep its original shape.
Arcade Repair Blog