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.

Konami X-Men arcade pcb repair #2

Game played and passed all self tests (including mask ROM tests) but some background elements had incorrect colors or appeared completely black.  Colors ultimately come from the palette RAM but that was most likely good as the self test had passed.  A group of 3 LS157 chips arbitrate access to the palette RAM address lines – these can be controlled either by the main CPU, or by the 053251 priority mixer which combines all of the layers (sprites and tilemaps) to send a final output pixel to the palette lookup.

All address lines seemed good with a logic probe so the problem was most likely the 053251 itself or the tilemap custom that fed it.  As other tilemap elements were fine, the 053251 was replaced with one from a scrap board and this fixed the problem.

Konami Hyper Sports arcade pcb repair #2

The game logic seemed to be running but graphics were totally corrupted.  Tilemaps are usually easier to fix than sprite problems so I started there, but the relevant custom chips and RAM checked out fine.  The breakthrough came when I noticed one of the RAM chips never had the write (/W) line enabled at any point.  The write lines should almost always be pulsing on this game as the CPU writes tile data into RAM.

The V1DIR and V2DIR signals actually start on the top CPU board, but they travel to the bottom and are buffered by an LS241 before reaching the RAM chips.  This chip was removed and tested bad before being replaced.

Which improved things somewhat – definitely recognisable now but still broken.

I kept on debugging the tilemap RAM and found a couple of data lines were always high – I knew the RAM was good so I started to search for ways in which the data could be corrupted before getting to the RAM.  This traced back to the LS245 on the top CPU board that sends CPU data to the video board – it had failed on multiple lines so literally every byte the video board received was corrupt in some way.  Replacing this fixed everything 100%.

Taito Legend of Kage arcade pcb repair #2

Game just booted to a solid white screen with the CPU in a watchdog reset loop.  This game, like Bubble Bobble, uses custom package RGB DAC’s that are known to fail (and also need +12V and -5V connected to work) but it seemed the palette RAM was actually passing full white to the DACs so the initial problem wasn’t there.

Usual test first is to check the program ROMs – and one wouldn’t read at all due to some kind of internal short.  When replaced the game ran, but without any sprites or tilemaps but at least it proved the RGB customs were working.

RAM on the video board all tested fine, but what looked like some dirt on the board actually turned out to be a massive gouge that had broken 10-12 traces.  When patched back up the game was fine.

Taito Frontline arcade pcb repair #2

Game played but without sound.  Diagnosing sound problems on these boards is pretty easy as all of the sound generators have test points on the top board – PSG1-4, DAOUT.  Attaching power speakers here lets you hear the individual sound outputs before they are mixed.  If they are all silent then there is most likely a sound CPU problem, but for this board everything sounded great at the test points.   The sound is then mixed and sent to the two volume controls – powered speakers can also be attached directly to the right-most and center pins of the volume pots to check audio post mix.  From there it’s almost straight to the power amp, and if you can hear audio over powered speakers attached to the power amp input (pin 1) then almost certainly the power amp is dead (or is missing +12V).  In this case the MB3730 amp was replaced to fix sound.

Tecmo Knight arcade pcb repair

Game booted, but the red & blue color channels were clearly stuck on.  I went hunting for palette RAM and found it on the top board, it’s a slightly unusual type – AAA16K4P-35 with one chip per RGB color.  Swapping in replacements from a Ninja Gaiden parts board restored correct colors, and I could see the video board problems in more detail.

One tilemap layer had corruption – the game has 3 tilemap layers and each layer comes from a combination of the Tecmo 3 & 4 custom chips, graphics ROM plus a pair of RAM chips.  One of the RAM chips tested bad straight away, but with that replaced there were still problems.  A logic probe on the ROM showed one of the address lines was floating – but it had continuity back to the Tecmo-4 custom.  Unfortunately this suggested the line had died inside the custom chip.  Replacing this improved things but there was still a fault with tiles being ‘doubled up’.

A logic probe on the RAM chip showed the D0 data line was stuck low, and this traced back to the Tecmo-3 custom – so the doubling was because only even (0,2,4,6,etc) tiles could be selected.  This custom was also replaced with one from the Ninja Gaiden parts board and everything was fixed.