Feb 282019
 

Some time last year I attended an arcade meet of UKVAC user ‘Bonehead’. It was here that I met up with Virtvic who brought along a couple of boards that needed repair. Among them was this Arkanoid 2 which has had a few attempts of repair by a few different people. Because of this it also came with a list of suspected bad components.
Among the list of suspected dead parts was the Z80 Sub CPU. I tested this and it was indeed dead.
After a quick visual inspection I fired it up and got a “SECURITY ERROR” on screen.
The security error is generated from the sub CPU and is all to do with the MCU which is part of the sub CPU section.
I pulled the ROM and it failed in the programmer with an “OVER CURRENT” error. At this point I was getting suspicious and set about checking other chips on the same busses. Everything on the same bus as the sub cpu was dead. The list includes:
Z80
PAL
RAM
ROM
Y2203
MCU
uPD4701

I desoldered and removed them all but I was worried now as the MCU is currently undumped and I wasn’t even sure the game would work even if I replaced all of this.
I fitted a new Z80, RAM, ROM and PAL as I had them on hand. I then set about patching both the main and sub ROM’s in order to bypass security checks and to verify the game worked. It did so I attached the Fluke 9010 to the sub CPU socket and simulated various coin and button presses by writing expected values to the shared RAM.

It was a good start and now I was assured the game would actually work I set about thinking of ways to get around the MCU being dead.
My options were:
-Replace the MCU with a modern one programmed to act similar
-Program my own 8741 from scratch
-Create a PCB to fit in the socket to make necessary connections and bypass certain checks in ROM

I started off attempting to replace it with a more modern ATMEGA MCU. I made up a small adapter PCB which would match the pinout of the 8042.
This didn’t work well at all as the ATMEGA doesn’t have dedicated chip selected lines or any of the other control lines I needed. As a result i scrapped the attempt and decided to start learning 8741 assembly.
I spent quite some time learning the ropes on this one dealing with all its limitations and pouring over the MAME source which simulates this MCU. It really was a great experience for me and I enjoyed it a lot.
Phil Bennett gave me some assistance in setting up a MAME environment to use a real MCU file rather than the simulation and I finally ended up with something that seemed to allow me to boot the game.
I went to test my first attempt but realised that I would need some kind of debounce routine for the coin up processing.

I continued working on the MCU features in the background and started to look at getting hold of the missing chips.
I needed a new Y2203. Without this I have no sound and the game also boots straight into test mode as the Y2203 also processes the DIP’s. For now I was patching this check out too.
Getting the Y2203 was fairly easy and I found one on a scrap board.
I eventually got some 8741 MCU’s for a decent price from eBay and was about ready to test for the first time

Success! Coin up was implemented and buttons were implemented too.
The sticking point was the NEC uPD4701. This handles the spinner inputs and I couldn’t find one anywhere.
Hammy was going to send me one with the next batch of things to dump but Caius came to my rescue sooner and sent me one from a Cabal PCB (thank you Caius and Hammy).
I don’t have any spinners to test controls so I hooked up an Arduino to simulate left and right movement.

From my point of view that’s this PCB fully working. Its taken me months to get to this point but its also been one of the most satisfying things I’ve done in this hobby.

There are some ‘features’ missing from my MCU replacement but I don’t think its anything disastrous. The game no longer caps at 9 credits and the tilt signal doesn’t work within the test mode. There is probably other stuff too but I can work on those if they become a problem. Once it has been tested then I will release it.

 Posted by at 9:07 pm

Black Tiger repair log #4

 PCB Repair Logs, Repair Logs  Comments Off on Black Tiger repair log #4
Feb 282019
 

I got the same Black Tiger bootleg board back as in my repair log #3.

The sound had stopped working completely.
I did all the usual visual checks and reseating where I could but no joy.
I probed the Z80 CPU and found following a brief flicker at power on the /HALT pin was always asserted. I pulled the ROM and checked it in my programmer but it came back as good. There is nothing in the way of buffering in between the CPU and ROM.
I decided the quickest way to see what was happening here was to attach the logic analyser to the CPU address bus with the trigger set to the /M1 signal.

From here I could see that it started off good but failed when returning from a call. As the return address is pulled from the stack I decided to remove the RAM and test it. This turned out to be faulty reporting that bit 3 had become disconnected.
Replacing the RAM brought the sound back.

 Posted by at 8:42 am

