Jun 042018

Was asked by a friend to repair his Sunset Riders.

When starting up the PCB, it was stuck in something resembling a watchdog fault.

But I’ve been working on Sunset Riders before and this didn’t seem like an ordinary watchdog. I felt that it went a little bit longer in the startup sequence before crashing.

The board was a bit dirty but I started with the usual:

  • Checking CPU signals like clock, reset and halt
  • Verifying the program ROMs
  • Checking the program RAM for odd signals

All looked ok, but then I found this at the 051550 reset signal generator.

Pin 1 on the 051550 looked like a cold solder joint.

Pin 1 is the clock signal input pin on this IC and without that input, I can understand that the game doesn’t boot up properly. Gave that pin a dab of solder

And booted up the game

Board fixed without any other issues 🙂

Jun 022018

Although I grew up with a Commodore 64, I have a soft spot for Atari 8 bit machines. My mission in life is to save them all from going into landfill.

I spotted this grimy Atari 800XL on Gumtree very recently as untested, it came with an Atariwriter Word Processor Cartridge. I met the friendly chap selling the item and we did the exchange for the computer at Town Hall steps, which is a popular meeting place in Sydney.

Taking the machine apart, I was happy to see that the machine was fully socketed and that the PCB was in excellent condition despite it needing a good clean. Actually, I was expecting a fully socketed machine because it was made in Hong Kong just like my 600xl was. Another pleasant surprise was the brand of DRAMs used ( OKI ) instead of the mT variety, which have a bad reputation for reliability and were used extensively in the Atari 8 bit and C64 line.

I had a close friend of mine over after work and we went through the troubleshooting together. Unfortunately, not much happens after power it up. A black screen most of the time and sometimes an intermittent picture, obviously this is a sync issue.

Sometimes I manage to get a screen that looks like this. This is a good sign. At least I know the CPU, ROMs and DRAMs are working to some extent to produce this screen.


Luckily I  have a fully socketed 65XE to swap parts to and from.  I also tried a known semi good GTIA which was bad on one output only but produced a nice clean picture in a working machine. The GTIA is responsible for generating the luminance, color and csync signals to produce an image to the screen.

Replacing it doesn’t change a single thing so I consult the schematics, the signals go directly to a hex non inverting buffer ( 4050 ) so I switch my logic probe to the CMOS setting and start probing the chip. Output 6 ( lum0 ) is good, lum1, 2 and 3 were all bad and all outputs were floating. I wanted to check the CYSNC line (  composite sync ) and that was also floating ( no signal at all  ).

I short the input and output pins of the 4050 ( pins 14 & 15 ) with my logic probe briefly which restores the picture to the screen.

Replacing the chip completes the job!

Now onto the next challenge, cleaning the motherboard and case!

Jun 012018

Received from Germany this faulty DonPachi PCB for repair:

Board played almost ‘blind’, most of graphics was missing, only some corrupted text was visible:

According to MAME source there are three layers of graphics:

ROM_REGION( 0x100000, “layer0”, 0 ) /* Layer 0 */
ROM_LOAD( “atdp.u54”, 0x000000, 0x100000, CRC(6bda6b66) SHA1(6472e6706505bac17484fb8bf4e8922ced4adf63) )

ROM_REGION( 0x100000, “layer1”, 0 ) /* Layer 1 */
ROM_LOAD( “atdp.u57”, 0x000000, 0x100000, CRC(0a0e72b9) SHA1(997e8253777e7acca5a1c0c4026e78eecc122d5d) )

ROM_REGION( 0x040000, “layer2”, 0 ) /* Text / Character Layer */
ROM_LOAD( “text.u58”, 0x000000, 0x040000, CRC(5dba06e7) SHA1(f9dab7f6c732a683fddb4cae090a875b3962332b) )

I translated this info on hardware and figured out the relevant circuit of each layer:

Each circuit consists in a QFP custom ASIC (maked ’38’) which addresses an 8Mbit MASK ROM (or a 2Mbit EPROM for the text layer) reading back data that then are written to two 8K x 8-bit static RAMs.After succesfully  checked connection between ASIC, ROM and RAMs my suspicions fell on the 8k x 8-bit SRAMs, they were all manufactured by Sanyo so in my experience not a great guarantee of reliability.Probing the ones @U50 and U51 (which lie in the ‘layer 0’ circuit) revealed weak or stuck signals on many data lines:

I removed both:

Actually only the one @U51 failed the out-of-circuit testing:

Now all graphics were visibile.Backgrounds and sprites were fine but text was corrupted throwing garbage over the screen :

The ‘layer 2’ identified in MAME source as ‘ Text / Character Layer’ was obvioulsy the involved one.Checking the two Sanyo 8K x 8-bit SRAMs @U55 and U56 revealed again weak signals on data lines:

I removed them and installed machine sockets:

Actually both RAM chips successfully passed the out-of-circuit testing of my different programmers.Anyway, replacing them fixed completely the graphics:

But sound was horribly scratchy and corrupted as you can hear in the above video.Here it comes again to help my audio probe for checking the relevant circutit:

