[Coco] Drawing hires graphics

[Paulo Garcia]

Hi all

for the whole programming techniques I still need to digest the
information, then I will ask more!

As for the file format, I suppose the CM3 format is kind of standard for
that type of idea? Is there a sharable code to display it (C, ASM, etc) ?

Working on Windows and be able to convert simple graphics would be awesome,
though.

Thanks


Paulo

On Wed, Jan 18, 2017 at 11:52 AM, Paulo Garcia <paulo.astuser at gmail.com>
wrote:

> 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
>



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