Problem

Game runs but nothing is visible other than solid-colored blocks:

Diagnosis

System 16A has four graphical layers: text (‘FIX’), foreground (‘SA’), background (‘SB’) and sprites (‘OBJ’).

IC57, an 82S153 PLD, primarily determines which of the four layers should be visible. This is based on whether a layer’s pixel data is transparent (handled by IC85 and IC56) and a fixed priority order: FIX has highest priority, followed by OBJ, SA and then SB.

An array of LS153s is used to multiplex the pixel data of the selected layer onto the palette RAM address bus:

Select lines A and B of the LS153 array were permenantly high. This meant that the FIX layer would always be visible. Tracing back to IC85, FIX0-2 were found to be always high. Not only would the FIX layer show up as blocks of solid color, there would be no transparency either, as the pixel data would never be 0 (the transparent color index).

The FIX0-2 signals originate from the 74LS174 pair at IC102/IC103:

Inputs D0-3 of IC102 were always high. Probing a little further, it turned out that outputs Q0-3 of IC103 were also stuck high. Replacing IC103 improved matters a little:

FIX transparency still seemed to be broken and one of the FIX bits was likely incorrect. Indeed, FIX0 was still stuck high. It was actually shorted to 5V. While replacing IC103, one of the pins that was tied to 5V had made contact with the trace running next to it, which happened to carry the FIX0 signal:

I likely had the temperature of my soldering rework station set too high for this older type of PCB (two layers, no power planes). With no power planes to dissipate the heat, It doesn’t take much to burn away the aging solder mask and cause pesky shorts like this. I dropped the temperature down to 600°F (315°C) to remove and replace IC103 a second time. No shorts this time around!

With the FIX0 short gone, everything was visible but the sprites:

Given that the ‘sprites’ remained static, I theorized that the CPU was somehow unable to write to sprite RAM and that the sprite hardware was processing whatever garbage values happened to reside in sprite RAM. Looking at the video PCB schematics, bi-directional buffers IC43 and IC51 (74LS245) act as the interface to the sprite RAM at IC28/IC22:

CPU access to sprite RAM appeared to be controlled by the 315-5012 custom IC, specifically by the /LDEN output that runs to /OE of IC43/IC51. I found that /LDEN was always high, which would entirely prevent any CPU read or write access to sprite RAM. Before I could begin worrying that the custom IC was potentially bad I noticed that there was an input to the IC which was the logical OR (IC117) of the /LDEN signal with something else (presumably a signal from the CPU side). Pin 11, an output, did not follow its inputs at pins 12 and 13. In addition, touching the chip caused the game to reset! Probing other inputs and outputs of IC117 showed bad signals, which was enough to convince me that this IC needed to be replaced…

Fix

Replace 74LS174 at IC103 (main PCB).

Replace 74LS32 at IC117 (video PCB).

Philip Bennett