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

[Cocodemus]

Told ya the problem was your pal coco3 ;)

Sent from my iPhone

> On Feb 13, 2015, at 4:37 AM, Nick Marentes <nickma2 at optusnet.com.au> wrote:
> 
> 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
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco