Jul 082023
 

Hello,

This is my first repair log on an arcade board, i hope that my text will not be too long and useful to anyone having problems with their own PCB of the same game.

The preambule of this repair :

First thing first, i bought this PCB sold as broken with repair required, paid 130 euros.

On reception :

After pluging the board on my jamma system, i noticed that the board has at least 4 problems to fix.

The first is that i get japanese characters on screen. After reading each eproms and socketed maskroms, i see that FU-05 is from the wrong set. The solution was easy peasy : i bought a 27512 brand new on ebay, and burn the right content from the world set.

Once this first problem is fixed, i get this screen :

This error has already been solved by Porchy, this message appear when the routine that check the presence of the TC4 PAL chip fails. It indicates that the TC4 chip is wrong or toasted. And indeed, by checking with the magical finger touch, the chip is very hot.

So as a solution, i bought a replacement GAL 16V8 on ebay :

Now, the game boot correctly.

Let’s check the next problem to fix :

I see that the graphics are simply flashing constantly on the screen, it’s a mess. The culprit are the sram located here :

Those are TMM2063, and when i passed my finger on them, they were incredibly hot on touch, and the graphics were going crazy on screen. In order to confirm they are shot, i piggyback with new sram replacements bought on ebay : graphics are now fixed !

Let’s remove the buggers :

And install the brand new SRAMs :

Last problem to fix :

I noticed that jump button and start button for PL1 are not working. this board seems to have been connected backwards, so the RC1 custom components are shot. So i contacted Caius, who sold me 4 replacement RC1 pcbs, that i replaced on the board :

It was not easy to remove properly the dead RC1 components, i got 2 traces cut, that i patched after checking them with my multimeter.

Thanks to Caius on a few tips and hints here and there, the PCB is now fully working.

Another board saved ! 😀

Dlfrsilver

(With many thanks to Caius for the help and the replacement parts).

Oct 082022
 

Virtvic handed over his sick Bosconian PCB at a recent event for repair. I’d not seen a Bosconian before so it was interesting to delve into one and it also gave me a chance to redump the PAL chip for the Namco version as the one we have on the PLD Archive is flagged as bad.

On power up the game went through its self test process and displays “RAM OK” and sometimes “ROM OK” then reset itself and the whole process repeats itself.
The game uses 3 x Z80’s all working together which is a little bit of a pain but luckily the MAME debugger makes this a little less painless to aid in fault finding.
In the debugger I could run through the code and see what checks are performed in what order to better narrow down where my issue was.
The memory maps for each CPU are the same apart from the ROM’s for each processor. That means all the RAM is visible to all 3 CPU’s.
CPU 1 does all the RAM tests then it lifts the /RESET pin for the other 2 CPU’s which then do a ROM test for their own ROM’s and stick the result of the ROM test into the shared main RAM.
While this is happening, CPU1 is in a loop constantly checking the RAM area for a value. When the value isnt 0x0 then it either proceeds to boot the game or flags a “ROM #” error depending on which ROM has failed.
Now around 90% of the time the “ROM OK” error didnt show before resetting and I never did see a “ROM #” error.

I pulled all the ROM’s and tested them against MAME but found this to be an undumped version. Overlaying the ROM’s on an existing set I could verify that this version booted fine so they were likely good.
All the CPU’s are socketed and all the pins were also going black so removed them to look for damage and cleaned them up in the process. On replacing the CPU’s the game booted but was very flakey. Messing with the CPU sockets I could get different behaviors so was fairly convinced at this point that the sockets were bad. In hindsight I should have suspected these earlier as they are not the best

I opted to replaced all 3 even though CPU1 socket seemed to be fine.

Next boot up went great and nothing I did would make it crash again

 Posted by at 3:46 pm
Oct 302021
 

I’ve worked on a few of these boards before so I knew straight away that I should be able to access the components side on both PCB’s when it is all screwed together but on this board set the video PCB was showing solder side out.
This doesn’t necessarily cause damage if powered up but its obviously not going to work either.
I switched it back around and when I did I noticed that the crystal on the video PCB was completely missing.

I had a spare 12 MHz crystal so I fitted that. Without that crystal fitted you would get a blank screen.
I tested the game and it started it self test routine but failed on the 63701 with an “Error” and had some graphical issue too.

I had to hope the 63701 wasn’t actually at fault because that is an MCU with an internal ROM which I cannot replace easily.
The way the self test works is the MCU does its own self test and when it is complete it puts a value of 0x84 into the shared RAM at location IC22. The main CPU them reads this value when it is ready to and compares it to 0x84. If this doesn’t match then we get an error.
Looking at the schematics we see where the RAM is

I desoldered the RAM at IC22 and it failed an out of circuit test.

Replacing it cleared this error and allowed the game to boot.

Straight away I could see that sometimes there was a problem with the characters.

When they glitched so did the game title graphic too. It looked like they were being drawn twice overlapping each other. This led me to look for a counter issue, usually a 74LS161.

Following the VPOS signal on the schematics I came to some 74LS161’s. Found this one that has some excess solder on the legs. Touching this while the game was running cleared the issue so I just replaced it and the issue was fixed.

Now on to the remaining sprite issue.

Found 3 dead ROM’s on the video board which sorted all the graphics out when programmed up with the correct data.

 Posted by at 5:24 pm
Sep 292021
 

This version installs in 11J

Why a different version ?

  • Bootlegs have a space at at 14J but no socket, so this version simplifies testing.
  • The version I wrote for 14J won’t boot if 11J is bad, if that version fails to boot then you may have a bad rom at 11J

Diagnostic mode is still available via Player 2 Start + Reset

Differences

  • This version is only used for testing and won’t boot into the game once power up tests are complete.

Download link

gyruss-diag-alternate

Operation Wolf repair log #6

 PCB Repair Logs, Repair Logs  Comments Off on Operation Wolf repair log #6
Jul 252021
 

Got a familiar Operation Wolf PCB that I offered to look at for a friend.
I’ve had this board several time over its life and this new fault was “no sound”. The sound actually stopped working when the owner hit the start button but the game could still be played.
I found the fault really quickly. Starting at the CPU I checked all the signals on the Z80.
Everything was doing what it should be doing except for the /NMI pin (pin 17) which was stuck high all the time.

The NMI is used to signal to the sound CPU to start playing a sound. The signal is generated by the custom PC060 chip nearby on pin 12

I transplanted the custom from my Rainbow Islands PCB to test and the sound all came right back.
Here you can see and hear the /NMI pulse as a new sound plays

So now I’ve confirmed the device at fault what do I do for a replacement. I have no scrap boards with one available. Furrtek has recreated the operation of this device and Caius has made a CPLD replacement that uses this code.
I’ve recapped the sound section and Caius is sending me a replacement but for now I’m happy that this is working again.

 Posted by at 6:24 pm