I feel sorry for the French too ... but

[emmanuelf]

First, thanks to ChildOfCv for his astounding work on the French SECAM 2600 PCB/schematic

 

 

The  VCS was a dream when I was young, but it was for others ... we did not have TV at home (my parents choice) so my first Atari was an STE years later.

Now I'm old so I could get my dreams

 

I've got a SECAM 2600 but was barely knowing its specificity : only 8 (artificial) colors and more than 60% of the surface covered by the electronics dedicated to the BW to 8 SECAM color encoding with discrete logic.

 

I'm from the digital electronic age, so it took me time to dig into the old analog standards.

Here is a resume of my findings that I did not find in a single place:

 

NTSC TIA/NTSC console use only one crystal because TIA and the 2600 where completely designed for NTSC.

All is designed around the 3.579545 MHz frequency which is the NTSC color burst frequency/sub-carrier.

With a divide by 3, TIA provide the CPU clock : 1.193181MHZ

And on NTSC, the color sub-carrier is defined as 455/2 x line rate(15.734 Khz), witch permit line (and pixels for the TIA) frequency generation with cascaded integer dividers (5x7x13).

TIA has an horizontal resolution of 228 color clock (blanking included)

Clearly you could see that 455/2=227.5 ~ 228 the pixel clock = color sub-carrier frequency = main crystal

On the 2600, frame rate/line per frame is controlled in software by the CPU at TIA ticks (sync between the TIA and the CPU)

 

Next come the PAL TIA/Console.

The PAL system has a color sub-carrier frequency of 4.43361875MHZ

The color sub-carrier is defined as 283.75 colour clock cycles per line plus a 25 Hz offset to avoid interferences  : 283.75 × 15228625 Hz + 25 Hz

We could see that the pal colour cycles are ~5/4 of 228 TIA standard pixels clock per line.

 

So what is a PAL TIA ?

This is simply a NTSC TIA (Luma generation is exactly the same) with an external pin for the oscillator for the chroma generator as we could no longer use the main oscillator and a minor adaptation on the  chroma generator for the pal color encoding (a 180° color signal phase rotation on each line). As the oscillator is now external, we have the pal-S/900khz-out pin too to drive it.

To match the TIA 228 color pixel clock per line we need to respect a 5/4 ratio between the main TIA clock and the color generator clock.

We get:

4.433618MHZ => crystal for the pal color generator

4.433618MHZ * 4/5 => 3.546894MHZ => main crystal of the TIA

3.546894MHZ/3 => 1.182298MHZ=> CPU clock

 

And what is a SECAM 2600 ?

Well, looking at the schematic from ChildOfCv, we see that the TIA is only used for luma generation.

8 Secam Chroma mapped on the 8 luma values.

The secam chroma generator use a 4.453125Mhz crystal witch is still driven by the 900khz output => pal/secam/ntsc sync and color sync logic is the same or mostly compatible (At the TV, not for on the air RF....)

Remark here: as the NTSC TIA does not have the 900khz output, another trick is surely used on first SECAM models (pin 6 BLK* ?)

With the applied previous logic, to respect the 4/5 ratio, main TIA crystal should be 3.5625Mhz Bingo ! it is !
And the CPU clock is 1.1875MHZ, slower than NTSC console but faster than PAL ones !

 

For 2600 SECAM model to PAL conversion we need to (it was my first motivation):

- rewire the BW/Color switch to the CPU => on the SECAM version, the swich drive the SECAM color generator, and the cpu bw/color info pin is grounded.

- feed the pin 8 with the output of the 4.453125Mhz Oscillator (r278/r2800/q208) which is exactly the same as the PAL one.

- change the two crystals (I suspect that it should work too without the change).

- add the 1k pullup to the col signal

- add the color adjustment circuit with the voltage elevator on the osc (as the original 2600(not A) NTSC or PAL version)  : one pot, two diodes and tree caps.

=> now you could add a s-video/composite mod like the UAV and voila.

 

The more interesting part :

With the Tim Worthington RGB mod and a modern programmable clock generator plugged in place of the crystals you could have a true multi-standard 2600, with RGB/PAL or NTSC s-video and composite, at PAL/NTSC or SECAM CPU speed (will need some adjustments on the RGB board). For the sake of preservation, add a few gates to rewire on the fly the console in PAL or SECAM and add a 8 color SECAM RGB out.

A single board to do it will be a future project.

Will report here if something work/progress.

 

[ChildOfCv]

27 minutes ago, emmanuelf said:

So what is a PAL TIA ?

This is simply a NTSC TIA (Luma generation is exactly the same) with an external pin for the oscillator for the chroma generator as we could no longer use the main oscillator and a minor adaptation on the  chroma generator for the pal color encoding (a 180° color signal phase rotation on each line).

This is one thing I wonder about.  Does it really do a phase rotation?  PAL expects 135 degrees for one color burst and 225 degrees for the alternate one.  So that's a 90 degree shift and a bit more difficult to implement.  I wonder if, instead, it just outputs the same 0 degree color burst and lets the TV interpret each line however it pleases?  Maybe that would explain why the PAL palette seems to spin so weirdly around the color wheel in contrast to the NTSC one.

[emmanuelf]

Yes it is possible. I was only exposing the theories as I still not look at it physically. But as the pal TIA look to me more and more as a simple quick hack of the NTSC one, you are surely right.

One interesting experiment would be to find a scheme to rewire a PAL TIA to generate NTSC. On a PAL console, we should not be too far with simply exchanging the crystals with two NTSCc ones.

[ChildOfCv]

Actually, looking at the palette again and comparing it with the color wheel, it begins just left of top, then alternates right and left while slowly rotating down each side of the wheel.  The even colors rotate counterclockwise from the top, and the odd colors rotate clockwise from the top.  So a revised hypothesis goes like this:

 

The lowest color bit determines which frame shows color (only one does for a specific color on any given pass).  If the color value is even, only the reverse-polarity frame will output its color value.  If the color is odd, only the positive-polarity frame will output color.  The remaining bits divide 180 degrees into sections in order to output a color.

 

This would fit the behavior pattern, but would also limit the saturation of colors since they always average with a shade of grey.  As for a way to test that, if you have an oscilloscope that can sync on video frames and fields, then you could have something that shows a solid color and sync on either the even frames or the odd frames, starting at least 30 lines down or so, and see if there is color subcarrier in both frames.

 

It is obvious, though, that the lowest bit chooses which half of the color wheel to use.

Edited November 20, 2019 by ChildOfCv

[emmanuelf]

I put it on my todo list. Yes I could choose the frame/fields and the line to sync on on my scope.