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
Feb 062019
 

Some days ago I wanted to test some RAM chips from an arcade PCB using my B&K Precision 560A tester :

B&K precision 560A IC tester

For the uninitiated this piece of equipment allow you to do out-of-circuit and in-circuit testing of many ICs like TTLs,RAMs and ROMs thanks to an extensive internal IC library.I often use it during my repairs but in that day it suddenly died, no sign of life, nothing came up on display when I powered it up.For first I checked the main fuse and it was good so I decided to open the unit:

Its internals

Having no schematics I started my troubleshooting from upstream checking the big transformer just after the AC input, voltages were present on its secondary coil.Following the path I figured out the AC voltages are rectified by a circuit on one of the PCBs.In particular the rectified +12V is then regulated by a couple of ‘LAS1605’ fixed +5V voltage regulators (in TO-3 package) mounted on a big heatsink for providing +5V to the circuitries on the other boards:

Two LAS1605 fixed +5V voltage regulators in TO-3 package

I probed the inputs of both and +12V was present:

As well as +5V on the output of one regulator:

But the other one was giving only +1.706V on its output, too few for correct functionality of the logics on PCB:

I looked online for buying a ‘LAS1605’ +5V voltage regulator or a compatible one but found only few at not really cheap price.Then, as a last resort, I asked my local electronics shop, they surpringsly had in stock some TO-3 ‘MC7805CK’ which is a perfect drop-in replacement (although it can deliver up to 1.5A output current against the 2A of the ‘LAS1605’ but this is not really an issue since I don’t think the tester can draw more than 1.5A during normal operation)

MC7805CK used as replacement

I pulled out the suspicious part:

The culprit in all its loneliness…

I swapped the spare in and was welcomed by this :

BK560A lives again!

My BK560A rised from its grave! Not too bad for a 2-euro repair! (as much as the replacement part costed…)

 Posted by at 9:30 pm