Capcom CPS1 arcade pcb repair

Well, really a non-repair in some ways, but an interesting case to look at.

This board had a glitch in the background graphics – with repeated sections and blank sections.  The components involved are the custom CPS chip that generates the background, the RAM chips, the main CPU and any latches in between.  The data is written to RAM from the CPU through two LS245 latches(the red path), then the graphics chip reads from RAM through another two LS245 latches (the green path).

You can rule this out being a RAM fault – because the RAM is paired, so it would need two different chips to fail in the exact same way which is unlikely (if only 1 chip failed then you would have bad tiles/colors not good tiles in the wrong place).

You can rule this out being a CPU fault because of the repeated data – the CPU can’t write one thing and have it go to different places at once in the RAM.  The RAM only accepts one address at once.

For the same reason the LS245 latches in between the CPU and RAM must be ok, they couldn’t cause a ‘repeat’.

So this must be a fault in how the graphics chip is reading the RAM (an addressing problem).  Initially I hoped for an easy fix as a broken trace on the board would cause this exact problem (with an address line broken the same data would be read at multiple addresses).  However the traces all run on the top of the board where a scratch is unlikely, and everything was perfect.  A multimeter confirmed continuity all the way from the graphics chip to the latches to the RAM (it also confirmed it to the top B board but I knew that wasn’t at fault as I had already tried out a known working B board).

