[Coco] Coco3 CMP color swatches
jdaggett at gate.net
jdaggett at gate.net
Wed Aug 31 12:32:10 EDT 2005
On 31 Aug 2005 at 9:37, Robert Gault wrote:
Date sent: Wed, 31 Aug 2005 09:37:33 -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>
> Nice explanation but I do have reservations with two implied
> statement. The resolution in the CMP color set is exactly the same as
> the RGB set, 64 separate colors. If the Coco hardware is designed to
> distribute these colors evenly throughout the respective color spaces
> why should it be difficult for the CMP and RGB colors to match? Of
> course the Coco hardware may not be up to the task, but in theory why
> couldn't it be?
>
********
The differences lies in how a RGB analog monitor and a NTSC TV works and the
GIME chip. The analog monitor essentially takes the RGB signals at low levels and
amplifies them to a level that the color guns of the CRT requires. There is no need
for chromance demodulators as needed in TVs.
Now here is where the rub really comes in. The GIME chip. The GIME chip can do
one of two means to generate the NTSC signal.
Method one is to feed the individual RGB outputs to three sets of three opamps and
hold them to the respective gains as described in the three equations. Three
opamps for each equation. After that the corresponding adders or substractors are
needed. Then you have the Y signal and the I and Q chromanace signals. The
Chromance signals are modulated onto the color burts carrier and their phase sy
cnchronization is done via the color burst.
Method two is to derive the Y signal from existing I and Q signals . Then have two
more DACs that are used to generate the analog I and Q chromanace signals from
digital data stored elsewhere in the chip. The rub here is the same data bits to form
the Y signal have to be used to generate the I and Q chromance signals.
Method two is most likely what is used. By standard phase relationships between
the I and color burst, I and Q, I and R-Y andfinally R-Y and B-Y signals. The best
way to see this is to look at a cartesian plane. The color burst lies on the neagtive X
axis. R-Y lies on the positive Y-axis and B-Y lies on the positive X-axis. Therefore
the color burst, R-Y, B-Y and G-Y all lie on the X and Y axis. The I axis is rotated
clockwise from the burst phase by 57 degrees. The Q axis is 90 degrees clockwise
from the I axis.
The derivation can be done many ways and to predict how it is done is not of
importance here. The key is that the busrt sets the system phase. It then affects the
reproduction or demodulation of the RGB signals delivered to the CRT guns by
altering saturation and hue phases. In NTSC the I and Q signal have only half the
information. The phase is determined by the color burst signal. IN the tre, we have
only the two bits of saturation and four bits of hue for color determination.
> Perhaps if the requirement were that both the CMP colors and the CMP
> gray scale be smoothly spread through the color spaces, one but not
> both would be possible. But I don't see that Tandy was under any such
> constraint. In fact, I can't remember any Coco articles where the
> monochrome bit was in use to enable 64 levels of gray. Do you know of
> any public use of the 64 gray scale mode?
>
I personally don't know either. Evidently the designers of the tre must have felt that
if we bring out a NTSC signal that B/W compatibility needed to be maintianed. Also
since the Y signal is most likley derived from the I and Q data, you still get 64 levels
of grey by not modulating the I and Q signals. The key to getting correct color is the
phase of the color burst signal. In NTSC this is the most sacred of all the signals.
One last note is the that the Y signal is fed to the cathode of the CRT and the
demodulated RGB signals are fed to respective control grids.
james
> jdaggett at gate.net wrote:
> > 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
> >
> >
> >
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list