[Coco] Drawing hires graphics

[Evan Wright]

I don't know if it's really what you need, but I've made a Windows based text adventure generation tool that targets the CoCo.  You describe the game in an XML file and the Windows tool converts it to a 6809 binary.  It's still a bit rough at this point, but it works, and I have some of my students testing the first game I've made with it.
If that's something you're interested in, let me know,
-Evan 

    On Wednesday, January 18, 2017 10:21 AM, William Astle <lost at l-w.ca> wrote:
 

 On 2017-01-18 06:15 AM, Paulo Garcia wrote:
> If so, what is the best option to:
>
> 1 have the graphics in disk and load them when needed?
>
> 2. have the in memory like bundled in my .BIN file?

If you have the memory to hold the graphics, this is actually a pretty 
good way of doing things. It avoids having to wait for loading things in 
the middle of the game. It is perfectly possible to load an arbitrary 
amount of data from a single BIN file but it does require a bit of 
trickery. You can actually exploit the way LOADM (and CLOADM for that 
matter - it works from tape, too) work. The limit is the size of the 
disk (or how long your tape is - you can load a few hundred KB from tape 
this way - far more than you can from a standard floppy - though it will 
take relatively long time). You may know how this works already, but 
others might find it interesting.

Your first thought might be to have chunks that load over the MMU 
registers between data chunks. Unfortunately, that will give you I/O 
errors because the ROM actually verifies the value that goes into each 
memory location. That's not helpful in this case because the upper 2 
bits of the MMU registers contain garbage and won't match what you wrote 
to them. While you can predict what those bits will be, it will cause 
things to go very wrong on systems with more than 512K where those upper 
bits have a meaning. For maximum compatibility, you shouldn't try to 
compensate for the garbage in those upper 2 bits.

Since you're doing this on a Coco3, it turns out that you can overwrite 
the start of the "CLOSE" routine (in the Color Basic ROM area[1]) as one 
of the chunks in your BIN file with a jump to your loader code. Then, 
when LOADM reads the postamble and calls "close", your loader starts 
executing with the file still open and pointing to the data past the 
postamble. That can be anything of any size. Your loader can then do 
whatever it wants by calling the "CONSOLE IN" routine (in the Color 
Basic ROM[1]) appropriately until it gets an EOF indication. Note that 
if you still want the Basic ROM intact, you should restore the first 
bytes of the "CLOSE" routine as part of your loader and you should call 
it when you're done loading.

At the most simple, what you can do is duplicate the loading loop for 
LOADM (or the Extended Basic CLOADM loop) but without the "verify" step. 
Then you just append to your loader another BIN file. You can, of 
course, get arbitrarily complicated depending what you need 
specifically. This could include loading screens, graphics data, code, 
or anything else you need to load.

[1] The reason for doing the work in the Color Basic ROM instead of 
trying to patch the LOADM routine directly is so that it will work on 
ANY version of Disk Basic, regardless where the LOADM code (or the "read 
a byte from the disk file" routine) is located. It also has the side 
effect that your file can be loaded from tape since the trick will work 
with CLOADM as well.

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco