PAL GTIA hardware details

[dmlloyd]

I was wondering if anyone might know some specific details about the PAL GTIA. The data sheets that are out in the wild seem only to cover NTSC. Here are my questions:

1. From the schematics of various Ataris, it appears that the PAL pin acts as an input (?) for the PAL color carrier frequency line. Is this right?
   
2. From my understanding, PAL switches color polarity every line and indicates this via changing the polarity of the color burst. Does the PAL GTIA do this? Does this manifest as every other line having inverted hue (i.e. 15-hue), or shifted hue (i.e. 7+hue%15), or what?
   
3. Is the PAL color palette really substantially different from NTSC?
   
4. On NTSC systems, the color clock (one gr.7 or 15 pixel) is 279.4 nS long. For color pixels (hue != 0), the COLOR line goes low at one of fifteen possible times, and the delta between each possible color can be (depending on the CADJ voltage level) anywhere between 16 to 35 nS (that's according to the various data sheets; though only values on or slightly below 18.6 nS would make for "correct" color output, as anything beyond that would result in higher color values bumping into the next pixel). On PAL systems, how does this timing work? Is it relative to the color carrier (PAL line?), or OSC like NTSC? If it's relative to the color carrier, does that mean the possible delay values are much shorter than 16-35 nS?
   
5. Does anyone have any real-world timing measurements for PAL GTIA, or know of a PAL GTIA data sheet?
   

Thanks in advance...

[Rybags]

1. That's right - Pal uses the ~ 4.43 MHz colourburst which isn't a direct ratio of the master clock like on Ntsc machines.

 

2. Unsure how the colourburst swing is achieved. Since it runs at 5/4 the speed of the Ntsc colour clocking, it would drift out of sync per scanline regardless of Pal needs. Something inside or outside of GTIA acts upon the phase shift, and I think it happens each time a HSync is generated - noting that we can generate HSyncs with software thanks to the bug in Antic which allows graphics to be generated outside the normal 240 scanline display, re "Scanline 240 bug".

 

3.The colour difference is variable per colour. Probably worst is colour 4 which is usually red on Ntsc but typically purplish on Pal. Colour 10 on Pal is bluish green but sometimes seems to be assumed as greenish blue on Ntsc.

Regardless, the palette isn't hardwired into GTIA, the colour is a result of the phase shift introduced to the colour signal which can be affected by the trimmer pot. The actual palette differences of Pal/Ntsc are more the fault of the difference in those standards than anything that GTIA might be doing.

 

4. Not sure the colour delay has anything to do with the clocks themselves. The colour delay on both would be adjusted on ~ 3.59 MHz boundaries but the delay itself might be a physical delay as a result of the electronic circuit used for the delay pads, and tuned to be near enough to 1/16th steps of the colourburst cycle.

 

5. What timing measurements would be relevant? The operation vs Ntsc should be much the same except for swinging colourburst and slightly longer scanline time for Pal.

[dmlloyd]

Thanks for replying, that clarifies a lot. According to the GTIA data sheet, the color signal triggers relative to the trailing edge of the OSC input, which makes sense for NTSC but just seems weird for PAL where the relationship makes less sense, though since the color info comes from a source that's timed to OSC I'm not sure what else it could do. Does that mean that there is some kind of visible artifact that repeats every 5 pixels?

 

The timing info I'd be looking for is basically what COLOR does relative to OSC for each of the 15 colors, I guess.

[Rybags]

I'm just assuming here, since it's seems the logical way:

 

I don't think Pal Gtia uses the Pal clock input for any of it's timings - the 160h pixel boundaries are where you want colour changes taking place and they're directly relative to the "Osc" input.

 

Also I think that the actual colour output of Gtia is simply a square wave - it's up to the external circuitry to make a nice sine curve out of it.

 

ijor would probably be the one to clarify a lot of this stuff - I've measured various aspects of the video output but never really looked into colour generation.

[Kr0tki]

4. The way the hues are computed in PAL GTIA is rather complicated compared to NTSC, and not fully understood. In NTSC it's quite simple - the delays between phases of each consecutive hue are always equal. In other words, a function to compute angle of each hue in the YUV colourspace is something like

 

angle[hue] = 180 - (hue - 1) * pot

 

where hue is 1..15, and pot is the setting of the colour potentiometer.

 

With PAL the function is way different. PAL GTIA produces different colours in odd and even scanlines. This is not normally noticeable, since chroma blending of a PAL TV averages chroma signals of each two consecutive scanlines, but it can be seen nevertheless. Consider the following program:

 

10 GRAPHICS 11
20 FOR C=0 TO 15:COLOR C
30 FOR Y=0 TO 11 STEP 2:PLOT 0,C*12+Y:DRAWTO 79,C*12+Y+1:NEXT Y
40 NEXT C
50 GOTO 50

On PAL the left side of the screen will produce a different set of 15 hues than the right side.

 

So, for PAL we have two different functions to compute hue phases - one for normal ("NTSC") lines, the other for phase-alternated ("PAL") lines. The functions themselves also are not as straighforward. Based on my playing with my unit's colour pot and examining screenshots of my cheap TV capture card, I came up with the following formulas (based on the ones in the Altirra emulator, but with different coefficients) - for even lines:

 

multis[0..14] = { -2, -3, 3.5, 3, 2, 1, -0.5, -1, -2, 3, 2, 1, 0, -1, -2 }
shifts[0..14] = { 180, 180, 0, 0, 0, 0, 0, 0, 0, 180, 180, 180, 180, 180, 180 }
angle[hue] = shifts[hue - 1] + pot * multis[hue - 1]

 

and for odd lines:

multis[0..14] = { 1.5, 2.5, 3.5, -1.5, -0.5, 0, 1.5, 2.5, 3.5, 4, -2.5, -1.5, -0.5, 0.5, 1.5 }
shifts[0..14] = { 180, 180, 180, 0, 0, 0, 0, 0, 0, 0, 180, 180, 180, 180, 180 }
angle[hue] = shifts[hue - 1] - multis[hue - 1] * pot

 

I wish I had access to a vectorscope - I would be able to get more accurate formulas, as the above ones are only approximations.

Edited October 12, 2012 by Kr0tki

[dmlloyd]

Assuming that there's a direct ratio between phase angle and signal delay time (as you mention, COLOR is a square wave), are you saying that the PAL hue phase angles output by GTIA are non-linear?

[Rybags]

I would think the steps should be the same. But there's 4 pads involved in generating the delay and possibly each pad isn't necessarily exactly double the value of the next lowest one.

[ijor]

The way the hues are computed in PAL GTIA is rather complicated compared to NTSC...

Based on my playing with my unit's colour pot and examining screenshots of my cheap TV capture card, I came up with the following formulas ...

 

That's interesting. But I understand you checked the modulator output, not the output directly from the GTIA pins.

 

As far as I can see in the GTIA original (barely readable) schematics, there is no such thing as different output for odd or even lines. Just the use of the PAL input signal as the phase delay base. The schematics have a reference pointing to the STELLA (TIA) Pal schematics. Unfortunately, the avalaible TIA schematics seem to be NTSC only.

[Kr0tki]

I used separate chroma/luma outputs, so no modulator involved here.

[Creature XL]

Little side track, as i do not want to negro bump another thread.

 

The routine gives wrong values for me (and the picture is looks also wrong). Hue "3" (red) is a good example.

 

http://www.atariage.com/forums/topic/107853-need-the-256-colors/page__st__25#entry1312471

 

Were there published better routines/parameter in the mean time?

[Bryan]

Little side track, as i do not want to negro bump another thread.

What's negro bumping? It doesn't sound very nice.

[Creature XL]

What's negro bumping? It doesn't sound very nice.

Ouch. I ment "necro bump"!

 

For what ever reason I cannot edit that post any more. So if a mode can edit it?

[Kr0tki]

The routine gives wrong values for me

Yeah, Olivier's PAL routine is way off.

 

Were there published better routines/parameter in the mean time?

Read this thread thoroughly.

Edited October 26, 2012 by Kr0tki