Konami Pandora’s Palace arcade pcb repair
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.
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.