[Coco] Coco3 CMP color swatches

Tue Aug 30 03:41:44 EDT 2005

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

As to the accuracy of the mapping, I plan to ignore this and plow on.

Until I have printed the first try I am not going to worry much about what 
has been said.

I am going to assign names. Here are some I have defined already.

RGB_WHITE, RGB_BLACK, RGB_RED, RGB_GREEN, RGB_BLUE,
RGB_CYAN, RGB_YELLOW and RGB_MAGENTA

I will not be defining CMP_WHITE ... CMP_MAGENTA. I will accept them if 
someone provides them.

I need the RGB ones in the DECB Preprocessor as the first program to be 
preprocessed needs them.

The discussions of all the problems with color I expect in the end to just 
ignore.

If the chart is useful for many CoCo ers, then I will consider the project a 
success.

Remember, I am trying to improve on a page with no useful information at 
all.

As to the names, I expect that the ones that I choose will be accepted as 
being more useful than the numbers 0-63.

The default names in the DECB Preprocessor can be overwritten or the 
defaults changed. I expect that the ones I define will be kept and new ones 
added as needed.

One of the things that I saw a need for many years ago was some one 
appointing themselves the OS-9 Dictator being that the old Dictator(s) was 
no longer performing their duties. (Tandy / Radio Shack.)  This was done in 
a way that I did not expect, but is a huge step forward that eliminated the 
question "What patches need to be applied to generate the latest OS-9 
Version. What a wonderful job was done. I have not seen any comments saying 
"You can't do that".
It is widely accepted.

If anyone does not like what I define, do a better job.

Persons who do not like the names or the colors printed can do a better job.

No Problem for me.

Stephen H. Fischer

----- Original Message ----- 
From: "Robert Gault" <robert.gault at worldnet.att.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: August 29, 2005 1:09 PM
Subject: Re: [Coco] Coco3 CMP color swatches

> There are two issues here, 1) what are the color names and 2) what are the 
> equivalent 24 bit value. There is no need to measure anything to get 24 
> bit values. Just assume the Coco DAC is full on at 3 and full off at 0. 
> Scale that proportionally over the 24 bit values of 0-255. The problem is 
> that all monitors have slightly different color tuning even with the best 
> intentions that will make all Coco images look slightly different. It is 
> possible that the Coco DAC is of low tolerance and that will cause even 
> larger differences in color. Even the amount and type of room lighting 
> will have an effect on perceived color. Tandy did not fill in the table of 
> color names for a reason. Tandy could have printed un-named color 
> swatches, but the expense of doing that in a useful fashion would have 
> been too high.
>
> Names are another matter entirely and I don't believe there is any 
> suitable method of getting these short of using standardized color charts 
> and their technical rather than descriptive names. Any method of printing 
> the color swatches will not result in permanent color so naming the 
> swatches would be an exercise in futility. Most people will barely be able 
> to distinguish nearest neighbors in the 64 palette color selection unless 
> they are side by side and certainly can't when the level of color is 
> increased.
>
> My suggestion is that the best names for the Coco colors are their RGB 
> values, ex. 2R3G1B and let it go at that.
>
> Kevin Diggs wrote:
>> Hi,
>>
>> Robert Sherwood wrote:
>>
>>>
>>> Of course, you also have to consider the effects of converting the image 
>>> to GIF or JPEG as well.  The only way I know to be certain of having 
>>> perfect colour reproduction in a digitized image is to provide it in a 
>>> 24-bit uncompressed format (such as BMP or TIFF.  PNG might work - I'm 
>>> not as familiar with that.)
>>>
>>> All that being said, I think it's certainly worthwhile to go ahead with 
>>> the experiment and see how the results compare to the previous MESS 
>>> screenshot.  It's probably also worth it to try the same with the 
>>> digital and film cameras as stated sometime earlier.  Although with 
>>> film, the printing process introduces way too many output variables to 
>>> be very accurate for producing swatch-like samples.  Either slides, or a 
>>> scan from negatives would be the best option here.
>>>
>>> --Rob
>>>
>>>> Allen Huffman wrote:
>>>>
>>>>>
>>>>> What happens if you just grab a frame using a TV digitizer? (With
>>>>> composite inputs.)
>>>>>
>>>>>         -- Allen
>>
>>
>>     What about hooking a scope up to the RGB lines and seeing what the 
>> DACs actually put out for the 4 values and using that to guide the 
>> conversion from 2 bit to 6 or 8?
>>
>>                     kevin