Extermination repair log and ‘X2-003’ – ‘RO-012’ reproduction

 PCB Repair Logs, Reproductions  Comments Off on Extermination repair log and ‘X2-003’ – ‘RO-012’ reproduction
Mar 112019
 

Some time ago I bought a lot of original faulty boards, there was among them a Taito PCB which at first gance I could not identify:

I could not power it up because there was a dead short between GROUND and +5V :

So I dumped some ROMs and it turned out to be Extermination, a vertical shoot’em up game (that runs on “The New Zealand Story” hardware) released by Taito in 1987.Someone previously tried to troubleshoot the board and cut one terminal of a zener diode thinking it was shorted but this was for +12V line protection whereas there is another zener diode to protect +5V which was actually bad causing the short to GROUND:

Once replaced the zener diode and cleared the short I powered the board up and it booted into game but sound was missing and colors were wrong with a dominant blue :

A blueish image means the RED color is missing or has some troubles.This was confirmed by the logic probe, the signal was indeed stuck low :

I could trace the JAMMA edge connector pin of RED back to a SIL component marked ‘RO-012’, a typical R/2R resistor ladder used as RGB DAC (one for each color).A closer inspection revealed the part was mounted backwards:

 

Reinstalling it with right orientation restored the RED color but image was now purplish :

This meant the GREEN color had some troubles.I located the relevant ‘RO-012’ DAC near the sound amplifier and found that some pins were shorted by a solder bridge:

Removing the bridge finally restored the correct colors :

Now the lack of audio.From signs on solder side I noticed someone previously reworked the sound section replacing the amplifier (an Hitachi HA1388) and potentiometer (and perhaps also capacitors)

Checking the +12V  confirmed this voltage was present on board but not on amplifier when I put the black probe of my multimeter on the two GROUND pins of the HA1388 (pin 4 and 9).At the end it turned out that who replaced the amplifier and potentiometer managed to lose their GROUND connection likely ripping off the rivets from the holes (power pins are always harder to desolder due to presence of internal planes).I restored the connections in this way :

Sound was back again.Board 100% fixed and job done.Before archiving this repair I took the chance to see if some parts (simple ones, not digital ASICs) were worth to be reproduced.I chose the aforementioned ‘RO-012’:

And the ‘X2-003’ :

The first, as said above, is an R/2R resistor ladder acting as RGB DAC, the latter is a capacitors/resistors array used for inputs but, unlike all the others, comes in a DIP16 ceramic package hence quite fragile.Reproducing them was straightforward :

 Posted by at 8:53 pm

Defender repair log #3

 PCB Repair Logs  Comments Off on Defender repair log #3
Mar 112019
 

Again my Defender boardset had developed another fault.

I had already repaired here:

Defender repair log #1

and here:

Defender repair log #2

This time after the screen “Initial tests indicate all unit OK” it rebooted in an endless loop.

The diagnostic LED were flashing two times correctly before resetting, so I thought it was the ribbon cable.

After spraying and moving the cable , game still reset itself after the initial test but after a while it didn’t produce anymore the classic startup sound and all the LED were always stuck lit.

The 6821 PIA on the romboard should send an \IRQ signal to the main CPU after the ram test but the signal was missing, that’s why the watchdog kicked.

Also the 4 LED stuck lit is an evidence that the PIA died.

It’s known to be not very reliable, so I decided to desolder it , put a socket and test the only one PIA I had for spare which luckily made Defender to boot again.

Game was  fixed without any problems ( for the moment )

Pac-Mania repair log #3

 PCB Repair Logs  Comments Off on Pac-Mania repair log #3
Mar 092019
 

Got for repair from USA this Pac-Mania PCB on Namco Sytem 1 hardware.System is made of a larger ROM board:

And a smaller CPU board:

It booted to an ‘EEPROM ERROR’ message screen followed by some digits:

The EEPROM is a 2816 (2k x 8-bit) device located on CPU board:

I didn’t try to replace or swap this EEPROM since I knew it was not the cause of error.From my experience this is due to another IC that goes bad very often.I’m speaking bout the custom ’64A1′ located on ROM board @M4.Mine, indeed, was marked with a pencil as ‘BAD CHIP’ :

Technically the custom ’64A1′ is an HD63701 MCU in disguise with the exception of two custom opcodes.I already explained in a past post of mine how to replace it with a standard HD63701 MCU :

Namco System 1 custom ’64A1′ replacement

It’s what I did and this was enough to fix the board completely.Job done.

 Posted by at 7:36 pm

Sunset Riders repair log #9

 PCB Repair Logs  Comments Off on Sunset Riders repair log #9
Mar 032019
 

Got from USA some faulty PCBs for repair, there was among them a Sunset Riders by Konami :

Owner told me he bought the board as working but actually it lacked of sprites when powered it up.I got, instead, different results.Sometimes the board passed the POST but then stayed on a static striped screen:

Other times it failed the self-test reported a bad device @12F:

The device in question is one of the two 6264 WORK RAM :

Probing this RAM with a scope revealed unhealthy signals on some data lines, here’s a comparison with good ones on the left of the picture below  :

I desoldered the chip, it failed the out-of-circuit testing of my EPROM programmer:

I replaced it and board finally booted into game but, as expected, sprites were displayed only half or totally missing:

I launched a MASK ROMs check which reported no errors :

But checking the two sprites MASK ROMs revealed the address lines were all stuck LOW, no activity :

Like in many other Konami PCBs all the sprites generation circuit is handled by two custom ASICs, on this board there is the ‘053245’ which generates the address for the MASK ROMs and the ‘053244’ which processes the data:

The first I tought was to replace the ‘053245’ which is what I did :

But invain because nothing changed.Then I remembered a past repair of a same board where the lack of sprites were due to a missing connection of the custom ‘054358’:

Sunset Riders repair log #7

Checking with a multimeter it seems this custom provides interface between busses of 68000 main CPU and the custom ASICs sprites generators.Having a spare I decided to replace it:

Sprites came back:

Board fixed and end of job.

 Posted by at 4:28 pm
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