[Coco] Questions on CoCo 3 graphics

[Mike Pepe]

I'm no expert on this by any means, but I'll share my opinion on the subject

Andrew wrote:
> All,
> 
> I have a few questions regarding CoCo 3 graphics modes and such, using 
> Disk Extended Basic - that I want to run by everyone to see what they 
> think. The responses I get may come in handy in the future, if I get 
> around to playing with something I thought may be useful to others:
> 
> 1. First off - does anyone know if it is possible to have more than one 
> 320x200x16 color screen in memory on a 128K CoCo 3? I assume that such a 
> thing would be easily possible on a 512K or higher machine.

Yes- each screen takes up 32k. You could in theory have 3 such screens 
and 32k left for code.

> 2. Is is possible - and more importantly, how - to have two such screens 
> in memory (on a stock 128K machine), and be able to cause DECB to 
> redirect the graphics commands (ie, HLINE, HCIRCLE, etc) to this 
> "hidden" page, then "flip" it forward? Even if it required a small bit 
> of assembler, that is OK.

Probably not. There's no other contiguous 32k block available to display 
from if you want to use BASIC. The 8k pages after the high-res display 
are used for other stuff in BASIC.

> 3. Basically, I want to do page flipping (and double buffered graphics) 
> on a normal 128K CoCo 3 - however, I am not sure if it can be done in 
> the memory map as shown (it seems like there isn't another contiguous 
> 32K segment of memory in the map - is this right or wrong?

Correct in that there is no unused 32k chunk available for a text screen

> 4. Is it possible to instead set up a pair of 256x200x16 color screen 
> (using the GIME registers), and then use DECB along with some assembler 
> routines to access/display them (in other words, create custom line, 
> circle, get/put routines)?

Probably not easily. a 256x200x16 screen is 25k, so you'll still need 4 
blocks to do it.

I would say if you went with a 160x200x16 screen instead, all it would 
require is a couple of pokes to tell basic which two mmu pages to draw 
to, then a couple of pokes to the GIME to change what it's displaying.

> 5. If none of this is possible - would it be better to create fast 
> blitting routines in assembler, and blit/redraw the graphics as needed 
> (dirty rectangle, maybe?) during the vblank interval? I think this is 
> what rogers butterfly game is doing?
> 
> 6. Am I expecting too much out of DECB? I am not expecting blazing 
> framerates, but even one frame per second with 2-3 sprites could be 
> useful...? I am also thinking about doing this under CBASIC-3 (from 
> Cer-Comp) - IIRC, it allowed inline assembler.
> 
> 7. Is the only way possible on a 128K CoCo 3 would be to overwrite BASIC 
> (since we're in all-ram mode)? Can I overwrite only a "non-essential" 
> portion of BASIC in order to get the extra graphics screen in place?

You could, but switching the RAM and and going into ROM mode mid-stream 
would probably be fatal. The ROM has un-patched code. Your code would 
probably get lost when an interrupt happens and something unexpected 
results.

> Basically - a long time ago I wrote a library for 
> QuickBasic/QBasic/PowerBasic called "The Blast! Library" - and I would 
> like to replicate it in some small manner (probably couldn't recreate 
> all of the functions I had) on the CoCo 3 - hopefully a 128K CoCo 3. It 
> basically handled sprites and such with double-buffering in the 
> 320x200x256 color mode (VGA mode 13h). It would be nice to do something 
> similar under DECB on the CoCo 3.
> 
> Does anybody know of sample code or articles or something that can show 
> me how to access and control the CoCo 3 graphics modes properly, both in 
> DECB (ok - techinically I know there is the word "Super" in there) 
> and/or in assembler? I have seen such articles in the Rainbow (from my 
> collection) for the regular PMODEs for the CoCo 2, but not much, if 
> anything, for the CoCo 3.
> 
> Thank you for any responses - like I said, I don't know if I will get 
> around to this project, but I am interested in trying such a thing in 
> the future.
> 
> -- Andrew L. Ayers
>    Glendale, Arizona
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco