Battery bombed Centris 650’- corrupt video out

[joevt]

I didn’t think about doing screenshot. I assumed it was something on the output side. View attachment 24412
Since the lines show up in the screenshot, this means it’s between the CPU and the vram (or the vram itself)?

I think so. Looks like line 29 of one of the 32-bit buses. Maybe post the screenshot here so we can count the pixels.

If the problem was with CPU and RAM, then you wouldn't be able to boot.

PD[31:0], PDf[31:0] are on the output side of the VRAM, so look at BDb[31:0] which is probably the input side of the VRAM.

The problem exists all over the display, so it's not a single VRAM chip (U20) or VRAM socket (J19). But it could be that one of those is grounding the date line.

There's a memory buffer at U19 which separates CPU data lines D[31:0] from VRAM data lines BDb[31:0]. If there's continuity between U19 and VRAM, then the problem could be inside U19.

 

[wottle]

I think so. Looks like line 29 of one of the 32-bit buses. Maybe post the screenshot here so we can count the pixels.

If the problem was with CPU and RAM, then you wouldn't be able to boot.

PD[31:0], PDf[31:0] are on the output side of the VRAM, so look at BDb[31:0] which is probably the input side of the VRAM.

The problem exists all over the display, so it's not a single VRAM chip (U20) or VRAM socket (J19). But it could be that one of those is grounding the date line.

There's a memory buffer at U19 which separates CPU data lines D[31:0] from VRAM data lines BDb[31:0]. If there's continuity between U19 and VRAM, then the problem could be inside U19.

Looking at the image in Basilisk II, the black line repeats at pixel 2 (with the far left pixel starting at 0), then repeats every 32 pixels (e.g. 34, 64, 98, etc).

Here's the image (I made cascading pixels where each vertical line is 10 pixels)

How do the vertical lines translate to the VRAM data lines? e.g does a failure at line 2 translate to 29 (is it reverse order of the 32 address lines, zero-based indexed would put the 3rd line at 29)?

 

[joevt]

Looking at the image in Basilisk II, the black line repeats at pixel 2 (with the far left pixel starting at 0), then repeats every 32 pixels (e.g. 34, 64, 98, etc).

Here's the image (I made cascading pixels where each vertical line is 10 pixels)

How do the vertical lines translate to the VRAM data lines? e.g does a failure at line 2 translate to 29 (is it reverse order of the 32 address lines, zero-based indexed would put the 3rd line at 29)?

View attachment 24419

The first line begins at offset 0 of the frame buffer.
The most significant bit (bit 7) of the fist byte is the top left pixel.
32 bits is 4 bytes. The most significant bit of a 4 byte value is bit 31 (left edge) and the bits count down to 0 (right edge).
Check continuity between the date lines and ground. Bit 29 may be connected to ground somehow.
Or do a compare between D[29] and BDb[29] of U19 maybe U19 is not passing the value from one side to the other.

 

[joevt]

In your screenshot, the first 4 bytes of the framebuffer is 07FFFFFF hex. That is 5 zero bits (black pixels) followed by 27 one bits (white pixels).
The second line is 1FFFFFFF.
The third line is the same as the second line but it should be 3FFFFFFF.
The fourth and 5th lines begin with 5F but should be 7F. The first 4 bytes of those lines also contain the zero pixels for the top 2 lines of the Apple menu.

 

[wottle]

RESOLVED!!!

@joevt and @iigs123, thanks so much for all your help! I was poking around all the pins that should have the BDb29 data line and noticed something odd. Pin 1 of RP6, which has BDb29 was somehow shorted to pin 16. Looking at the schematic, that shouldn't be because pin 16 is the +5v line. That certainly seems like it could be the source of my problems. So, I started following the traces of that line and not surprisingly, one of the traces was one of the ones I had damage removing the SIMM slot. And apparently while I had made sure the two vias were connected, I didn't check other pins around the area to ensure the damage hadn't shorted the traces to other lines. And what's right next to that trace to pin 60, the +5v lines going to pin 59...

Anyway, I was able to clear the short, and pins 1 and 16 on RP6 were no longer shorted, so I fired it up. And the video is perfect now. In addition, I can use slots 2 and 4 of the memory again. I also suspect I could repopulate the on-board RAM chips and get my 8MB of on-board memory back.

Really excited to have this working. Planning on trying to put it into the shell of a Quadra 800 I got that was absolutely destroyed by the battery.

Here's the pre-cleaned base of the case for an idea of how bad it was:

 

[iigs123]

well done! you've given me more confidence to get my Q610 working!