GTIA decap

[ijor]

GTIA chip decap (NTSC version)

 

Once again, thanks to Greg James and the people at Visual 6502 for the physical decap, die shooting and image stitching. Thanks to Bryan for donating the chip. Reverse engineered schematics coming soon.

 

 

Rough floorplan:

 

[ijor]

There seems to be a small bug in the chip layout. One inverter in the color delay chain seems to be shorted to ground. This might affect the exact hue of the two last colors, colors 14 and 15 (called Organge Green and Light Orange in the GTIA datasheet).

 

The cells in the color delay chain have one inverter with the output disconnected. The purpose of this inverter is just to provide capacitance for the RC delay of each chain. The output of this inverter on the 14th cell of the chain seems to be shorted to ground by mistake. This shouldn't affect the digital logic, because as said, the inverter output is disconnected. But this should likely change the capacitance, and hence might affect the actual delay of this cell. And because this is a chain, any change in the delay will affects also other cells coming after this one (only one in this case).

 

I don't know how much significant this is (how much the delay, and hence the color output, would be affected). And I can't be 100% sure if the inverter is actually shorted. Probably this is for the NTSC version only.

[+Stephen]

Thanks so much for doing this and posting the work.

[fox]

:thumbsup: Looking forward to the schematics.

[fibrewire]

There seems to be a small bug in the chip layout. One inverter in the color delay chain seems to be shorted to ground.

The capabilities and skill sets of forum users never cease to amaze me!

[Kr0tki]

There seems to be a small bug in the chip layout. One inverter in the color delay chain seems to be shorted to ground. This might affect the exact hue of the two last colors, colors 14 and 15 (called Organge Green and Light Orange in the GTIA datasheet).

I've once analysed several screenshots of NTSC Ataris and hues 14 and 15 weren't affected by this issue in any noticeable way - the delay between all consecutive pairs of hues was always the same.

Edited August 23, 2011 by Kr0tki

[ijor]

I've once analysed several screenshots of NTSC Ataris and hues 14 and 15 weren't affected by this issue in any noticeable way - the delay between all consecutive pairs of hues was always the same.

 

I see, interesting. This might mean indeed, that the effect is not significant. I understand from what you are saying that you didn't actually measure the delay. Or you actually scoped the chroma signal?

[Kr0tki]

No, I only played with the screenshots - I broke each screenshot down into Y, U and V components and checked how the resulting values spread around the YUV colourwheel. Not really a precise form of measurement, considering vast amount of distortion that can happen to TV signal between GTIA and the final screenshot, but the results for hues 14 and 15 didn't stand out in any way.

[Rybags]

I think a digital capture direct from the COL pin would be the way to go, using a software trigger to sample each hue value.

[José Pereira]

By the way and once and for all:

"Are the colour1 and colour15 the same? And also their Luminances?"

 

Or not?

Can anyone here with real machines PAL and NTSC answer this, please?

 

 

 

Thanks.

José Pereira.

 

 

(P.s.- by the way, what's the (colour,luminance) to have an Orange fruit on A8?

AND

A Red, clean/normal Red?)

Edited August 24, 2011 by José Pereira

[Rybags]

Col 1 and 15 are similar in PAL but not the same.

 

PAL hues are different to NTSC to begin with, and the colour clock isn't based on the master clock like in NTSC. Regardless of that, the PAL/NTSC colourspace also differs, the colour generated by same phase angle on one won't necessarily match that on the other.

 

Luminence is digitally generated at GTIA level, and the final result will vary among machines because it's generated by resistor ladders, and those and the various other components in the final video circuit tend to have variance around 3-5%

Edited August 24, 2011 by Rybags

[José Pereira]

Col 1 and 15 are similar in PAL but not the same.

 

PAL hues are different to NTSC to begin with, and the colour clock isn't based on the master clock like in NTSC. Regardless of that, the PAL/NTSC colourspace also differs, the colour generated by same phase angle on one won't necessarily match that on the other.

 

Luminence is digitally generated at GTIA level, and the final result will vary among machines because it's generated by resistor ladders, and those and the various other components in the final video circuit tend to have variance around 3-5%

 

 

That is saying that my old defunct computer here on a 'PAL Land' I would get the same colour and the same if, for example:

(1,6) and (15,6) and in all the same other colour1&15 same luminances?

 

 

But on NTSC colour1 are what? Brown? And colour 15?

 

 

 

