SuperMac Spectrum 24/V Display Problems

[MacOSMonkey]

Seems like you're making progress. It's certainly possible that the BSR and DAC are OK. If you have identified a bad VRAM, you could just substitute or replace it. I think you have other boards that use the same parts. Or, you could use (or write) a board VRAM R/W tester. If any RAM is bad (including the one you have noted), R/W verification should fail. Or, you could use a visual pattern on the desktop or hook that part to a logic analyzer and write all black or all white to RAM (again -- using a desktop pattern). If you see anything other than 1's or 0's -- whichever way it's stuck -- then you know the part is bad. There are lots of options. Hope it works out!

 

[jmacz]

Ok, finally made a bit more progress on this particular card this evening.

The RAMDACs seem fine. I was able to individually tie the inputs to the RAMDACs to HIGH or LOW and get the expected output on the screen.

But the decision to make that nubus interposer is helping... with the video card lying flat on my workbench while running, I was able to consistently reproduce artifacts when applying down pressure on various chips. The issue is most pronounced in the area where the VRAM chips I was playing with reside. I used a toothpick to nudge each pin on the VRAM chips in this area but that's not the issue. It's only downward pressure applied in this area that causes random artifacts to appear.

Given the card had physical damage, I'm guessing the card endured some bending motion that most likely partially severed some internal traces in the vicinity of those VRAM chips. It's a 4" x 2" area of the board where I'm suspecting the issue to be. It could be internal traces or could be damage to a power/ground plane also. But I still do believe it's mostly with the signals read from or written to VRAM chips U19 and U20.

My next course of action is to attach probes to those VRAM chips and while using a static image on the monitor, see which pins have fluctuating values as I apply pressure.

I'm still confused on a couple things though...

In Black and White Mode - I obviously see a column of pixels that are incorrect (it's repeating at regular intervals which is expected) and when I apply downward pressure, I see a couple more columns having issues. This behavior makes sense to me if some traces were damaged (again, I suspect it's traces on the write path to the VRAM, not the read path).

In 24bit Color Mode - I get what appears to be a clean blit of an image (the turtle graphic I showed earlier in this thread). But I seem to be having erase issues where the screen doesn't redraw properly. So menu's don't appear. Moving the cursor results in dirty pixels along the path of where I moved the cursor. This isn't making sense to me. How can I get a clean picture? or maybe at 24bit, the error is masked in insignificant bits.

 

[MacOSMonkey]

