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! : )

superpang-mitchell-pcb-top

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!

superpang-mitchell-bottom-bad

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!

superpang-mitchell-suicide

$#!@$*! 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.

superpang-battery-leakage

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 …

superpang-mitchell-splash

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

test-6116-data-bus-test-error

As you can se, an ugly job has been done in the past to the board.

superpang-mitchell-videoram

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!

superpang-mitchell-cr084

The IC socket wasn’t soldered yet. So i removed the SIP custom module and fixed it.

superpang-mitchell-cr084-fixed

Here is the custom SIP module schematics, maybe someone could find them useful …

Capcom-Mitchell-CR084-schematics

The previuos owner probably have been tried to fix this issue, with a very bad job, damaging the board and ending with this patches …

superpang-mitchell-bottom-bad

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 …

superpang-mitchell-ls367

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!

superpang-mitchell-pcb-bottom

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 …

superpang-mitchell-kabukirevival

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 …

superpang-mitchell-ramok

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 …

superpang-mitchell-gameplay3

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.

rambo3-taito-pcb

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 …

rambo3-taito-pink-screen

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:

rambo3-taito-palette-ram

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:

RAM:
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.

rambo3-taito-palette-ram-6264

I made a quick shot on the MAME source at:

https://github.com/mamedev/mame/blob/master/src/mame/drivers/taito_b.cpp

… 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")
 ADDRESS_MAP_END

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 …

rambo3-taito-ic41-closeup

… and fitted the proper IC socket.

rambo3-taito-pcb-color-ram-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!

rambo3-taito-color-ram-test-fail

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

rambo3-taito-gameplay-3

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:

rambo3-taito-audio-cap-damaged

and two 220uF caps like this …

rambo3-taito-c124-damaged

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

rambo3-taito-color-ram-fixed

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

rambo3-taito-splash-screen

Board fixed. Another case closed! πŸ™‚