Is it possible someone could post here a Pallete/Luminances of the two colours that show the differences?

(just for curiosity...)

 

 

I thought these two were something like C16 only have 121 instead of 128 because Black is always Black and doesn't have black+7 Black Luminances. Or it also has?

[Rybags]

The palette comparison has been done multiple times, best to just look for the threads.

 

C16 has only 121 colours because all of the lumas for "Black" are zero. Atari treats black/white as the one colour with a range of lumas.

[+rdemming]

Are there plans to decap the buggy Chinese GTIAs found in European 800XEs to see what is causing the GTIA modes bug?

 

Robert

[slampam]

Is this also the 5200's GTIA? Replacement GTIAs for the 5200 have a "5200 ONLY" stamp.

[Bryan]

I can't imagine why 5200 GTIA's would be any different.

[Rybags]

I didn't think the CTIA even made it into the 5200.

 

It might be the case that the LUM0 line isn't connected on them... does anyone know if 5200 has that line?

[Bryan]

I didn't think the CTIA even made it into the 5200.

 

It might be the case that the LUM0 line isn't connected on them... does anyone know if 5200 has that line?

Yes, 16 shade modes work fine on the 5200.

[ijor]

No, I only played with the screenshots - I broke each screenshot down into Y, U and V components and checked how the resulting values spread around the YUV colourwheel. Not really a precise form of measurement, considering vast amount of distortion that can happen to TV signal between GTIA and the final screenshot, but the results for hues 14 and 15 didn't stand out in any way.

 

Thanks Kr0tki. Yes, if there is any difference then it can't be significant. I was interested in a precise measurement just out of curiosity.

 

Are there plans to decap the buggy Chinese GTIAs found in European 800XEs to see what is causing the GTIA modes bug?

 

We might try, but unless they made a completely new layout, chances that we won't see anything. Most of these chip bugs require probing and physical analysis. Visual inspection is usually not enough to find the culprit (Say, imagine a board made with a trace too thin, or with too much impurities in the conducting material). Does this bug produce a consistent and constant, or more an erratic behavior?

[ijor]

Revese engineered GTIA (NTSC) schematics in searchable PDF format. There are probably still some minor cosmetic issues, but shouldn't matter too much. I suggest checking this together with the original (barely readable) schematics. The "style" is very similar to the original schematics and quite different from the Pokey schematics one.

GtiaReschem.pdf

[Rybags]

Cool.

 

So, from early analysis, do you think there's any unknown exploits available? The "holy grail" that has been previously discussed is the rumoured ability to delay the Col and Luma GTIA modes by one colour clock (which could give a TIP mode with full 256 colours and perceived 160 resolution).

 

Also, with the NTSC chips, do they use the same pin as the PAL GTIA for colourburst clock input, or is it just routed from the normal clock input (since it's the same in their case) ?

[Bryan]

Cool.

 

So, from early analysis, do you think there's any unknown exploits available? The "holy grail" that has been previously discussed is the rumoured ability to delay the Col and Luma GTIA modes by one colour clock (which could give a TIP mode with full 256 colours and perceived 160 resolution).

 

Also, with the NTSC chips, do they use the same pin as the PAL GTIA for colourburst clock input, or is it just routed from the normal clock input (since it's the same in their case) ?

 

Gary, I should send you a NTSC GTIA that displays the behavior if you have an NTSC machine to test it in. I tried to find an external mod that would made any chip do it (timing delay, etc...) but never found it. I think some of the GTIA logic is right on the ragged edge timing-wise.

[Rybags]

I've got the 1200XL.

 

But I don't know if it'd be of any help if the quirk is only unique to a small batch of chips. Although if the glitch is only under certain conditions then it would narrow down the scope of necessary experimentation with "normal" chips.

[Bryan]

I found the glitch because my 800XL did it at room temperature. I was fiddling with PRIOR bits during the blank and discovered that I could corrupt a mode 9 screen. I worked up a demo to display images with alternating lines affected by the mode 10-like shift. Then I discovered it didn't work on other machines and later I found it worked on some machines if the GTIA was heated. It may still be possible to make it more reliable, but I gave up on it after a while. Looked incredible, though.

[sack-c0s]

I've always wondered about how folks read those decaps and make sense of them. Is there any recommended reading out there for someone who has a rough grasp of digital logic and a reasonable amount of time to kill whilst babysitting automated stuff?