Good job!!
You should probably just reflow all the RAM pins and maybe the SMT02 -- but carefully and
only after thorough cleaning -- you could have microscopic debris shorts that have worked their way behind the pins. Blast it out with compressed air. Check all of the SMT02 pins for shorts -- and also the BSRs and DAC. n.b. For others, U44 is a BSR03 (Bit-Shift Register). The DAC is U47/ADV473 -- I'm sure you know -- just a mental typo.
Then, wire up the failing RAM to your logic analyzer and look at the R/W cycles (compare vs. the data book for those parts). It looks like a random write problem -- floating or shorted (being driven by something else, possibly). It is probably not shorted to an adjacent data pin because with a 1-bit half-tone background, it is not double adjacent pixel data -- it appears random -- or at least with respect to the end of the write cycle.
However, if you wire the part, you should be able to see/evaluate the write cycle. And, for this test, it would be easier to trigger with the board as a secondary monitor with a
solid black background so that the screen is all black (also no burn-in this way -- better not to use all white
). That way, you can just trigger on white pixels on that line (but in conjunction with a write strobe, so that you're triggering on a cycle and not randomly). You know it happens with a solid background, because you see it at Primary INIT when the clut is programmed with gray and red for the SuperMac "S" vs. black and white. You could also use a timed trigger if you needed to, but you should be able to trigger on the failure. It could also be a timing/rise-fall/line voltage/data valid issue (resistive but not broken) -- check trace resistance.
You could also connect the failing pin to the logic analyzer on its own (as a starting point), give it a long capture time and see if it has an obviously recognizable signal -- for example, like a clock signal? (in which case it would be shorted to a clock somehow). Or, is it extremely noisy - AC injection issue from somewhere -- or just floating? Is it tied to a nearby interrupt line? There are lots of possibilities. Signal periodicity is often a handy debug clue (and something to rule out).
Then, after you wire everything, you might see that it is tracking one of the other utility signals -- another clue about a possible short. You could also try looking at surrounding adjacent pins on the SMT02 -- maybe that would offer a clue, since there was an SMT02 short for the other column issue.
Since you fixed the other garbage/column issues, you probably don't have a problem with general via corrosion, which is good. When there are build issues and corrosion/migration after many years, it can affect many via locations.
Besides the above, try to figure out the exact path of the failing trace to U19.23 and check it again for opens/shorts -- including any connecting vias in its path. Or, as before, it could just be a bad solder joint at either end.
Or, you could also theoretically test jump it directly with rework wire (and expect signal reflections - but who cares). If you see the behavior change with any noticeable improvement, then you might be able to assume there is a break (that
should be verifiable with a meter before doing this test). You could try this test from SMT02->RAM and RAM->BSR, etc.
IF you can identify a failed via, then you can drill and fill. Or, if you don't want to do that, then it would have to be cuts and a jump (over the via -- and ensuring minimal trace stubbing to limit signal reflections) -- but, it's an uglier repair with surface rework. Drill and fill is not that hard -- you just need the reams, silver epoxy and a little care.
Anyway -- it sounds like you are on a very pragmatic hardware debug path, which is the right way to go for this kind of problem! No freebies or easy answers -- just crawling across the desert on your hands and knees.
Maybe something here will help - hope so.