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


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.

IMG_7506 IMG_7504

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!

IMG_7640 IMG_7641

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.





Leave a Reply