This is fascinating - looking forward to what you find! I've spent hours tracing bad grounds before, I hope you find a corroded ground pin somewhere and that's that.
=] -- Anders Nelson +1 (517) 775-6129 www.erogear.com On Tue, Aug 15, 2017 at 8:18 AM, Rob Jarratt via cctalk < cctalk@classiccmp.org> wrote: > > > > -----Original Message----- > > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Peter > > Coghlan via cctalk > > Sent: 15 August 2017 09:48 > > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > > Subject: RE: DECstation 220. Another Impasse > > > > > > > > I have looked at this problem a little more. I have two motherboards, > > > neither of which work, but one at least produces a corrupted video > pattern. > > > The one that works best appears not to be writing to the video memory. > > > When I look at the EMEM pin on the Paradise PVGA1A chip I can see a > > > signal but the scope shows a trace that is very faint. When I look at > > > the same pin on the other motherboard, I get a nice clear bright trace > > > on the scope, using all the same settings on the scope. This pin is > > > driven by a non-inverting buffer (74LS126). The input side of the > > > buffer is tied to 0V, the enable signal comes from a custom gate > > > array. Comparing the buffer's enable signal on the two boards I see > > > the same dimming effect on the board with the corrupted video pattern, > and > > no dimming on the other board. > > > > > > > A dim trace suggests that the trace is changing too rapidly to see it > properly. > > Try increasing the scope brightness and sweep rate and adjusting the > various > > triggering options to see if you can get a better trace that reveals what > is really > > happening at that pin. It might be useful to try triggering the scope > from > > whatever clock is used locally as the signal might be synchronised to > that. > > Once you can see the trace properly, it should be easier to figure out > where it > > is coming from. > > > > > > > > I have checked the other pins on both the buffer and the gate array > > > and I don't see anything suspicious. > > > > > > > It may be worth looking very closely at the power supply pins for > difficult to see > > spikes that might be caused by decoupling failures. > > It would also be good to make sure ground is really ground at the chips > in > > question. > > > > > > > > I am thinking of speculatively replacing the 74LS126 because I can go > > > and buy replacement parts for it, I can't replace the gate array > > > (although I could conceivably swap the part on the two boards). > > > > > > > If the 74LS126 has some fault at it's input which is affecting the signal > coming > > from the gate array, it seems to me that it would be more likely to load > it down > > or up rather than cause it to change rapidly (if that is in fact what it > is doing), > > unless it has somehow managed to turn itself into an oscillator. > > > > On the other hand, if the gate array output is open collector, it could > be > relying > > on the 74LS126 to provide a collector load and not getting it if the > 74LS126 is > > faulty. This seems unlikely though. > > > > I suppose another possibility is that the gate array output could be > tristate and > > not enabled leading to noise pickup from nearby traces and components and > > perhaps across the PCB surface, given there was a battery leak at some > point. > > > > Getting back to the oscillator theory, I wonder if it is possible that > the > non- > > inverting buffer could be oscillating at a much higher frequency than > normally > > found on the board due to feedback from it's output to it's input as > result of the > > battery leakage? > > > > I don't normally like suggesting cutting tracks but if the board already > has > > damaged and repaired tracks, you might feel ok about cutting the track > > between the gate array and the 74LS126 to determine which of them (or > both > > together) is responsible for the unusual signal there. > > > > I would be very wary of replacing the unobtainable gate array with your > only > > replacement until all other possiblities are eliminated in case the gate > array > > was damaged by a fault elsewhere. > > > > Looks like I've provided more questions than answers :-( > > > > > Some great ideas Peter, thanks! I will double check the scope, I wonder if > mine doesn't have the bandwidth to show a glitch that is occurring? I will > consider cutting the track, which is also a great idea. I really do have to > hope that it isn't the gate array, it is my last resort, although that was > closer to the leakage damage than the 74LS126. > > Regards > > Rob > >
