[Coco] Coco3 CMP color swatches

[Robert Gault]

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?

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?

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
> 
> 
> 
>