[Coco] Coco3 CMP color swatches
jdaggett at gate.net
jdaggett at gate.net
Tue Aug 30 23:38:37 EDT 2005
Robert
The CMP colors are off in the CoCo3 because of the lack of resolutionin the I and
P values used to recreate the color. One can consider that I is the intensity or the
saturation of color and that P, phase, is hue.
RGB does not use saturation and hue. NTSC does. There are three governing
equations that can convert an RGB level signal to NTSC. As stated before the lack
of resolution in six bits for the tre, there is no way to exactly map all or even some
RGB value color to that of a corresponding NTSC chromance and
monochrominance signals.
The best you can do is a close approximation.
Monochrome information signal equation:
Y = 0.3R + 0.59G + 0.11B
This is essentially your black and white signal.
Chromance is comprised of two signals I and Q wh ich are orthogonol to each other.
Q = 0.21R - 0.52G - 0.31B
I = 0.6R - 0.28G - 0.32B
The Q signal is the purple/green axis and the I signal is the orange/cyan axis. These
happen to be rotated counterclockwise 33 degrees from R-Y and B-Y axis. The R-Y
and B-Y axis form the common Y and X axis of a cartesian plane.
enough with theory.
As I simply stated, it is great that the CoCO 3 can even reproduce 48 of 64 CMP
colors closely. WIth 16 level of hue and four levels of saturation, the GIME chip is
doing well. The GIME chip has the ability to invert the phase of the colorburst signal
that will essentially give another set of colors. YOu also have to consider that the
GIME chip also can output monochrome. Thus the values stored in the palette
registers must meet the requirements so that you have 64 levels of gray. These are
computed via the first equation above.
james
On 30 Aug 2005 at 9:36, Robert Gault wrote:
Date sent: Tue, 30 Aug 2005 09:36:03 -0400
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts
<coco at maltedmedia.com>
Subject: Re: [Coco] Coco3 CMP color swatches
Send reply to: CoCoList for Color Computer Enthusiasts
<coco at maltedmedia.com>
<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
<mailto:coco-
request at maltedmedia.com?subject=subscribe>
> If one assumes that the net outputs to composite and RGB monitors were
> correctly designed, then the composite and RGB colors are essentially
> but not exactly the same; just have different palette ID numbers.
>
> Regards ml programming, the format of the composite and RGB colors
> will be different. RGB - x x R1 G1 B1 R0 G0 B0 CMP - x x I1 I2 P3 P2
> P1 P0 where I is intensity and P phase angle However, as there is a
> one to one mapping of the CMP and RGB colors, it is easier to think of
> the same 64 colors being assigned different palette ID numbers.
>
> You get into trouble with the CMP colors for 48 and 63 which are
> xx110000 and xx111111. These colors both look like pure white on a
> composite monitor but only 48 should be. By rights 63 should be a very
> pale green. Since these two colors are wrong, probably other CMP
> colors are somewhat off and a CMP to RGB mapping is not accurate. It
> all depends on what angle xxii1111 corresponds to but it should not be
> xxii0000.
>
> Stephen H. Fischer wrote:
>
> > Hi,
> >
> > Thanks for all CoCo er's tips and discussion.
> >
> > I am now working on the project and found the following in Jeffs and
> > Johns Emulator.
> >
> > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> > ;64 byte palette lookup table
> > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> >
> > PALETTE_XLAT DB 00H,08H,10H,18H,20H,28H,30H,38H
> > DB 01H,09H,11H,19H,21H,29H,31H,39H
> > DB 02H,0AH,12H,1AH,22H,2AH,32H,3AH
> > DB 03H,0BH,13H,1BH,23H,2BH,33H,3BH
> > DB 04H,0CH,14H,1CH,24H,2CH,34H,3CH
> > DB 05H,0DH,15H,1DH,25H,2DH,35H,3DH
> > DB 06H,0EH,16H,1EH,26H,2EH,36H,3EH
> > DB 07H,0FH,17H,1FH,27H,2FH,37H,3FH
> >
> ><snip> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list