[Coco] RGB to XGA (Bruce Borer)

[Bruce Borer]

Hi Andrew,
    Thanks for all the useful information.  Something to look into in the
new year.
Bruce

On Wed, Dec 24, 2025 at 4:41 AM Andrew Ayers <keeper63 at cox.net> wrote:

> Probably the "best" that I know of (if anyone knows of a better one, I'm
> all ears) is Chris Lomont's memory map.
>
> https://www.lomont.org/software/misc/coco/Lomont_CoCoHardware.pdf
>
> There's also this version - I'm not sure which version it is, though:
>
> http://lomont.org/software/misc/coco/Lomont_CoCoHardware_2.pdf
>
> As you can tell by either - there is a ton of "TODOs" and missing
> information. Some is stuff that just needs to be filled in and checked
> from other sources (?). Others may need deeper investigation. But the
> majority of useful stuff is all there.
>
> Also check out the various "Unravelled" books - while these are more
> about the ROM contents and such, they can be helpful when used with the
> memory maps:
>
> https://colorcomputerarchive.com/repo/Documents/Books/Unravelled%20Series/
>
> Note that if you want to use them, you'll need all of them; also, the
> XLS (Excel) file is an update in some fashion, but I haven't delved into
> it much - I'm not sure how it is structured.
>
> You need all of those books at hand because each (in each ROM
> disassembly) reference "labels" - and those labels could be in "earlier"
> (or "lower level") ROMs. For instance, Disk BASIC will reference stuff
> in Extended BASIC, which in turn will reference stuff in Color BASIC.
>
> Each book is mainly interested in the BASIC ROM it has disassembled, and
> doesn't include those other ROMs. Also note that Super Extended BASIC
> can be tricky to understand in areas, due to how SECB does it's overlay
> and patching in the "All-RAM" mode that is native to the CoCo 3 (I know
> the CoCo 2 could be put into "All-RAM" mode, and I think the CoCo 1
> could as well - but the CoCo 3 boots into that mode; I don't recall
> off-hand, but I think there is actually a way to disable the mode on the
> CoCo 3 which probably clobbers things).
>
> You might find the Color BASIC and Extended BASIC books useful for
> learning more about how the CoCo VDG stuff works, which the GIME in the
> CoCo 3 partially "emulates" (it doesn't handle all of the SG modes
> mainly that the CoCo 1/2 does.
>
> I think the GIME supports everything else, but it also allows the
> changing of the palette for the SG and PMODEs - which is how, IIRC,
> those "composite emulation" mods for RGB monitors work; the mode is set
> for PMODE 3 (128x192x4-color mode) and the colors are changed to match up).
>
> If that doesn't make sense, the explanation is that PMODE 4 is actually
> a monochrome mode (black and white or black and green); on a proper
> composite monitor with enough bandwidth, you only get the monochrome
> representation.
>
> Color on TVs and lower-bandwidth composite monitors are achieved by
> putting black and white vertical stripes next to each other 1 pixel
> wide, with "even/odd" selection (so - black/white vs white/black); the
> pixel color transitions between "white" and "black" (two different
> voltage levels) "bleeds" over (due to lack of bandwidth) and shows
> different colors...depending on where the clock is in its phase for the
> chip, which is "random" at startup (for the 6847; it is -fixed- on the
> CoCo 3 and GIME!). Which is why PMODE 4 games say "press reset until
> screen is red" or whatever. This is why it is also called "artifact
> coloring" - because the colors are the result of an artifact of the
> hardware and NTSC color system being...well, crappy in a way (but was
> done that way to support and allow for b&w broadcasting to continue and
> be viewed on color TV sets, and for color broadcasting to be seen as
> black and white on those sets - a clever hack, I guess.
>
> Anyhow - because of that "even/odd" spacing thing, horizontal resolution
> is effectively considered halved, so on the CoCo 3, switching the mode
> to PMODE 3 and changing the palette of the 4 colors in that mode can be
> done to simulate/emulate PMODE 4 colors on an RGB monitor.
>
> With that said - what you see in PMODE 4 on an RGB monitor without that
> trick is actually how the mode is -meant- to be seen, at least according
> to the Motorola 6847 datasheet. Which is kinda a pity, because there
> were games on other systems that had similar limitations to their
> graphics, which used a different method (or simply because it wasn't
> NTSC) - and they couldn't use artifact coloring. Which led to a
> different way of doing things to give detail and such to graphics for
> games (dithering of black/white pixels, patterns, etc). It also led to
> (for the CoCo; not sure about the Dragon) software which was meant to
> use artifacting looking weird on (say) PAL televisions. Strangely
> though, there are some titles for the CoCo that were made to look decent
> on either video standard (IIRC, the one Walt Disney title was that way).
> Most though, either had strange "colors" (not at all what was meant) or
> were just monochrome (with colors showing as vertical stripes).
>
> ...and with all that, I will probably be ripped a new one by AllenH,
> because my descriptions and such are mostly wrong in a technical sense,
> because I'm not an engineer who worked with such systems intimately like
> he did (I don't mind, Allen - I know what I'm talking about isn't 100%
> right, but hopefully I do convey the intention and reasoning - so
> correct away if you can or must - when your arm is feeling better,
> perhaps!).
>
> Andrew L. Ayers
> Glendale, Arizona
> phoenixgarage.org
> github.com/andrew-ayers
>
> On 12/24/25 12:57 AM, Bruce Borer wrote:
> > Hi Andrew,
> >      After reading your comments about 225 lines I searched and found
> > this site
> > BASIC225 <https://nickmarentes.com/ProjectArchive/basic225.html>
> > This will help me support 192, 200 and 225 lines.  But that will be in
> > the  new year.
> >
> > Bruce
>