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.
A lot of boards are awaiting on the “to be repaired” stash, today the random pick is one of my favourite arcade system ever … an SNK MVS board! So i moved it from the stash to my bench for a repair. A clean MV2 dual slot board :
The usual visual inspection, reveals the BIOS IC (on the red square) is missing, the battery seems to be in good condition and no damage has been done due to its acid leakage.
The overall condition is good enough to perform a smoke test, so i plugged in the JAMMA harness and powered up my supergun, finger crossed and i’m been greeted with this error:
A video RAM error is a common issue on this hardware, the error address is not zero boundary, so the culprit should be a damaged video ram chip. The self test program is expecting a 5555 hex value (101010101010101 binary pattern) but the lower half memory chip probably reply with wrong and garbage data, as you can see on the READ lower half value (hex FF instead of 55) and the random characters on the screen.
So i’m going to replace it. On my spare parts i found a 32Kb SHARP LH52B256 a little bit faster than the original TOSHIBA ic, 70ns instead of 85ns, but it should do the job in the same way, it’s the one in the yellow box below:
At this time i decided to give the board a try and i powered it up again, no more garbage on the screen, but there are still strange video errors (picture missing sorry) tipically due to a problem with NeoGeo FAST video RAM. The Sony CXK5814 ICs, a 6116 2Kb standard compatible static RAM, over the ages are very prone to failure, so i replaced both and fitting the proper ic socket, you can see them in the light blue box below:
I replaced the FAST video RAM chips and powered up the board again … yeah board fixed!
Now it’s time to do some deeper testings … 🙂
The board runs fine, the I/O controls, the video and audio sections now are fully working. After the “testings”, i made a minor fix to prevent further damage due to battery leakage, so i removed the original Ni-Mh battery and the 470ohm resistor to deactivate the charging circuit:
… and fitted a CR2032 battery socket on the rear side for easy swapping and maintenance, once the board will be closed with its metallic case.