Problem

Dead.

Diagnosis

I hooked up my trusty logic analyzer to the master 68A09E (W6). I was able to determine that code execution was stuck around the 6xxx range. This range does not contain valid executable code. Execution was dropping into this range because a bad return address was being popped from the stack. Interestingly, at this particular phase in the code (0xD79D), the stack pointer points into sprite RAM (6264 SRAM at D6 and E6). The data bus activity on E6 during reads looked rather suspect, so I replaced it.

Replacing E6 allowed the game to run further and it would occasionally display this nonsense:

RAM 4 (H1) is a 2018 SRAM shared between the three 68A09Es. Using the logic analyzer, I could see the value 0x02 being written to the RAM at location 0x003C but subsequent reads back from this address were random. Replacing H1 finally allowed the game to boot, however things were far from perfect:

All RAM was now reported good. I turned my attention to the CUS123 tilemap IC on the ROM board:

There was activity on all input and control pins but one of the outputs, A6 of the ROM address bus, was stuck low.  Reflowing the pins of the IC actually caused the graphical errors to worsen! I replaced CUS123 with a donor from a beyond-repair System 2 PCB.

Installing the new CUS123 fixed the tilemap layers. However, the sprites were still a jumbled mess:

The sprite hardware is mainly comprised of two custom ICs: CUS39 and CUS48. These are also found on System 86/Rolling Thunder. I ruled these out by swapping them with a known-good pair.

I then probed CUS39 with the logic analyzer to check the accesses to the line buffer RAM at D4/E4. I could then see if the data written was the same as the data read back:

On the strength of the suspicious reads, I decided to replace D4. This brought Pac back and finally all was well with the boardset!

Fix

Replace 6264 SRAM at E6.

Replace 2018 SRAM at H1.

Replace CUS123 at S8.

Replace 2018 SRAM at D4.

Philip Bennett