PCB Repair: Rolling Thunder (again)

John here again with another Rolling Thunder but a different problem .

Problem

Sprites flicker and disappear in a ‘noisy’ manner. They don’t disappear in a ‘block’ manner, rather random pixels flicker as if the sprites are being blown away. Once warmed up, this seems to lessen, although one that sticks around the longest is a priority issue:

Diagnosis

The sprite (‘object’) area is the obvious place to look. As is usually the case, there is the CPU-facing ‘sprite’ RAM and a buffered copy (both circled at the top of the schematic below), where the custom IC copies the data (during a Vblank?). Although, as socketed, I tried a swap to no avail, it was always unlikely to be the CPU-facing SRAM as that is also used for CPU general processing (which is presumably fine).

The buffered copy (TMM2018) is soldered, so rather than ripping that out, it seemed more sensible to have a probe around the graphics area.
I get to the HSET line (lower circle in the schematic) and the logic high is a mere 2V. So well below acceptable thresholds.

As it’s used for the latching of sprite pixel data and near the thresholds (so temperature could easily make a difference), it seems a fair culprit for the problem.

The weak signal is either the fault of the custom at 9M or one of the 74LS173 latches. Whilst I swapped the custom to discover it was fine, you could likely remove the custom and probe the signals (use a multimeter to measure the resistance or diode forward voltage of the pin to ground, then compare to similar signals).

With the custom fine, it’s easier to just change the 3 logic IC’s than to try to guess which one is pulling the signal low. It could even be that with all of them being clocked at 6MHz, they’ve aged similarly?