Konami Pandora’s Palace arcade pcb repair

Board 1

Board would boot with some corrupt text, then reset.  The tilemap RAM for text tested ok, but it was just re-seating and cleaning the tilemap custom 85 that fixed the text which now read CPU A OK.  At this point CPU B is meant to kick in and run it’s own self test and report, but the board kept resetting.  A logic probe on CPU B reset line showed it pulsed very briefly then went back to being held in reset, so it didn’t have a chance to run the self test.

Things got a bit trickier at this point – the reset is controlled by a LS138 and LS259 that the main CPU can write to.  These components were removed and replaced with no change, so I fired up MAME to debug what exactly happens during the boot sequence.  It turns out both CPUs can write to the LS259 latch – CPU A performs it’s self test, enables CPU B and then sits in a tight loop until CPU B finishes and enables interrupts on CPU A at which point they both run in parallel.

This raises the possibility that CPU B was actually resetting itself with a rogue write to the latch and causing a deadlock…  And indeed that was the problem, a corrupt program that had tested fine first time around but on a re-read showed some random bad bits.

The game now played with some bad sprites – other sprites were fine though, so the sprite custom chip and RAM were likely good.  Again, this was just failed eproms that needed replaced.

Finally, lack of sound was a failed Z80 CPU on the top board – a logic probe showed it had a valid clock, reset and so on but all data and address lines were stuck high.  Putting in a fresh CPU fixed everything.

Board 2

Did not boot at all with garbage on screen and the CPU stuck in a watchdog reset.  This turned out to be straightforward as the CPU A boot eprom had completely failed.  Replacing it enabled the game to run, with some bad sprites, but like the first board this was just more failed eproms.