Re: RGB to XGA (Bruce Borer)
Robert Emery via Coco <coco-uNHYcr1XS/wmlAP/[email protected]> Mon, 29 Dec 2025 23:11:30 -0600
| Newsgroups | gmane.comp.hardware.tandy.coco |
|---|---|
| Message-ID | <CAEVHLL5LydVLOHJjfaWyvLkE1kRKsev0xCLqcBAe=TP+k6CK-w@mail.gmail.com> |
I recommend a book called Tandy's Little Wonder by Frank Swygert... available on the Color Computer Archive. Tons of useful info in a fairly succinct but informative guide to CoCo foundations. Cheers, Bob On Wed, Dec 24, 2025, 7:42 AM Bruce Borer via Coco <[email protected]> wrote: > 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 <[email protected]> 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 > > > > -- > Coco mailing list > [email protected] > https://pairlist5.pair.net/mailman/listinfo/coco > -- Coco mailing list [email protected] https://pairlist5.pair.net/mailman/listinfo/coco