[Coco] Creating and loading big machine code files into RSDOS

[Glen Hewlett]

Wow a lot of great info here guys!

First Robert, thanks for getting back to me, I think William's methods will work for well for me.

Thanks for the ideas Mark and William.  I did see and use some of the info in Williams PDF for loading the sprites and graphic characters for Pac Man already.  I guess I just didn’t look closely enough at Williams CoCo Loaders PDF or maybe it went over my head a few months ago when I first looked at it…. I think using your code for a two stage loader is the way for me to go.

William, thanks for LWTOOLS they are awesome!  I don’t think I would be working on these ports if I have to develop it all on the CoCo it is just too big.   Mind you I did create a basic program on the CoCo to decode the graphic characters and sprites from Pac man and that was fun.  It brought back a lot of old memories...

Mark, I did already have those PDFs and they are a great resources for Pac Man and the CoCo. As for the large amount of space for Pac Man.  I have just completed all the demo/attract screen routines and It's taken most of the lower 32k. I probably have around $1000 bytes free, the sprite routines that I made and the unoptimized code so far is taking a lot of space. I just want to know what my options are before I hit that $8000 byte wall.  You were mentioning  different options for speeding up the graphics code like pre rendered sprites and more which will take even more space…

You guys rock!
Glen


> On Feb 13, 2017, at 11:39 PM, William Astle <lost at l-w.ca> wrote:
> 
> On 2017-02-13 08:04 PM, Mark McDougall wrote:
>> On 14/02/2017 1:44 PM, William Astle wrote:
>> 
>>> You really do want to avoid loading over Extended Basic. Depending how
>>> far over it you go, it will crash. If you're careful, you can get away
>>> with a small amount of overlap but it gets fiddly doing that.
>> 
>> You also need to be careful which pages you load into even outside the
>> (currently mapped) 64KB address space whilst BASIC is still running. I
>> found I couldn't use pages $34-35, for example, as simply returning to
>> BASIC to execute the program corrupted a few bytes on those pages.
>> 
>> Regards,
>> 
> 
> It is true that you do need to be a bit careful. In particular:
> 
> Block $34 is used for the HGET/HPUT buffers and isn't messed with except on reset or by HBUFF, HGET, and HPUT. Part of it is clobbered during the hardware RESET (or cold start) handler. It's unfortunate they did that since it means that HGET/HPUT buffers cannot survive RESET (even if you intercept the RESET vector at $72). These are NOT touched by simply returning to the OK prompt.
> 
> Block $35 is used for stack space during the H* graphics commands. This one won't be modified unless you're doing H* graphics commands. It is definitely not touched by simply returning to the OK prompt.
> 
> Block $36 is the high res text screen memory. It will only be clobbered if you're using the 40/80 column screen.
> 
> Other than the above, there is no mechanism in the ROM that would cause either of blocks $34 or $35 to be modified so they should stay exactly as you put them. Unless you end up leaving them mapped in the logical address space and the stack or something other runtime data structure runs into them.
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com <mailto:Coco at maltedmedia.com>
> https://pairlist5.pair.net/mailman/listinfo/coco <https://pairlist5.pair.net/mailman/listinfo/coco>