This pcb booted up but with corrupt graphics. Helpfully Pacland does a self-test on startup and this one briefly printed 0 0 4 on screen (or arguably 4 0 0 as the self-test is printed upside down – to clarify the 4 is the first digit to appear). This means a RAM error and as I have a working Pacland to compare against it was quite easy to work out what error digit corresponds to what chip.
Piggy-backing a replacement chip on top fixed the corrupt text and the top scrolling layer so for sure RAM was bad. The bottom scrolling layer was now completely absent though and the self-test didn’t report any errors.
As I had a working board I swapped the custom chips and tilemap ROMs between boards just to rule them out and it made no difference. I suspected the fault was in the priority mixing circuit – this is what decides what pixel is ‘on top’ be it text, sprite or a scrolling layer.
The relevant chunk of the schematics is above, essentially the sprites and top scrolling layer are mixed by custom chip 29. The bottom scrolling layer is produced by custom chip 30 and drives the ROM at 4N. A pair of LS298 multiplexer chips then decide what takes priority – the background layer or the sprite/foreground layer. The LS298 selector is driven by an 8 input AND gate (LS30 @ 1N). This is really what determines ‘transparency’ in the sprite/top tilemap layer – if any of the 7 bits are high for a given pixel then it is ‘opaque’ – all low means ‘transparent’ and the lower layer should be shown.
On this board the LS298 chips and the LS30 are all manufactured by Fujitsu, which is known for a terrible failure rate. A logic probe showed the output of the LS30 chip was dead – so the LS298′s in turn were constantly stuck. Replacing the LS30 with one from a Dragonninja parts board fixed the problem.