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
Jun 242021
 

See part 1 first.  https://www.jammarcade.net/amiga-a1200-video-repair-part-1/

 

Sockets arrived yesterday and chips arrived a day later, great timing because I’d already had the socket installed by the time the chips arrived.

I’ve decided to remove the backing on one of the sockets, I really didn’t like the idea of trying to get my soldering iron tip in between the backing and pins so I removed it. My plan was to attach some double sided tape or hot glue to the backing/shim then apply it to the MB later, I didn’t want the chip to sit so low in it’s socket in case it needs to come out later.

 

 

After lining up the pins, I had an obvious problem here. The base of the SMD capacitor at C407 in the video decoupling circuit wont allow the socket to sit flush so I decided to remove it, solder the socket in place then add the capacitor later.

 

 

Out with the old and in with the new. Socket soldered into place and connections inspected with a Microscope, then the 10uf capacitor replaced with a brand new one.

 

 

The following day later in the afternoon I received a package containing these. Who sends electro static sensitive devices in a plastic satchel ? More over the devices were clearly de-soldered/pulls yet advertised as new. Will avoid this seller in future.

 

I chose the cleanest of them all ( top right ). I then installed the plastic shim with some double sided tape to the bottom of the socket and installed the chip and tested with success.

 

I now have my blue working again.