Shape of the output signal on TIA pin

[Windless]

2 minutes ago, ChildOfCv said:

Well, rev 8 did add a chip.  The changes may be small, but they're probably not going to be trivial.  They also like to renumber the parts between versions too.  So I'd say go for it, though rev 7 should provide guidance.

ok, I'll try, and probably learn a lot
 

Did you desolder all / most / some chips to do your schematic ?

[ChildOfCv]

Just now, Windless said:

ok, I'll try, and probably learn a lot
 

Did you desolder all / most / some chips to do your schematic ?

Yeah, the logic chip cluster and the two lower small ones.  The larger chips were already socketed so it wasn't as big a problem.  I also desoldered the cartridge port so I could see the traces there.  Everything else was just chasing things down.

 

Well, the logic chips were also socketed, but the socket still covered most of the traces so I needed to get them out of the way anyway.

[Windless]

Ok. I'm rather slow on making the schematic of my Rev8 board. In the mean time I tried to understand things about the generation of the hue and saturation signals on the TIA COL pin.

 

If I understood correctly:

 

-On the NTSC 2600, the clock on the TIA is the same as the color burst frequency (3.579545MHz) (228 clock per line, 262 lines per frame, 60 frames per second -> 228*262*60=3584160, 0.13% error)

-The TIA generates the HUE by outputting the CLOCK input on COL, but it shifts it depending on the hue part of the color number (that is color/16 see color chart). The amount of shift is (7 + hue) * clock_period/16, that means that colors $2x will have a shift of 17.460ns more than $1x

 

We often see this kind of drawing when looking for information about NTSC encoding :

But in the case of the NTSC TIA where pixel frequency is the same as the color carrier frequency, it means that we would have only one oscillation on each pixel (or in this picture, we draw five consecutive pixels of each color). And the signal output by the TIA is probably square and not sinus.

 

Now on the PAL TIA, the clock is 3.546894MHz, when the color carrier is 4.43361875MHz.

 

I have two hypothesis here:

-if the *16 clock used to shift the clock 16 times per clock to generate the 16 possible outphasing is generated from the the TIA' clock, on the PAL TIA it would give a 56.795104MHz clock. With respect to the 4.43361875Mhz frequency of the PAL color carrier, it would mean the the outphasing would be 0 to 12.8/360°,that would be 12 different hues plus grey. Indeed, with 8 luminance-saturation per hue in the palette, it makes 13*8 = 104 different colors on the PAL 2600

-if the delay for the 16 possible shifts is independent of the clock, and fix at 17.460ns * (color/16), it would range from 0 to 262ns. So the shift would be from 0° to 360*1.1616... out of the 15 possible valued, the 13 first colors would be different, then we would wrap around 360°... that would also give 104 colors.

 

Something I don't understand is why the color are in different order with the PAL TIA. Maybe it is because :
-the shift is not 1/16period per color but 9/16 for some reason I don't get (so we have a +180° rotation on each line of the palette)

-the inside of the PAL TIA has been weirdly designed where the color<->shift mapping is made*

-this is related to the PAL encoding that shifts the phase 180° for each line. On the PAL TIA this shift would be made not only on the odd/even bit of the line number, but on this bit XOR the heavy weight of the color, for some reason I can't understand.

 

Windless.

 

