[Coco] Drawing hires graphics

[Paulo Garcia]

Hi Evan, that is not what I was looking for since I want to try to remember
how I coded it in BASIC, but now I am interested in your implementation as
well if you don't mind to share. I wrote something similar in Javascript in
the past so I am curious to see your approach for the CoCo!

Thanks

Paulo

On Wed, Jan 18, 2017 at 11:33 AM, Evan Wright via Coco <coco at maltedmedia.com
> wrote:

> 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
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>



-- 
--------------------------------------------
Paulo