I ‘mocked up’ the problem in the MAME debugger.  By forcing RAM line 0×400 (or something) to always be low I repro’d the problem (this means that data at say 0×600 reads the same as data as 0×200 (the ’4′ is masked low), 0×602 same as 0×200, etc.  So 1 bit was stuck low in either the LS245 latch, or the CPS-A-01 graphics chip itself.  Removing surface mount chips via hot air is quite easy – replacing them is much harder…  but eventually both were replaced with others from a parts board – and the exact same fault remained   That means the fault was definitely within the unreplaceable CPS-A chip (well, you could replace it with another from a working board, but much easier just to use that board).

And in this case, that’s what I did – an A board from a Magic Sword with no sound and bad B board was swapped in to keep the SF2 World Warrior working.

No Sound fix

A logic probe showed the audio Z80 CPU was running, so I examined the analog audio output by attaching a pair of power speakers at various points on the board.  At first the op-amp at IC138 (pins 1, 2 and 3), then the volume control (VR1), then inputs to the power amp @ 16A.  Faint sound was heard at all points so the power amp was likely the problem.  The amp was removed from the board with the dead CPS-A and soldered in to give a fully working SF2 World Warrior.

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.

Namco Assault arcade pcb repair

(aka Atari Assault, as it was licensed to Atari for the USA).

Board would boot up and sometimes say DRAM error, but most often would not boot properly at all and just constantly reset.  I used the MAME debugger to confirm any error with the main CPU RAM causes the DRAM error message.  The nice thing about this pcb is all the RAM is in sockets from the factory – so very quick to swap out main RAM for spares.

This indeed fixed the DRAM error and sometimes the game would play perfectly – but still sometimes it would not boot at all.  As so many things are in sockets on this board I removed everything I could and cleaned the pcb and all sockets – Simple Green and paintbrush then rinse with water.  PCB looked as good as new!  Even better it booted 100% of the time with everything replaced.

Data East The Real Ghostbusters arcade pcb repair #2

Board was completely dead to start with – no video or audio output.  The video board from Gondomania is the same as the Ghostbusters video board so I started off by attaching a known working video board to the Ghostbusters top board.  This gave me some garbage video:

Which confirms there were faults on both the Ghostbusters top CPU board (because the software was not running) and the bottom board (because there was no video output at all).  The top board was an easy fix – the CPU was inserted backwards – luckily it wasn’t damaged and the game ran fine when reinserted properly.

To debug the bottom video board I started by examining the signals going to the connector between the two boards.  Surprisingly the video sync (CRTSYNC) and vertical blank (VBLK) all pulsed correctly on a logic probe which confirmed the video clock was working as well as the custom IC that drives sync.  The RGBBL (RGB blanking) signal though was stuck low and this seemed to inhibit any RGB output.

From there it was just a case of tracing back all the inputs to RGBBL until a problem was found – which was the HCLK0 input was stuck high.  Rather strangely this turned out to be a physical problem on the board rather than a TTL one – the leads on some of the ICs had not been clipped short enough and at one point on the board the HCLK line was shorted to a +5V line.  When cleaned up everything worked 100%.

Sega Super Monaco GP arcade pcb repair

Super Monaco GP!  Same board as Afterburner, one of the classic late 80′s sprite scaling boards.  Very complex hardware with 2 68000 CPU’s + Z80 for audio.  When powered up this board would flash the screen for a second and then sit dead on a black screen.  Logic probe showed the main 68000 was getting a clock signal but there was no activity on any data or address pin.  The probe also revealed the reset logic was working fine, and there was a burst of data activity for a second or less at boot up before it stopped.

A stopped 68000 usually means there is a bus error or illegal instruction and the CPU has crashed, usually asserting the bus error hardware pin.  In this case the BERR pin didn’t show anything.  I suspected the software was actually issuing a STOP command and indeed when I fired up the MAME debugger I found all the exception handlers jumped to STOP routines.  So the theory was the program started to run, crashed, then the CPU was told to stop.  The most common reason for a crash would be bad RAM – because as soon as the program tries to return from a subroutine, a bad value would be returned by the RAM (most likely 0xffffffff) which would trigger a bus error for unaligned access.

Piggybacking known good RAM didn’t help so I decided to write a little diagnostic ROM that would print RAM values to screen.  The program itself is very careful not to use any RAM of course – so no subroutines, just logic instructions and static branches.  After trying the program out in MAME, I first needed to modify the board to run on 27c010 eproms – rather than the 27c1000 pinout eproms my programmer didn’t support.  Jumpers/resistors can be toggled to switch between the two different types (see Afterburner schematics for full details).  The program worked first time – which was great because it proved the main CPU was running as well as the palette and text layer hardware.

Running the real hardware side by side against MAME showed a couple of bad bits in the 0×280000 range – which according to MAME memory map is actually the sub CPU RAM.  I used the logic probe to short pins on the RAM chips to identify what physical chip matched that address range and then piggybacked the known good RAM on top.  The values flickered and changed which is a good sign the RAM was bad (the flickering being the two RAM chips arguing over the correct value).  The RAM (TMM2063@IC31) was removed and replaced and the board worked 100% again.

Diagnostic ROM and source is included below – note it’s a very quick hacky test!  Not something polished and easy to use.

Diagnostic ROM and source – MakeSMGP- provided with no warranty

Capcom Last Duel arcade pcb repair

Game played but with lines through sprites and corrupt sprite colours.  Diagnosis was quick – it was clear a mask ROM was missing on the video board, and strangely it’s sister ROM was inserted with a pin outside the socket.

The board has pins for both a 23c2000 16 bit mask ROM or two 8 bit 27c301 ROMs, probably so the factory had flexibility to fit whatever type was cheaper during the production run.  But.. the 27c301 is a 32 pin IC, and the mask ROMs fitted are only 28 pin.

This borrowed picture shows how it is possible – the top 4 pins are VPP (programming voltage), VCC (+5V), OE (output enable), PGM (enable programming).  The 28 pin mask rom doesn’t need the programming pins, and it omits OE in favour of just using CE (chip enable), so it always outputs when enabled.  The +5V line then just runs to the NC (not connected) spare pin on the 27c301.  So this way the board can use both the 28 pin or 32 pin ROM with no other modification.  In this case I used a fresh 27c301 and everything was fixed.

Konami Blades of Steel arcade pcb repair

Game played blind, with audio responding to input, but no video signal.

The custom digital to analog IC for video had obviously been changed in the past as a lot of solder flux was on the board.  (Same custom IC as Dark Adventure).  In the fact the problem was just a single pin had a bad connection – when resoldered video returned and the game was 100% again.

Konami Dark Adventure arcade pcb repair

A very frustrating time consuming repair…  The board was initially stone dead – no video output at all.  Logic probe revealed the reset on the 68000 CPU wasn’t working.  This was quickly traced to a Fujitsu LS07 chip near the edge connector – dead outputs.  Logic probe on the two Fujitsu LS32 chips next to it also showed dead inputs, so all were replaced.  At this point things slowed – 10% of the time the board wouldn’t boot, 70% it would show the ROM RAM TEST string and hang, 10% of the time that test would complete after a while, and 10% it would complete instantly.  When the test did complete it would show various bad ROM and RAM chips.  If the test completely instantly then everything showed bad, so clearly the test itself wasn’t working correctly.

MAME provides some insight into how the game works – there are two 68000 CPU’s – the master does a few tests, and prints the ROM test string, then it signals the sub CPU via an IRQ to do the bulk of the tests.  When the sub CPU completes it uses an IRQ to signal back to the main CPU which then shows the results screen.  I spent a lot of time examining all the components involved in the IRQ logic and the Fujitsu LS273 at 5U was found to be bad.  This IC is a latch that passes input to output on a clock signal – but the probe showed the inputs went to outputs regardless of the clock – so it was just spewing bad signals everywhere downstream.

The MAME debugger also shows the main program waits for the graphics hardware on the bottom board to signal it’s ready a couple of times before the self test happens.  This turned out to be a bad trace on the board somewhere – the CPU would just get a disconnecting floating signal.  This was the reason for the inconsistent booting – sometimes it would hang forever waiting, sometimes it would read as being ready before it really was.  With the bad trace patched the game would finally boot consistently and with no errors on the check screen!

But…  lack of sound now quite obvious.  There was no hiss from the speakers so I suspected the amp was bad but before looking at that I used the logic probe to try and see if the sound CPU program was running properly.  The main CPU sends sounds commands to the sound CPU and triggers an interrupt when the command is ready.  The sound CPU reads the command, acknowledges the interrupt and things continue.  So if things are working well placing the logic probe on the Z80 interrupt line you should see it pulse for every sound played (easy to see in the audio test).  But…  more inconsistency – often it would accept the first IRQ then hang/crash, leaving the IRQ line low so it was obvious it was never acknowledged.  Sometimes it could trigger 4 or 5 times before hanging.

So yet more time examining the IC’s related to sound IRQ, the sound RAM and I even swapped out the YM2151 audio chip which was obviously corroded and perhaps putting bad data onto the bus.  Eventually this turned out to another bad trace – sometimes a pin on the RAM chip would drop out which of course caused the CPU to crash returning from the interrupt (as the wrong value would be pulled from the stack).

The amp turned out to be good – the fault there was one of the power capacitors had physical damage and 12V was not getting to the amp.  With that replaced sound was working.

But..  now obvious inputs were faulty as player joystick left did not work.  Like most Konami games of this era inputs go through a custom IC then a LS253 multiplexor IC.  Because the output of these chips go onto a shared data bus you can’t tell bad outputs with a logic probe alone, but usually piggy-backing a good chip on top will identify the problem IC.  In this case the chip @ 2M controller player 1 left and when replaced the board was finally playing perfect again.

Technos Double Dragon 2 arcade pcb repair #2

I bought this board non-working and it arrived with the main RAM missing on the top board and two sprite RAM chips missing on the bottom.  I soldered in replacements and.. it worked 100%!  Nowadays this is a very valuable game for someone to scavenge for quite cheap RAM parts, so I assume it had been removed years if not decades ago.