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

[Glen Hewlett]

Hi All,

I modified William Astle's two stage loader technique and code and created a single program the lets you use all of the CoCo 3’s memory for your machine language programs.  This is exactly what I was looking for in my original post.  It’s quick and easy and let’s you use the RAM on the CoCo 3 from $0000 to $FDCC for you program.  You don’t have to worry about anything just assemble your program and merge the loader program onto the front of your program and you are done.  You can read all about it and how to use it on my blog (and of course download a copy)

https://nowhereman999.wordpress.com/2017/02/15/coco-3-loader-for-big-programs/ <https://nowhereman999.wordpress.com/2017/02/15/coco-3-loader-for-big-programs/>

I hope other find it useful,
Glen 

> On Feb 15, 2017, at 12:50 AM, Glen Hewlett <glen.hewlett at sympatico.ca> wrote:
> 
> Hi William,
> 
> That’s good to know, I’m sure I have enough room for Pac Man now.  , I’ll keep it in mind, down the road it might come in handy...
> 
> Cheers,
> Glen
>> On Feb 15, 2017, at 12:44 AM, William Astle <lost at l-w.ca> wrote:
>> 
>> Excellent.
>> 
>> If you ever run into file size limitations (as in your file doesn't fit on a disk), there is a way to modify the loader so that it can read an SLZ compressed payload. I have the C source for the slz compressor and also a functional stream-based decompressor in 6809 assembly that only needs a 4K buffer in addition to the decompression code.
>> 
>> SLZ actually does a surprisingly good job on 6809 assembly code and it will almost certainly do well on graphics data. And it has the advantage of having a simple file format that is easy to decompress with a fixed amount of memory.
>> 
>> It can be really fun watching people react to doing a LOADM of a 68 granule file and have a massive program unpack and start running.
>> 
>> On 2017-02-14 07:28 PM, Glen Hewlett wrote:
>>> Hi William,
>>> 
>>> I just wanted to let you know I now have my program loading using your method and I have lots more free space now for coding.  :)
>>> 
>>> Cheers,
>>> Glen
>>> 
>>>> On Feb 14, 2017, at 8:57 PM, William Astle <lost at l-w.ca> wrote:
>>>> 
>>>> The second stage loader is intended to take total control over the machine in my use case. My second stage is actually a secondary loader that takes a DECB style binary and "interprets" it. The first "section" of that binary sets the MMU blocks as required by the rest of the binary. (Actually, my actual second stage loader takes an SLZ compressed DECB style binary, but that's another kettle of fish altogether.)
>>>> 
>>>> Obviously, you can do whatever makes sense for your use case in your loader. :)
>>>> 
>>>> On 2017-02-14 06:46 PM, Glen Hewlett wrote:
>>>>> Hi William,
>>>>> 
>>>>> I’ve starting implementing your Two Stage loader and I just thought I’d let you know that in Stage One it might be a good idea to put the memory page for $FFA2 back to normal before the program exits and moves on to Stage Two
>>>>> 
>>>>> I changed the code from:
>>>>> LOADER3 JSR     $A42D   ; close file to be polite
>>>>>      ORCC    #$50    ; disable interrupts to prevent crash
>>>>> 
>>>>> To:
>>>>> LOADER3 JSR     $A42D   ; close file to be polite
>>>>>      LDA     #$3A    ; Put BLK 2 back to default
>>>>>      STA     $FFA2   ; page of $3A
>>>>>      ORCC    #$50    ; disable interrupts to prevent crash
>>>>> 
>>>>> Cheers,
>>>>> Glen
>>>>> 
>>>>> 
>>>>>> On Feb 13, 2017, at 9:44 PM, William Astle <lost at l-w.ca> 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.
>>>>>> 
>>>>>> I did write a "paper" on loaders some years back which might be of use if you go that route. You can find it on my web site in the "Coco" section under "Projects". For ease in finding it, here's a direct link to the relevant page:
>>>>>> 
>>>>>> http://lost.l-w.ca/0x05/projects/coco-stuff/
>>>>>> 
>>>>>> In the PDF, there's an auto-executing example that loads any number of blocks of data from the same file as the main program which would mean you could have everything in a single file. There's also an example of how to do a two stage load that allows you to overwrite anything though that can get complicated.
>>>>>> 
>>>>>> On 2017-02-13 03:48 PM, Glen Hewlett wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> I’m currently using lwtools to assemble my transcoded z80 pacman to the 6809 and I’m getting close to the $E00-$7FFF range and I was wondering what are my options once my source code starts to go over the $8000 point and will start loading over Extended Color Basic and it will then fail loading won’t it?
>>>>>>> 
>>>>>>> Is there an easy way that doesn’t require me to make my own disk loader program?  It would be amazing if such a feature was built in to lwasm.
>>>>>>> 
>>>>>>> Currently I’m using Basic to load the ROMs and the character and sprite data in blocks of $2000 and moving them to other blocks of memory not needed during execution.  Then it loads the main program but when my code gets too big this is going to be a problem.
>>>>>>> 
>>>>>>> If I do have to use a special loading program is there one that already exists that I can use for such a job?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Glen
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Coco mailing list
>>>>>> Coco at maltedmedia.com
>>>>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>