Re: [stella] tia hue luminance

Subject: Re: [stella] tia hue luminance
From: "Eric Ball" <ericball@xxxxxxxxxxxx>
Date: Thu, 11 Dec 2003 23:14:30 -0500
Wow, lots of interesting questions.  Let me see if I can come up with some
answers & clarification.  This will probably be long and I may ramble a bit,

1. Ranges
In the calculations I've given the range of RGB & Y are 0.0 - 1.0, which are
then multiplied by 255 to yeild an 8 bit value (so black = #00000 and white
= #FFFFFF).  In other situations different ranges are used (eg Yblack = 16
and Ywhite = 235) to allow for some underflow/overflow due to signal

When talking about NTSC video IRE units are used, where sync = -40 IRE,
blank = 0 IRE, black =7.5 IRE & 100% white = 100 IRE.  There is some video
equipment which uses black=0 IRE.  Color saturation is also expressed in IRE
with colorburst being 20 IRE.

2. the TIA
The TIA generates the video signal via 6 output pins: phase shifted
colorburst COL, and digital luma SYNC, BLK, LM2, LM1, and LM0.  The phase
shift for the COL pin is generated internal to the TIA via some delay gates
selected via a multiplexer (with an output disable for COL=0).  SYNC and BLK
are driven automatically by the TIA horizontal counters, with LM2-0 being
tied directly to the object color selector.  The digital luma pins drive a
simple resistor D to A converter.  (Note: the pins sink current, so a lower
resistance means a higher output voltage.)

Based on the knowledge that SYNC is 40 IRE, we can derive values for LUM.
(Note: the BLK pin isn't connected on the 2600A, so the dark colors will
tend to be darker.)  Note: the same values of LUM are used for COL=0 and the
other colors.  Therefore, any attempts to make COLUM #F bright white will
wash out the other colors.

Because the TIA generates a Y/C signal directly, the "colors" it can
generate sometimes fall outside the normal 0.0 - 1.0 range for RGB
(typically those with low LUM values).  These values are clipped, which
changes the resulting hue, saturation & brightness.  (One of the reasons to
keep COLUM lower is to reduce clipping at the top end.)

3. Output Confusion
Coming up with the R'G'B' values is easy.  Getting those values to display
consistently is hard.  There are a bunch of variables which are beyond my
knowledge and control.

First, the color of RGB is unknown.  The color & brightness of TV/monitor
phosphors has changed over the years.  LCD display color is a combination of
a "white" cold cathode florescent light and color filters.  This can be
further complicated by manual adjustments to color "temperature", tint, or
the internal 2600 color delay pot.

Next, the "gamma" of the output is unknown.  In order to compensate for the
non-linear light response of the TV's CRT to input voltage, the video input
is pre-compensated at the broadcast end so the TV output is linear.  (I'm
not sure whether this was done to make the TV electronics simpler or for
broadcast power reasons.)  Because the TIA generates a Y/C signal, the
brightness of LUM 0-7 is not linear.

On the emulator side this gets even more complicated because I don't know
whether RGB is considered linear or non-linear, i.e. is it passed straight
through to the CRT guns, or is it compensated.  The answer to this question
may vary from platform to platform (including such details as graphics card
and API).

Finally, brightness can be changed by black level & contrast settings etc.

4. Formula Tweaks
There are a few tweaks which can be made to the formulas I've given:
- LUM could be scaled by more than 0.045 to get Y, although not much since
it will wash out the high LUM colors.  An offset could be added, though that
will change black and the low LUM colors.

- COL could be scaled by a different value than 24 degrees to get hue.  This
may be what is needed to make the higher colors match.  An offset here is
probably wrong because the colorburst is likely just a gated COL=1.  I think
that the external pot is just to get the burst in the correct phase relative
to SYNC.

- Changing to linear RGB?  I've gone through the sRGB spec three times and I
still can't figure out which is right.

- Transforming the output to Rec 709 RGB (which is used by HDTV and is a
better representation of current CRT colors) would be interesting, but
probably have little impact.  Gamma is also an unknown here.

5. Next steps
Given infinite time, there are some things I would like to try.
- Actually fire up the colorbar demo I've done (all 128 colors onscreen at
once using PF/BK), and do some comparisons myself.

- Try to persuade my video capture card to capture my colorbar demo without
super-saturating all over the place.  (Probably missing AGC somewhere.)

- Take the palettes used by the emulators and figure out what the equivalent
Y/hue/sat values are to get some hints.

- Start to think about considering the possibility of looking into how PAL
color works.

Archives (includes files) at
Unsub & more at

Current Thread