“Listening” to various points revealed the sound was clear on the analog output of the two OKI MSM6295 and still good on outputs of the LM324 OP-AMP and input of the LA4460 amplifer.It was fine too on one output (pin 7) of the LA4460 amplifier:


But corrupted on the other output (pin 9)

I ruled out all electrolytic capacitors checking them in-circuit with my ESR meter (bad ones can affect sound in this way) so I decided to remove the LA4460 amplifer:

Put back a good one and some thermal compound for a better heat dissipation:

This restored a crystal-clear sound.Mission DonPachi accomplished!

 Posted by at 9:10 pm
Jun 012018

I recently borrowed this Arkanoid PCB from NES4Life. I wanted it as part of a project to recreate the 28 pin custom chip that found on this, Darius and probably a couple of other Taito games of the same era.
He kindly loaned me this but knew it had issues so I agreed to look at this one rather than poke around on one of his workers.

First up the game would not boot, just watchdogged.
Using the schematics available in the download section I could easily track down a stuck bit on the data bus.

IC42 was to blame for this. Replacing it let the game boot but with all new issues.

You can see the game has booted straight into test mode and the colours are messed up.
One of the DIP switches is for test mode and the DIP’s are handled by the YM2149 chip. Looking at the databus when this chip is supposed to be active showed all data bits stuck.
Replacing this chip let the game boot.

Colours are still messed up so lets look into that. I chose to start at the 3 colour PROM’s

Probing the address pins revealed most were floating. Going backwards we come to a 74LS298 at location IC38. Replacing this then gave me this:

You can see now the screen is doubled up.
The graphics are contained within 3 EPROM’s. These EPROM’s are all addressed by 74LS298 chips before outputting their data to the custom bit shifters.
Checking these 298’s showed some stuck output pins on IC50.

Replacing this gave me a more normal screen but the bat sprite is being drawn half way up the screen and is doubled up.

Horizontal position has its own bus on the schematics

I confirmed the operation of the 74LS157’s first so moved onto the 74LS669’s. I’ve not dealt with these before and had none to hand either but I was fairly certain id narrowed it down to IC65 so I ordered some new ones up, desoldered the old one and tested it. Thankfully it failed.

Got the new chips a couple of days later and fitted.

Just the double bat issue to go.
The schematics also have a bus identified as OBJ which Im taking stands for Object. It made sense to me that the issue was somewhere along the same path as the previous positioning fault so armed with my best guess going from schematics I carried on following the path first of all checking the other 74LS669. This appeared to be OK and the RAM didn’t have any unusual looking signals on so I carried on. After these there is a 74LS374 on the OBJ bus. Probing the outputs of this found a single stuck bit. Replacing this gave me a seemingly fully operation game.
I cannot check the spinner inputs but all the sounds, DIP’s and regular inputs are working.

 Posted by at 7:44 pm
May 252018

I’ve been sent from Germany some faulty PCBs for repair.There were among them two PCBs manufactured by Toaplan :

  • Knuckle Bash


  • Fixeight:

The first was throwing a “A VRAM ERR” message on boot:

The video RAMs (VRAM stands for this) are two 8k x 8-bit static RAM located @42 and U51:

They are accessed by the QFP ASIC marked ‘GP9001’ which is the graphics controller of the system:

For first I did a visual inspection of it and found some pins not really firm (common issue on QFP with this fine pitch)

I reflowed them but this didn’t led to any improvement so I moved to check the VIDEO RAM ICs and found weak signal on data lines:

I pulled both RAMs, only the one @U42 failed the out-of-circuit testing:

The board successfully booted into game now but the colors were wrong, they were “bleeding”:

This is another common issue on this board so I knew where to look exactly.The data bits from the two 6116 (2K x 8-bit) palette SRAMs are latched by two 74HC273:

Probing with a scope the 74HC273 @U9 revealed weak signal on outputs (inputs on the left of the below snapshot, outputs on the right)

I pulled the IC:

It actually passed the out-of-circuit testing on all my programmers so I think IC was not really bad but it had altered voltage thresholds.Anyway, I replaced it and this fixed the board completely.



Now the FixEight troubleshooting.

Board gave me a steady black screen.This board uses the GP9001 graphic controller too:

Found some lifted pins on it:

I reflowed them as well as replaced the main program code 4Mbit EPROM since it had some rebuilt pins that gave me trouble when dumping it:

But still no boot.But I noticed that pressing  the PAL16V8 @U51 :

produced a couple of different RAM error messages on screen:

Solderside of the PAL socket had some dry joints:

So I replaced it and finally the board initialized but it quickly went straight into SERVICE mode and then reset in an endless loop :


From a still image I noticed that some inputs were stuck in I/O check:

The inputs are handled by the custom ‘HK-1000’, you can find more info about it in a past article from mine:

Toaplan ‘HK-1000’ reproduction

On my PCB a replacement board had been used in place of the original part:

Some inputs of a 74LS240 on this replacement board were shorted to ground.Instead of repairing it, I opted for a reproduction of mine (the blue jumper wire was already there to patch a trace previoulsy broken during the removal of the original ‘HK-1000’)

Finally the board booted into game with no further issues.Toplan double repair log accomplished.

 Posted by at 9:24 pm