On this picture below you can see that the Atari 2600 graphics are rather colourful, and some games like Pitfall! I think use the many shades of each colour and have rather good graphics for the 2600. I have seen a video of that game on youtube and it must have been NTSC or possibly PAL.

My question is kind of twofold. Why is the SECAM palette so garish and ridiculous, and why are there only 8 colours?

enter image description here

  • 6
    This is a comment rather than an answer since I don't know for sure, but I believe: 1) SECAM encoded colours in a fundamentally different way to NTSC and PAL (which is effectively just an improvement on NTSC using similar ideas). 2) This might have been harder to implement in hardware. 3) It was not considered worth trying harder just for the French and Soviet markets. 4) The colours are garish simply because they are red, green and blue maxed out in different combinations. If anyone has more time to do research on this, feel free to steal bits from my comment in their answer. – Muzer Oct 17 '17 at 10:28
  • 2
    I would also be interested to know why it seems to be 7 bits contributing to the colour in all three systems, even though the databus is 8 bits and presumably whatever register in the TIA is too. – OmarL Oct 17 '17 at 11:00
  • I presume the games were recoded for each TV standard then? Otherwise everything on SECAM would have looked incredibly psychedelic... – user3570736 Oct 17 '17 at 20:46
  • @user3570736 it doesn't appear as though they bothered to. Some games are completely unplayable. – OmarL Oct 18 '17 at 3:24
  • 2
    @user3570736 according to some forums I found while answering this question, SECAM consoles were hardcoded to tell the game to use black-and-white mode. So well-behaving games would use distinguishable shades of grey (ie all from the first row), and these would show up as distinguishable colours on SECAM (albeit mega ugly). If a game didn't respect the black and white setting properly (and the shades were rather indistinguishable on a black-and-white set), it also wouldn't work well on SECAM. – Muzer Oct 18 '17 at 9:06

The TIA manages a very large palette on NTSC and PAL systems because it takes advantage of the way that composite colour is encoded: three bits produce luminance, and the colour subcarrier is always exactly the same sinusoid, but four of the other colour bits set its phase.

So for both NTSC and PAL:

  • three bits set the amplitude of one signal;
  • four bits set the delay of another signal; and
  • the two things are summed for output.

To verify this, look at an NTSC colour wheel, and look at which angle each of the Atari's NTSC colours appears. They're just steps around the outside of the colour wheel.

Even PAL suffers a little from the NTSC-first logic; it has 12 hues instead of 15 because the NTSC subcarrier is approximately 12/15ths the frequency of PAL's, and the delay steps are NTSC oriented.

SECAM doesn't work in the same way. Performing a phase shift doesn't actually make any difference — the colour subcarrier is a single channel in frequency modulation, not two channels in quadrature amplitude modulation. Nothing about a SECAM output is determined by phase. The colour-shifts that result from phase errors is exactly what SECAM sought to fix.

So more complicated electronics are required, and the elegant hack of just doing a phase shift isn't available. More logic is required, and Atari did what it was cost effective to do, which is to implement a palette much like the other RGB-oriented machines of the era.

In short: the Atari's disproportionately-good palette on NTSC and PAL systems is because Atari exploited the way QAM composite encodes colour. SECAM does not use QAM. Therefore a much more basic palette, closer to other machines of the era, was implemented.

| improve this answer | |
  • 1
    Thanks, this explains the surprising colour selection in the NTSC TIA palette! – Stephen Kitt Oct 17 '17 at 15:50
  • 1
    Along with the not-that-great PAL one! – Muzer Oct 17 '17 at 16:58
  • It's too bad the Atari didn't simply mix a bit of the chroma signal into the R, G, and B values. That would have increased the number of colors to 15 or 16, in a fashion analogous to the PC video. – supercat Oct 17 '17 at 21:11
  • @supercat - I don't think that was an option. My suspicion is it would have required a complete redesign of the TIA's output stages, whereas the existing PAL and NTSC versions were essentially very minor modifications (I'm not even sure they weren't just a different selection of pins attached to the same die inside the package; I don't know if anyone has done any substantial examination of the chip's internals in order to be sure). – Jules Oct 18 '17 at 5:57
  • @Jules: The TIA's chroma output produces a square wave of some phase for any non-minochrome color value, but doesn't produce a square wave for the "monochrome" ones. Trying to convert phase to brightness might require a little extra circuitry (though probably not much, actually--something as simple as a NAND gate followed by a resistor-capacitor filter might suffice) but simply using present/not-present shouldn't be hard. – supercat Oct 18 '17 at 15:03

NTSC, PAL and SÉCAM are all colour-carrying signals based on existing monochrome transmission signals. This means that colour information has to be added to the existing monochrome signal, without disturbing it (or as little as possible). The missing information is represented as red and blue differentials with regard to the luminance.

NTSC and PAL carry all the colour information in every line, for every pixel. This results in a certain amount of artifacting, especially in NTSC (PAL avoids this to a large extent by halving the vertical colour resolution).

SÉCAM however only carries one of the two pieces of information in every line: alternating lines provide red and blue signals, and the missing information is taken from the previous line, using a delay line (hence the name “SÉCAM”: “Séquentiel Couleur À Mémoire”, or “Sequential colour with memory”). This is troublesome for the 2600’s TIA since the latter can change its colour output on every line, and doesn’t have a framebuffer (or even enough memory to store the previous line and re-use the colour information).