* : seems unlikely. Add they made a different "color select decode" (see sheet 5 on https://atariage.com/2600/archives/schematics_tia/index.html), it would have been easy to match the NTSC palette with at least a good approximation

Edited October 15, 2019 by Windless

[ChildOfCv]

1 hour ago, Windless said:

But in the case of the NTSC TIA where pixel frequency is the same as the color carrier frequency, it means that we would have only one oscillation on each pixel (or in this picture, we draw five consecutive pixels of each color). And the signal output by the TIA is probably square and not sinus.

On the Atari, the CPU clock is closer to 1.1MHz, and resolution is halved from the TV's theoretical horizontal.  Remember that CRT TVs don't have actual pixels.  They have color screens specially stamped to make sure that the green gun can only strike green phosphors, blue to blue, and red to red.  But in the days before color, it was just a solid phosphor coating and a continuous horizontal sweep.  "pixels" are simply the fastest that the signal can go from dark to bright to dark again and make a perceptible difference.  It's also limited by the signal bandwidth (4MHz for B/W, and around 2MHz for color).  Anyway, with the Atari's 1MHz clock, it has its own definition of "pixel" and it's a much wider portion of the screen.

 

The output from the TIA is a square wave, but it gets filtered by an RC tank before mixing with the luma signal.  So it still comes out as a sorta-sine-wave.

 

1 hour ago, Windless said:

I have two hypothesis here:

-if the *16 clock used to shift the clock 16 times per clock to generate the 16 possible outphasing is generated from the the TIA' clock, on the PAL TIA it would give a 56.795104MHz clock.

You have a misunderstanding, sorta.  The TIA does not have a clock divider in the sense you might be thinking of.  What it has is a delayed shift register that gets the color oscillator running through it.  The shift register has 16 stages, and the delay pot adjusts how fast it propagates through the registers.  The aim is to make sure a full cycle is visible across the shift registers.  A color is picked by simply taking the output from one of those registers to get the appropriate phase shift.

 

1 hour ago, Windless said:

Something I don't understand is why the color are in different order with the PAL TIA.

PAL and NTSC are different in their interpretation of phase shift.  PAL expects the phase shift to be negative of what it was on the previous line if it's the same color (Phase Alternating Line).  This is how PAL avoids the color artifacts that NTSC gets.  If your oscillator is drifting, the alternating phases cause it to average out.  As such, the PAL color burst reference is supposed to be 45 degrees on one line and 135 degrees on the other.  On NTSC it's always 0 degrees.  I've wondered how the PAL TIA does this, but the answer may be that it always outputs a 0 degree signal, and lets the TV's phase shift it to determine the displayed color.  That may explain why the palette is reduced.

[Windless]

Thank you, I think I now have a better understanding of the shift register (which is my second hypothesis + the delay pot hat I thought added delay but in fact changes the shift speed) I also read this in the meantime which helped.

 

9 minutes ago, ChildOfCv said:

PAL and NTSC are different in their interpretation of phase shift.  PAL expects the phase shift to be negative of what it was on the previous line if it's the same color (Phase Alternating Line).  This is how PAL avoids the color artifacts that NTSC gets.  If your oscillator is drifting, the alternating phases cause it to average out.  As such, the PAL color burst reference is supposed to be 45 degrees on one line and 135 degrees on the other.  On NTSC it's always 0 degrees.  I've wondered how the PAL TIA does this, but the answer may be that it always outputs a 0 degree signal, and lets the TV's phase shift it to determine the displayed color.  That may explain why the palette is reduced.

I still don't get something. Imagine I wanted a simple solution for this problem :

-I'd reorder the output of the Color Select Decode part of the TIA so color $2x, $4x, $6x, ..., $Cx would cover hues 0..154° and colors $3x, $5, ..., $Dx would cover 180..334°.

-I would have a bit that toggle on each line (0 for odd lines and 1 for even lines) and XOR this bit with the first color bit on the Color Select Decode, so every color would get shift +-180°

 

This could also work with another bit of course. The problem would be with $0x (greys) that became $1x (color) and vice versa. Easy solution would be to make $1x color also grey, and the PAL TIA would lose 8 colors.

The PAL TIA does lost the $1 colors, but:

-Toggling first bit doesn't help anyhow finding the +-180° color in the TIA's palette

-It also lost colors $Cx and $Dx

 

Now if we make a graph of the HUE (in °) vs higher nibble of the color, we get something like this (all graphs should be labelled from 0 and not from 1 on X axis):

the shape seem to have two different logic:

-we have an alternation of growing and  shrinking levels

-for the first three value, the order seems to be reversed.

 

alternating sizes of the bars tell us that it's not the lower weight bit that is XORed but the higher weigh one, so on odd lines, color 0 is swapped with color 15, 1 with 14, 2 with 13, ...

The "reverse order" of the first three bars can be explained if we guess that the hue has just wrapped around the 360°. Let's add 360° to bars for colors $3x and $5x:

 

 

 

That seems ok. The HUE for odd values seems to be : (3.5 + Cn) * 14.5°

For even line, we toggle bit 15 and add 180, so this becomes 14.5*(BITXOR(15, Cn)+2.5)+180°

Where Cn is the higher color nibble (top four bits) of the color number.

 

Color with nibble 0 is swapped with colors with nibble 15, but since it is greyscale it must not change, so colors $Ex need to be replaced with greyscales.

 

Now, why does the yellows ($1x) disappear (together with the pair $Dx) ?

What we know from the NTSC TIA schematic is that color $1x don't get any delay from the color phase shift delay. It might be possible that the XORing takes some time and some delay is required. Indeed if I remember correctly, the color $2x on the PAL secam is not yellow (as $1x on NTSC), the first colors ($2x) have nearly the same hue as $2 on the NTSC. It still would be possible to have colors $Ex, but then on even lines they would appear as grey. And if someone use the grey $1x, thy would get the color of $Ex on even lines. So they had to suppress it.

 

Is this model likely to be true ?

 

[ChildOfCv]

1 hour ago, Windless said:

Easy solution would be to make $1x color also grey, and the PAL TIA would lose 8 colors.

Actually, the solution is even easier than that:  White and black output no color component at all.  This is because the phase control is for differences from white, one in the red-green direction and another in the blue-yellow direction.  If you look at the color wheel, you'll notice no white or black.  That's at the center.  White is full saturation with no color shift, and black is no saturation.  So when it's a shade of gray, the difference in both directions is zero.  On the internal schematic for the TIA, white and black are not connected to the color output.

Edited October 15, 2019 by ChildOfCv

[Windless]

1 hour ago, Windless said:

Now, why does the yellows ($1x) disappear (together with the pair $Dx) ? 

 

 

Something else just came to mind:

If the delay is the same on PAL tia as it is on NTSC, then color adjustement potentiometer would only increase delay between the cells of the color phase shift delay. So instead of having e.g. 0°, 15°, 30°, ... for colors $1x, $2x, $3x, ... you could get 0°, 16°, 32°, ... This would work on NTSC, but on PAL if what I guess about the XORing on odd line is true, that means that if you add by adding 1° per cell, colors $Ex would get 13° shift when $1x would only get 1°, which means that the phase shift between them would go from 180° to 193°. Maybe the delay pot works differently (e.g. adjust only the first color) and this has some impact on the possibility to display 0° colors, hence leading to suppression of color $1x and $Ex ?

 

Anyway, this would be a good way to test if the colors are indeed XORed on even lines : either the col adj pot adds the same delay on all cells (and that would partially confirm the hypothesis), or it works as on the NTSW TIA and then adjustment of colors would not be the same for ODD and EVEN lines.

[ChildOfCv]

The delay pot is connected to the gate of a transistor on every cell of the shift register.  It definitely determines the speed of propagation throughout the entire register.  And you need that anyway.  NTSC has a 3.58MHz modulator.  PAL has a 4.43MHz modulator.  So you need them to have different propagation rates in order to make the square wave complete across the number of color cells.  But each cell should represent an equal portion of 360 degrees regardless of standard.

 

Remember that during the blanking period, the square wave is fed out directly through the color output (the color burst).  The other colors are phase-compared with the burst signal to determine the actual color.  On NTSC, the burst is 90 degrees and represents negative blue (yellow).  On PAL the burst is 45 degrees on one line and 135 on the other.  My hypothesis is that it does not bother flipping a bit to change the actual phase, but instead accepts that you'll be combining two colors because you're outputting from the same register on each line, and on alternating lines the same register means something different.  You noticed that you lose a color or two in that setup, and indeed the PAL palette is smaller than the NTSC palette.  So that actually seems to confirm my suspicion.  You'll also notice that the PAL palette has an unnatural progression, which fits your observations.  That also seems to confirm my suspicion.

 

[Windless]

1 hour ago, ChildOfCv said:

It definitely determines the speed of propagation throughout the entire register.

Do we have schematic of the PAL TIA ? I couldn't find one so I'm trying to random guess lot of things .

1 hour ago, ChildOfCv said:

PAL has a 4.43MHz modulator.  So you need them to have different propagation rates in order to make the square wave complete across the number of color cells.

Ok

1 hour ago, ChildOfCv said:

My hypothesis is that it does not bother flipping a bit to change the actual phase, but instead accepts that you'll be combining two colors because you're outputting from the samore register on each line, and on alternating lines the same register means something different.

I am not sure I understand. My hypothesis was that the color register (left part of sheet 5) contains the same value, but that the bit are XORed before being used to selected the Color Phase Shift Delay cell on odd lines.

From what you tell, I think (and it's very likely since it would be simpler and would work) that they probably just delay or NOT the color burst and leave the COL signal the same. But I don't understand how that would explain the need to remove 3 lines of colors nor to loose the possibility to have a 0° color ?

 

On the other hand, some sources say the phase is reversed on odd/even lines, but some indicate (as you do) that they are 90° rotated. With 90° rotation, I can't explain the organisation of the PAL palette.

Edited October 15, 2019 by Windless

[ChildOfCv]

I'm suggesting that the possibility that they don't even delay the color burst.  Let the TV interpret it however it will, but we always pretend we're sending the same phase.  For a PAL TV, the actual colors displayed would depend on mixing two different interpretations of the same relative phase.  Perhaps averaging between two cells causes duplicate colors.  So maybe removing 3 registers redistributes the color wheel in a way that has fewer duplicates.

 

I'd like to see the PAL schematic, but I have yet to locate one either.  Maybe they will be discovered eventually on one of the Atari tapes.

[Windless]

ho,ok. This would be testable with a fast oscilloscope. I'll try with mine (maybe pushing it a bit) when I'm done with the schematic and I can resolderparts andtry to feedthe TIA with a PAL-I signal

[WhyLee commotari.club]

Clarification on PAL systems in the 2600:

 

Oscillator frequency:     3.546894 MHz
CPU frequency:            1.182298 MHz ==> Osc / 3
PAL subcarrier frequency: 4.43361875 MHz ==> (Osc * 5)/4

Does that mean that the TIA has an integrated PLL that can do a multiplication of the frequency by 5 ===> 22.734470 MHz ??
I am not sure how the shifts for the COL signal is being implemented. Either in different steps of delays, or in combination with OSC*5.
But I think that a chip of 1978 would have difficulties to handle complicated things with over 22MHz on a digital level.
 

[RevEng]

52 minutes ago, WhyLee commotari.club said:

Clarification on PAL systems in the 2600:

[...]

There are two crystals in a PAL 2600, 3.54 MHz and 4.43 Mhz.

[WhyLee commotari.club]

51 minutes ago, RevEng said:

There are two crystals in a PAL 2600, 3.54 MHz and 4.43 Mhz.

oooh. i guess that was the preferred solution instead of using a PLL. maybe PLL chips where not available in 1978, or very expensive.
i just looked into the circuit. it looks different than the differential amplifier main oscillator for the pixel clock. almost like a filter circuit too. from this circuit alone, i cannot judge, if this is only an oscillator circuit, or if it does something else (filtering a signal).

 

[Windless]

I am starting to work again on this investigation* but still don't have access to a working TIA 2600.

Could someone upload an oscilloscope trace** of PALI, PALS, and COL for a full line of this rom ?

 

Thank you,

W.

 

* : just for curiosity, I don't expect anything coming out of it

** : data export, not just screen captures

 

pal colors.a26

Edited Saturday at 01:51 PM by Windless