Super Pang – Mitchell

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!


$#[email protected]$*! 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 …

Pang - Mitchell

… 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.

Neo Geo MVS MV2 – SNK #1

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 :

SNK - NeoGeo MVS MV2 - #1

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.

SNK - NeoGeo MVS MV2 - #1

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:

SNK - NeoGeo MVS MV2 - #1

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:

SNK - NeoGeo MVS MV2 - #1

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:

SNK - NeoGeo MVS MV2 - #1

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 …  πŸ™‚

SNK - NeoGeo MVS MV2 - #1

SNK - NeoGeo MVS MV2 - #1

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:

SNK - NeoGeo MVS MV2 - #1

… 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.

SNK - NeoGeo MVS MV2 - #1

Board fixed. Another case closed! πŸ™‚

Rambo 3 – Taito

Just taken a random pick from my “to be repaired” stash, an original TAITO B-SYSTEM arcade board.


The sticker il no more readable, but the eproms labels are marked B93. According on the lists found over the internet this should be a RAMBO 3 board.

The usual visual inspection don’t reveal anything strange, the board is good condition so i’m ready for the smoke test. Jamma harness connected and power feeded, finger crossed and …


I’m greeted with this amazing “hello kitty-ish” pink screen! I think John Rambo shouldn’t be proud of! So before i’ll found him in front of my door knocking and armed, i must hurry and fix the board as soon as possible. πŸ™‚

I powered off the board and i checked if some ICs were getting hot, but everything seems to be ok, but we know for sure that almost one “guy” shouldn’t do the right job on the board. Now i’m ready for a second run and powered on the board constantly checking it. The board seem stone dead, and in this condition the right thing is starting troubleshooting the main CPU looking for good control signals, time passes and no signs of life come from the board. I try to feed a credit to the board and surprisingly i was greeted with the right sound effect! This is a good news so probably the board is playing blind, i checked the dip switches and i tried to activate the attact demo sound, i did a power cycle of the board, the usual pink screen came out but now music and sound effetcs seems to be played in the right way.

So the issue must involve the graphic section of the board. My one cent bet is for the palette RAM, so i put my finger over it, it’s marked IC41 and it is a 2Kb 6116 compatible SRAM, the one with the yellow border below:


Its data and address lines are directly connected to the TAITO Custom IC marked TC0260DAR, the one light blue bordered, the palette generator chip i think, unfortunately no information neither schematics or pinout can be found on the net about this “guy”.

By the way according to the technical specifications the palette RAM on a B-SYSTEM board shoud be 8Kb, a 6264 standard SRAM, but on Rambo 3 board only a 2Kb palette RAM is present, allowing this way a less color depth.

Here’s a brief summary taken from wikipedia:

68000 main RAM: 32 KB
68000 video RAM: 46 KB
(8 KB palette, 36 KB tilemaps, 2 KB scrolling)
Video resolution:
320×224 to 512×256 pixels
Color palette depth:
4096 (12-bit RGB), or 32,768 (15-bit RGB)

Looking at this picture we can see the extra unused pins on the left of the palette RAM @IC41 allowing the fitting of a 8Kb palette SRAM as expected by the “standard” base design.


I made a quick shot on the MAME source at:

… here we can found the Rambo 3 address map:

static ADDRESS_MAP_START (rambo3_map, AS_PROGRAM, 16, taitob_state)
 AM_RANGE(0x000000, 0x07ffff) AM_ROM
 AM_RANGE(0x200000, 0x200001) AM_READNOP AM_DEVWRITE8("tc0140syt", tc0140syt_device, master_port_w, 0xff00)
 AM_RANGE(0x200002, 0x200003) AM_DEVREADWRITE8("tc0140syt", tc0140syt_device, master_comm_r, master_comm_w, 0xff00)
 TC0180VCU_MEMRW( 0x400000 )
 AM_RANGE(0x600000, 0x60000f) AM_DEVREADWRITE8("tc0220ioc", tc0220ioc_device, read, write, 0xff00)
 AM_RANGE(0x600010, 0x600011) AM_READ(tracky1_lo_r) /*player 1*/
 AM_RANGE(0x600012, 0x600013) AM_READ(tracky1_hi_r)
 AM_RANGE(0x600014, 0x600015) AM_READ(trackx1_lo_r)
 AM_RANGE(0x600016, 0x600017) AM_READ(trackx1_hi_r)
 AM_RANGE(0x600018, 0x600019) AM_READ(tracky2_lo_r) /*player 2*/
 AM_RANGE(0x60001a, 0x60001b) AM_READ(tracky2_hi_r)
 AM_RANGE(0x60001c, 0x60001d) AM_READ(trackx2_lo_r)
 AM_RANGE(0x60001e, 0x60001f) AM_READ(trackx2_hi_r)
 AM_RANGE(0x800000, 0x803fff) AM_RAM /* Main RAM */
 AM_RANGE(0xa00000, 0xa01fff) AM_RAM_DEVWRITE("palette", palette_device, write) AM_SHARE("palette")

as we can see, according to the MAME source, 8Kb for the palette RAM at range (0xa00000, 0xa01fff) are addressed, exactly 0x1fff hex bytes or 8192 bytes. Maybe should be something wrong here … it needs further investigations.

… but let’s take a step backward and bring the focus back to our not working board and its issue.

Probing the palette RAM address lines with the scope reveals they seems to be in good working order and an apparent regular activity seems to be present, also the control signals seems to be in good shape, but when i checked the data signals i think that something wrong were going on, too poor activity for a palette RAM.

This suspect is enough for me, and i start to replace it, i removed the old ram, i tried my best for a neat job …


… and fitted the proper IC socket.


before proceding, i tested the old RAM on the IC tester, and as you can see it was damaged! The RAM data bus miss the test … Yeah!


I replaced the palette RAM, and fed power to the board again, and …


GOTCHA! It worked! So i could proceed fixing minor issues over the PCB as these damaged, loosen or totally missed capacitors, one 1000uF cap on the 12v rail in the audio section:


and two 220uF caps like this …


Both replaced with their equivalent ones in a bloody-red color! Much better!


I think also John Rambo should be proud of them … and now he’s ready to kill all the enemies!


Board fixed. Another case closed! πŸ™‚

Golden Axe – Sega

This is one of my favourite arcade games ever!

I’ve got this GOLDEN AXE PCB a SEGA System16b board on the bench from a friend of mine, Daniele,  for a repair. The board boot fine, the game starts in the right way, but there is no audio at all.

This should be a quick fix, i think. This is the picture of the board :


The PCB is in very good conditions and no scratches were found on the solder side. So it’s the time to get hands  dirty and take a deeper look at the audio section of the board.

First of all i noticed the C18 cap is missing, but according to the System16b schematics i found on the net, the missing cap shouldn’t be involved in the issue, the board il totally silent.


We can look at the missing cap on the red circle, this picture is taken from the sega System16b schematics:


… and this one is taken from the IC datasheet:


For a first quick and dirty test of the audio power amp, a Fujitsu-MB3735, i used an old school method and an absolute high-tech probe … a finger! : )
Adding some interference and extra capacitance the amp should oscillate abnormally and should reply with the classic “hum” noise. This will tell us that the amp may do it’s job, and it seems working.

So we can take a deeper look at the audio chain of the board:


So we can go backward through the audio circuit in the preamp section a quad op-amp marked NEC uPC804C, it’s an equivalent of a better known TL084. Probing it with the scope i found that it was totally silent both inputs and outputs. The inputs are feeded by a Yamaha YM3012 DAC, a digital analog converter, obviusly all the output stages were silent but there is an apparently activity on its inputs. The serial data input pattern looked at the scope seem to be too regular, it should change in some way when differents sounds were played. The input pins of the DAC are connected to the output pins of the FM sound generator chip, a Yamaha YM2151. They are a classic audio ICs tandem, found on several arcade boards.

Also the NEC uPD7751 ADPCM Decoder was silent too …

My suspect is that the CPU in some way should misdriving the sound generators ICs. Before probing around address and data lines on the PCB, we can notice that on the SEGA System16b boards the audio CPU, a classic Zilog Z80, is mounted on a socket so we can easily test if the culprit relies on it by simply swapping it. Using a good Z80 didn’t solve the audio issue, and testing the mounted Z80 reveals it was good, so we need further investigations.

It’s time to take a look at the CPU signals, the clock signal was good, CPU control signals (RESET, HALT, WAIT, …) seemed to be healty, system control signals reveals the CPU is stucked in a READ state no WRITE activity on the RAM, this should be strange in a good working mode. So i started poking with the scope over the address and data lines, it reveals a lot of activity and the displayed patterns seemed to be the usual ones.

But when pinned the probe on the D3 line …


… The yellow pattern is a good D0 line, the green pattern is (inverted for a better reading) the D3 line and it is stuck high. Checking and beeping around the D3 signal for continuity traces testing between CPU, 6116 SRAM, an the FM chip reveals they were all ok. The test points are the ones with the red dot on the upper image of the audio section.

So only few IC remain to test on the shared data bus, the EPROMs. They are placed on a daughter board attached to the mainboard with four connectors. I started from the Z80 sound EPROM a standard 27c256 marked EPR12390, according to the datasheet the D3 signal should be on PIN 15.


The digital multimeter reported no continuity between CPU and EPROM on D3, maybe they can be wired in a different way so i check D3 on the CPU against all the pins of the EPROM data bus, but no audible beep can be heard. I checked the whole data bus and it was ok and only D3 was missing. So this should be the culprit, a broken trace, maybe on the connector, between EPROM and CPU data bus on D3 signal.

I pulled out the EPROM for further investingation and i spotted this:


… so i lifted the pin, reseated the EPROM on the socket and ready for the “smoke test” … and it worked! I was greeted with the usual Golden Axe audio effects and voices, and the well known music theme.

The damaged pin prevent the CPU bootstrapping and executing the right program code, probably leaving it in a endless loop of trash bits with wrong data.

It’s time to replace the missing C18 cap to completely fix the board. Despite of the lenght of this post, it was a few minutes easy fix.


Now, Daniele should be happy! : )
Case Closed.