The simplest fix for SÉCAM, which was the last market to be addressed by the 2600, was to make the luminance constant, which allows chrominance to be calculated — Atari had to choose between colour and saturation, and chose colour. Afficionados of black-and-white TVs would disagree, but imagine trying to sell a black-and-white gaming system in the early eighties...

The use of seven bits out of eight corresponds to the definition of the colour palette in the TIA (see COLUP0 here): four bits determine the colour (on NTSC, none, gold, orange, red-orange, pink, purple, purple-blue, blue — twice —, light blue, turquoise, green-blue, green, yellow-green, orange-green, light orange), and three bits the luminance.

| improve this answer | |
  • 2
    Thanks for the response, but I'm confused at how fixing the luminance as a constant fixes the problem. Does it still have to store the extra information so the following line will have the correct colour? Is there somewhere I can find more detail on how this actually worked in practice? – Muzer Oct 17 '17 at 12:36
  • 2
    You can’t do much about the colour itself, the previous line has already been output. However, fixing Y (the luminance) means that the previous line’s Y has no impact on the current line’s: you just output B-Y and R-Y on alternating lines, with Y constant, and get something vaguely sensible. The TIA’s vertical resolution is low enough compared to SÉCAM’s that this produces a good enough result (for some value of “good enough”). – Stephen Kitt Oct 17 '17 at 12:49
  • 1
    Hmm, so the downside is that this might give weird results if you change colour on the "wrong" line, you might end up with a pair of lines of the wrong colour. But isn't that the same issue here? If they had just made the TIA output the correct colour assuming that the colour and luminance haven't changed since the previous line was drawn, wouldn't you get mostly the same result - an OK looking picture with maybe a few oddities where the colours transition vertically? – Muzer Oct 17 '17 at 12:58
  • A few oddities, yeah, like Muzer said, which is one scanline tall and the same luminance as one adjacent scanline and the same hue as the other adjacent scanline. Is this right? – OmarL Oct 17 '17 at 13:12
  • I've found another, rather different explanation (perhaps complementary rather than conflicting), which I will post as an answer. I don't know if it's accurate though. – Muzer Oct 17 '17 at 13:15

There is an explanation listed in the Atari Mania FAQ:

Jerry Jessop explains why French Ataris produce fewer colors:

I will tell you why it only has monochrome out, because it's SECAM and a SECAM GTIA was never produced. The PAL GTIA is used in France and the Lum outputs are run into an onboard encoder to produce a "psudo" color depending on the Luminance output, composite only. This is why a SECAM VCS or 800 has nowhere near the same number of colors (16) availible as a PAL or NTSC unit (256).

The FGTIA was never completed as the market size did not warrant the expense. The largest SECAM market is not France but the Soviet Union (former) and in 80-84 sales of these items there were not possible.

The GTIA is the (by today's standards, very simple) video chip used by the Atari 2600, of which there are PAL and NTSC versions. This explanation sounds like they decided it wasn't worth the expense to make a third, SECAM, version, solely for the French and Soviet markets, so they decided instead to use the PAL chip (which, unlike the NTSC chip, would output video that was compatible with SECAM TVs for black and white pictures) and added some external, crude electronics to convert the different possible luminance output values of this chip into different colours (it was much easier to make electronics to look at the luminance values than the chrominance ones, since the latter would effectively involve decoding PAL).

Since the chip (being crude) only looked at the luminance values, and there were only 8 luminance values output by the PAL chip, this meant there could only be 8 colours. Therefore, as Stephen Kitt rightly said in his answer, they decided to sacrifice the ability to display different luminances at all for the SECAM output, and locked the luminance on maximum.

I suspect ignoring the complexities of SECAM and outputting just the colours was reasonably trivial as long as you were willing to put up with artefacts on colour transition, which they presumably were. It'd be nice if someone who actually used a SECAM Atari 2600 could verify that this was the case, and how visible these artefacts were.

| improve this answer | |
  • Note that the FAQ entry refers to the GTIA, which is more capable than the 2600’s TIA. Also the FGTIA was eventually completed and used in the XL/XE Ataris (starting in April 1984). – Stephen Kitt Oct 17 '17 at 13:31
  • Well-spotted. From googling around though it seems the same applies to the 2600's TIA. – Muzer Oct 17 '17 at 13:35
  • Yes, all that changes is the number of colours (8 v. 128 rather than 16 v. 256). – Stephen Kitt Oct 17 '17 at 13:36

Regarding the "only 8 colours" point, these are the standard colours available with RGB controls when the only choices are to turn the red, green and blue channels either on or off. Running through the truth table for the options available:-

  • red off, green off, blue off: black
  • red off, green off, blue on: blue
  • red on, green off, blue off: red
  • red on, green off, blue on: magenta
  • red off, green on, blue off: green
  • red off, green on, blue on: cyan
  • red on, green on, blue off: yellow
  • red on, green on, blue on: white
| improve this answer | |
  • Yep, exactly the same colours are on the ZX Spectrum and many others for this very reason. – OmarL Oct 18 '17 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.