[Coco] Wrong palette on CoCo3 issue - MYSTERY SOLVED!

[Nick Marentes]

Thanks to those people who gave me tips, clues and information which has 
led to the solution to this mystery.

There was in fact nothing wrong with VCC or MESS but before I accept the 
award for "biggest numbskull downunder", let me explain the situation 
that people may find interesting.


THE PROBLEM

VCC kept coming up with the wrong colors in programs even though the 
config was set for RGB monitor.


SOLUTION

VCC boots up with a CMP palette set, even if there is an RGB monitor 
attached.

My confusion came from the fact that on a real PAL based CoCo, we don't 
have a CMP only RGB regardless of what monitor we have connected. CMP 
works exactly the same as RGB on a PAL CoCo3.


TECHNICAL

The GIME chip on any CoCo worldwide produces an RGB video output 
(available from the underside of the CoCo3) and a NTSC Composite output 
(available on the RF and composite video outputs). These 2 outputs 
differ on how the GIME internally generates the color and hence why 
there is an RGB and CMP palette.

But on a PAL based CoCo3, the NTSC composite output is not connected, 
just left as unused pins on the GIME chip itself. Instead, the PAL 
motherboard has a separate daughterboard which is attached underneath 
that takes the GIME RGB outputs and generates a PAL based composite 
output (and therefore RF output also). Because of this, each outputs out 
the same colors since they are being generated from the same source (RGB).


WHAT I HADN'T REALIZED

I understood this before but I hadn't realized that on an NTSC CoCo3, 
even when you have an RGB monitor attached, the default startup color 
palette is CMP.

So what VCC was doing was correct because it is emulating an NTSC CoCo3.

I hadn't used a NTSC CoCo3 until now, I have now acquire an NTSC 
motherboard which is operating perfectly in a PAL CoCo3 case and powered 
by the 240v transformer as used in a PAL CoCo3. The output voltages to 
the mainboard are the same and the 50Hz doesn't seem to make any 
difference (rectified output).

REVELATION!

I would have thought it to be logical that if a RGB monitor is being 
used, the CoCo3 would select an RGB palette else it selects a CMP but to 
do this, the CoCo would need some sort of signal from the monitor for it 
to know what type of monitor is attached.

And it does!

Pin 10 on the RGB connector has been documented as "Not Connected" but 
as some know, it is connected to a bit on the PIA. In other words, it is 
a readable pin most probably for this very purpose... to tell if an RGB 
monitor is attached!


WHY MR. TANDY?

Has anyone read that pin with and without an RGB monitor (CM-8 only) 
attached? Does the Tandy CM-8 actually set this bit or was it ignored?

If this pin was used, the BASIC startup could have chosen the right 
palette to initialize on startup.

NTSC CoCo3's all startup in CMP palette (and 60 Hz) whereas PAL CoCo3's 
startup in RGB palette (and 50 Hz).

If this pin where utilized, it would have intelligently selected the 
appropriate palette (only for NTSC) and programs would not have needed 
to prompt the user if they had a RGB monitor or not.

I can't understand why I hadn't noticed this sooner. Was I using a 
patched VCC before that setup RGB palette on startup? I always have the 
config set to RGB.


So there you go, I wasn't completely bonkers and I have now understood 
the boot palette process and the intended use of pin 10 of the RGB 
connector.

The best news of all is that I can continue using VCC!! (Yay!!)

Nick