Crude Buster repair log #1

 PCB Repair Logs  Comments Off on Crude Buster repair log #1
Feb 172019
 

Got from Portugal this Crude Buster PCB (also known as Two Crude outside Japan), an unusual and underrated beat ’em up developed and published by Data East in 1991:

Board simply booted to a white static screen:

Blank screen on boot.

The first thing I did was to check the main CPU (a custom 68000 marked ’59’) circuit and I found that both WORK RAMs (two 8K x 8-bit devices) has stuck data lines whereas address was correctly toggling :

The two RAMs are Toshiba TMM2063, we all know they are very prone to failure:

TMM2063 WORK RAMs

When I piggybacked them and got some errors (related to code execution) on screen:

Hence I decided to remove the chips:

WORK RAMs removed

Although RAMs were both tested fine in my programmer I replaced them and I got the board booting. Game was fully playable but some sound samples were wrong:

Samples are stored in two 1Mbit EPROMs and played by two OKI MSM6295 PCM chips:

Sound circuit overview

The two EPROMs were dumped as good so I fired up my audio probe and started to “listen” to output (pin 36) of the internal DAC of both MSM6295.The samples came out already corrupted from one :

I was about to replace the OKI MSM6295 when I noticed some solder residues on a couple of pins.I magnified the area with a microscope and found a solder bridge that shorted two address lines (pin 20 and 21)

Soder bridge on MSM6295

I removed the bridge and sound was fully restored as well as board 100% fixed.

 Posted by at 8:51 pm

G.I. Joe repair log #3

 PCB Repair Logs  Comments Off on G.I. Joe repair log #3
Feb 162019
 

Yet another G.I. Joe PCB on the bench from the five faulty ones received from Portugal some time ago :

Board was in good conditions but someone harvested parts from it.In particular the thee 6264 SRAM (part of tilemap circuit) were missing:

As well as the sound ROM @7C and the 62256 SRAM @2D always in audio circuit :

I installed the components and sockets too where needed.When I powered the board up I was greeted by this screen filled with letters :

Usually this kind of issue on Konami boards means there is some trouble in the tilemap generation circuit so I made a visual inspection and found a couple of severed traces on solder side:

Finally the board executed the self-test but two devices were reported as bad :

The one @2D was the 62256 RAM that was missing while @3E lies the custom ASIC ‘054539’ (which is a PCM sound generator ), both ICs share same address/data bus.

At a closer inspection some pins of the custom were lifted so I promptly refowed them.The board successfully booted into game with no further issue.

Yes, yet another G.I. Joe PCB fixed (hopefully not the last one…)!

 Posted by at 6:55 pm

Mortal Kombat (original and bootleg PCB) double repair log

 PCB Repair Logs  Comments Off on Mortal Kombat (original and bootleg PCB) double repair log
Feb 052019
 

Got from USA an original Mortal Kombat PCB set complete with its sound board:

When I powered the board up the self-test reported two bad devices @U5 and U23:

P.O.S.T results

Then it booted into game but colors were completely wrong:

The two presumed bad devices are the color RAMs (Sony CXK5863 so 8K x 8-bit, pin-to-pin compatible with the more common 6264)

Color RAMs

Probing them revealed that pin 27 (Read/Write enable line) of both was stuck high:

This input signal is labeled on schematics as ‘-CRWR’ :

It comes from pin 22 of a 24 pin IC @U8:

EP600 ELPD color RAM control

The IC was faulty and needed to be replaced.At first glance I thought it was a simple PAL/GAL but actually it turned out to be an Altera E600 EPLD (so still a programmable logic device but something more complex with two clock inputs providing sequential logic too ).I had no chance to dump or reverse it but only to look for a donor board.Luckily I was sent another original Mortal Kombat PCB completely dead which I took the part from.Board was then fixed :

The bootleg I received for repair was the Yawdim one with no Midway logo on title screen :

It was fully playable but some backgrounds graphics were wrong :

As usual I did a visual inspection of PCB and found on solder side a scratch that apparently had severed a trace:

The involved area was the one populated by some 64K x 4-bit dynamic RAM so this was relevant to the kind of fault :

Checking with my multimeter confirmed the trace was really broken so I patched it, this restored background graphics and fixed the board:

Double repair accomplished.

 Posted by at 7:16 pm