Re: RGB to XGA (Bruce Borer)

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

-- 
Coco mailing list
[email protected]
https://pairlist5.pair.net/mailman/listinfo/coco