If the traces are damaged, then they will be resistive and/or intermittent. The problem you are seeing with the broken column is 100% reproducible, so not intermittent. Try not to flex the board too much -- you could do more damage. Just carefully check resistance on the VRAM traces and look for variation. I know you did some of this before (also on Spec/24 III), but double check it. If there is really a bad trace based on the repeating 32 px column in 1-bit mode, then you should be able to find it. Also, if the board sustained in impact, then make sure there are no broken/fractured traces, solder joints or vias. Look over the entire board. Something may look soldered, but it might be fractured (including vias and delam'd outer pads).

You have already desoldered a bunch of the RAM. However, make sure you have reflowed ALL of the VRAM pins. Apply some flux and go over them with an iron. Also, check other components at the site of impact (or maybe in general).

When debugging, if you are 100% sure that you have identified a fractured internal via/trace, then the standard solution would be to drill and fill with silver epoxy to reconnect the severed trace. Check it multiple times and make sure that is the problem before doing any destructive repairs...and be careful about hole clearances.

If you are going to try to drill out a via, it would be best to use a micro hand ream and try not to go more than .010" over the hole size (bearing in mind that the hole has been plated down during via metallization (electroless/through-hole plating, etc.) -- unless you can see the hole clearance using a bright light -- maybe -- otherwise, you would have to x-ray it). You could also check the trace-hole clearances on the outer layers to get an idea of what kind of design rules may have been used in the PCB layout tool during the design process.

However, an inner layer route might go very close to the hole clearance. Also, you have a margin on the drill tolerance of probably +/- .003" (at least - maybe more). The best way might be to start with a small ream and eyeball it. When you see that you have just barely reamed out the plating, carefully go bigger until you see the shiny trace end on the inner layer -- it may not take much. As soon as you can see the trace edge, you should be ready to fill...and when you do, you need to make sure there are no silver epoxy voids.

re: cursor:
The Mac's cursor is being updated during VBL and the accelerator code has specific protection built in to prevent update and interrupt conflicts vs. onboard accelerated blits. Given the problems you are seeing, when you are using the board in 24-bit mode with acceleration enabled, there will probably be cursor pixel garbage. It is likely a side effect of sequential cursor region updates and whatever is wrong in the onboard accelerated data path (or whatever the issue is - ??). Turn off the accelerator and see if the cursor garbage still happens. I think you said that it didn't in the earlier post.

Anyway -- happy debugging. Avoid rabbit holes and stay on the path!

You may not need the info above...but if you do, be careful and use common sense. And again, don't flex the board too much - you could induce new failures/via fractures.

 

[jmacz]

When debugging, if you are 100% sure that you have identified a fractured internal via/trace, then the standard solution would be to drill and fill with silver epoxy to reconnect the severed trace. Check it multiple times and make sure that is the problem before doing any destructive repairs...and be careful about hole clearances.

I'm a bit concerned about drilling especially because it may be difficult to figure out the path of an internal trace? I was thinking that if I determine which chips are impacted by internal trace damage, that I lift the legs of those chips and use a bodge wire instead?

And again, don't flex the board too much - you could induce new failures/via fractures.

Yeah, it's actually just slight pressure that is causing visible artifacts. I'm not even pressing down 1mm.. it's a fraction of that, probably similar to the stresses when handling the board and installing it in a machine. It's just easier as the board is out of the machine. Hopefully this is progress and I'm not on a wild goose chase.

 

[jmacz]

More progress while in Black and White mode.

The vertical line artifact I have been chasing is from VRAM Chip U19 pin 26 which goes to RAMDAC U44 pin 5. This one continues to be a problem. The VRAM gets the value for this particular output via input on U19 pin 23 which is connected to the SMT02 Chip Pin 31. I am certain it's not the RAMDAC or the VRAM as that would have resulted in that vertical column being a solid color. But it's not. There's some broken areas of the line as well. Also, when I moved a window around, it sometimes captures this column of pixels as the window is moving so that suggests the read from the VRAM is not the problem, it's the write to the VRAM that is the problem.

Now in addition to this column that I have been focused on, there were some other "dirty" areas of the screen. These dirty areas change when I was doing the pressure/tapping exercise mentioned a couple of posts ago. These are unrelated to the column I have been focused on. But I did fix this particular issue. There were four legs spread across two other VRAM chips that although had connectivity, must have had a bad joint. I was able to narrow down the chips by tapping, isolate the legs, and after reflowing those legs, this problem is gone. Pressure/tapping no longer causes additional artifacts on the screen.

Now back to the column I have been chasing, while looking at this further, I stumbled upon another column having issues but not exactly as bad, but it's still a column with some problem. This column is driven by VRAM Chip U21 pin 2 which goes to RAMDAC U44 pin 11. This one gets its input from U19 pin 5. I have not yet traced which pin on the SMT02 chip provides this input. But it almost seems like these two inputs are getting mixed. If that is true, then the traces for these two (U19 pin 23 and U19 pin 5) must be conflicting possibly due to an internal trace break.

Need to look at this more now. But some progress.

 

[jmacz]

That additional column I stumbled upon (driven by VRAM Chip U12 pin 2) was a different problem. I found a shorted set of pins on SMT02 and fixing that resolved that one.

So I hope I'm really down to the last column of pixels to fix which is the original VRAM Chip U19 pin 26.

Picture is much cleaner now and currently looks like this in black and white:



Notice how the columns aren't a solid color so I don't think it's an issue on the rendering via the RAMDAC. And when I drag this window horizontally, I get this:



The artifacts get copied into the buffer for window contents. So the bad pixels/column is written into the VRAM, it's not on the way out to the RAMDAC. At least that's my conclusion. Need to continue investigating why the bad bits are being written to VRAM.

This particular VRAM chip (U19) I had previously swapped with another and the problem followed the location, not the chip. That should rule out the VRAM chip itself.

 

[MacOSMonkey]

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.

 

[jmacz]

For others, U44 is a BSR03 (Bit-Shift Register). The DAC is U47/ADV473 -- I'm sure you know -- just a mental typo.

Yes, mental typo. Had in my mind cleared the BSRs and the DAC so mentally kept referring to them as a unit and wrote it down that way. Oops.

Cool, thanks for the tips! Hopefully will get this resolved soon. Trick has been more finding contiguous time to work on this as work has been so busy.