Professional software development, amateur BMW tinkering, old arcade game stuff


Capcom Ghosts n Goblins arcade pcb repair

This looked like an easy fix, but ended up taking a very long time indeed…  The fault was obvious – every second scanline of sprites was missing.  As I’ve talked about on previous posts most games use a pair of line buffer circuits – whilst one is written to by the graphics hardware, the other is read out to the screen.  I was able to confirm what one was broken by shorting data pins on the RAM – one corrupted the visible parts of the sprites, the other had no effect at all.  So the one with no effect was the one that wasn’t producing any data to the screen.


Ghosts N Goblins uses a fairly unusual RAM chip for the line buffer – the type is scratched out on the chip but schematics show it is a 20 pin CXK5808P.  This seems quite hard to obtain now-a-days – luckily the board was designed that a regular 6116 slimline RAM could be used instead.  As the logic probe didn’t show any problems with the surrounding IC’s I assumed the RAM was bad and swapped it out for a fresh 6116.  And.. the fault was still there.


More work with the logic probe showed that the LS257 at 7L had pulsing inputs, but the outputs were always high.  That must be the fault right?  Well, it was removed and tested fine, and any replacement acted the same on the board.  This chip at 7L is how sprite data gets into the line buffer circuit.  On the next clock the data goes around to the LS21 at 14L – this is the transparency check – all high inputs indicate it’s a transparent pixel for the sprite that should not be written to line RAM.  Any low indicates it’s an opaque pixel that should be written.


My next approach was to use a dual input oscilloscope – putting one probe on the good line buffer, and the other at the equivalent point on the bad line buffer.  This really just confirmed that everything seemed to be working fine and the problem was no data was getting that far on one buffer only.  Another hint this part of the board was ok was that I could force some of the input pins to GND and correctly saw ‘solid’ color blocks on screen (as opposed to a block with every second line missing).


After a lot of wasted time I went back to the start of the schematics and found there is another place where the sprite data splits into two paths – 11F and 12F split the ‘DE’ bus into ‘DEA’ and ‘DEB’ and it was the LS245 feeding DEB that had failed, with all outputs stuck high.  With this one IC replaced, everything was 100% again.



IMG_8261 IMG_8265 IMG_8267

Leave a Reply