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