400 - strange graphics issue

[drpeter]

11 minutes ago, Rybags said:

OK, I see.  What we need now then - modify my original program and put a graphics character in place of the zero in line 40.

I might suggest try CTRL-Y there - that should show PF1 for 4 pixels then PF2 on 4 pixels in the top scanline.

Yeah. Although, comparing a still from the video showing ROM data with the emulated equivalent from Altirra clearly shows that the top line of each character displays correctly on a badline, followed by data from character $FF on every other line...

So I think we have this nailed down.

 

 

 

 

[spacedmonkeys]

I will type the original program back in when I get chance, with a graphics character in line 40.

[phaeron]

You could try this as well, this program draws a series of vertical stripes in GRAPHICS 7 (160x96 4-color) and changes the screen to wide hscrolled, slowly incrementing the hscroll value. In theory, we should see corruption in the bottom half of each line on the broken cell since the line buffer is also used in bitmap modes. It'll glitch momentarily every time the scroll increments, that's normal since BASIC is too slow to synchronize properly.

 

10 GRAPHICS 7
20 FOR X=0 TO 79
30 COLOR X
40 PLOT X,0:DRAWTO X,79
50 PLOT X+80,0:DRAWTO X+80,79
60 NEXT X
70 DL=PEEK(560)+256*PEEK(561)
80 POKE DL+3,93
90 FOR I=0 TO 78:POKE DL+I+6,29:NEXT I
100 POKE 559,35
110 FOR I=0 TO 15
120 POKE 54276,I
130 FOR X=0 TO 500:NEXT X
140 NEXT I
150 GOTO 110

 

I looked over the ANTIC re-schematic again, and it does look like the ram cells are read on alternate cycles from the precharge+write... so my armchair IC engineer guess is that with the blown cell the data is being held on the internal RAM bus by capacitance from the write cycle, and then on the subsequent lines there is no write so the precharge sets the internal RAM bus to $FF.

 

[spacedmonkeys]

3 hours ago, phaeron said:

You could try this as well, this program draws a series of vertical stripes in GRAPHICS 7 (160x96 4-color) and changes the screen to wide hscrolled, slowly incrementing the hscroll value. In theory, we should see corruption in the bottom half of each line on the broken cell since the line buffer is also used in bitmap modes. It'll glitch momentarily every time the scroll increments, that's normal since BASIC is too slow to synchronize properly.

 

10 GRAPHICS 7
20 FOR X=0 TO 79
30 COLOR X
40 PLOT X,0:DRAWTO X,79
50 PLOT X+80,0:DRAWTO X+80,79
60 NEXT X
70 DL=PEEK(560)+256*PEEK(561)
80 POKE DL+3,93
90 FOR I=0 TO 78:POKE DL+I+6,29:NEXT I
100 POKE 559,35
110 FOR I=0 TO 15
120 POKE 54276,I
130 FOR X=0 TO 500:NEXT X
140 NEXT I
150 GOTO 110

 

I looked over the ANTIC re-schematic again, and it does look like the ram cells are read on alternate cycles from the precharge+write... so my armchair IC engineer guess is that with the blown cell the data is being held on the internal RAM bus by capacitance from the write cycle, and then on the subsequent lines there is no write so the precharge sets the internal RAM bus to $FF.

 

 

Video results of this one:

 

 

[spacedmonkeys]

16 hours ago, Rybags said:

OK, I see.  What we need now then - modify my original program and put a graphics character in place of the zero in line 40.

I might suggest try CTRL-Y there - that should show PF1 for 4 pixels then PF2 on 4 pixels in the top scanline.

 

 

Video results of this one:

 

 

[phaeron]

44 minutes ago, spacedmonkeys said:

Video results of this one:

Think you had a typo due to the diagonal lines, but no matter... the alternating blue lines are confirmation of what's going on:

 

 

That's PF2 from the $FF bytes on the odd lines where the line is being replayed from the line buffer. So good data is definitely coming through on the badlines, and then the data goes missing on the subsequent scan lines.

 

 

[spacedmonkeys]

2 minutes ago, phaeron said:

Think you had a typo due to the diagonal lines, but no matter... the alternating blue lines are confirmation of what's going on:

 

 

That's PF2 from the $FF bytes on the odd lines where the line is being replayed from the line buffer. So good data is definitely coming through on the badlines, and then the data goes missing on the subsequent scan lines.

 

 

 

Yes I had long forgotten how bad typing on this 400 keyboard is.  Not helped by it bubbling due to a tiny split near the ":" .

So are we concluding Antic has gone bad, and not RAM? I have a quote from "Best" for this one and one for my XL.

[Rybags]

For sure it would be Antic.  If bad Ram was producing similar symptoms you'd expect the distance between each corrupted cell to be a power of 2 - though if Ram was that bad the computer probably wouldn't even power up successfully.

[_The Doctor__]

These are good tools for a program based diagnosis suite. Continuing further with more test programs of this nature tailored to each chips failure modes would indeed be useful. Nice job all!

[spacedmonkeys]

On 4/17/2024 at 11:52 AM, Rybags said:

For sure it would be Antic.  If bad Ram was producing similar symptoms you'd expect the distance between each corrupted cell to be a power of 2 - though if Ram was that bad the computer probably wouldn't even power up successfully.

 

New Antic chip arrived from the USA.

 

Fitted today .. the "glitch" is now gone.

 

Hoorah.

 

Thanks for everyone's help with this!