[Coco] Syscall

[L. Curtis Boyle]

How big of a buffer space are allocating BASIC09 (when you invoke it from the command line)? Wayne is right in that it will consume a lot more RAM when merged with RUNB. This is because every user program gets a maximum (without fancy things like CHAIN, etc) 63.5K workspace. And each time you load program modules (like BASIC09, RUNB, etc, they get loaded into MMU blocks of RAM (each MMU block is 8K). OS-9/Nitros9 loads programs at the highest point of available RAM your 64k workspace, in MMU sized chunks. (There is 512 bytes at the very top that is reserved for I/O with hardware, and the task switching part of the kernal, so that is off limits to you and your programs). So, if your program (or merged programs) take 7.5k or less, it will take the full 7.5K (because the MMU can only map fixed sized blocks). If they take between 7.5K and 15.5K, it will take the full 15.5K, etc (just keep adding 8k). 
 So, if you load BASIC09 (which is 23k, roughly), that will take 23.5k from your 63.5k (plus at least 8k for its internal variables, and your procedures).  If you have syscall, etc merged with RUNB, when it try’s to add that into your workspace, it brings the entire merged chunk in (and since RUNB itself is about 12k, that gets rounded up to 16k for the MMU - you now have 23.5k for BASIC09, 16K for RUNB, syscall, inlet, etc) plus at least 8k for your procedures, etc - so you are at least taking up 48k of your workspace. If your program is bigger, you rapidly run out of room. 
Depending on the size of your program, you could UNLINK RUNB and it’s merged modules until you get an error 221 (which means it is really out of RAM, and then load in a merged file of inkey , syscall and your other routines (but *NOT* RUNB), which could fit into 8k (rather than 16k with RUNB), and see if that gives you enough space in BASIC09.  You can then do debugging, etc. normally. If that still isn’t enough room, then you may have to pack the code first, and just run it from your merged RUNB, and only use BASIC09 to edit and pack the program, but not be able to use the interactive debugger. 
(Another sneaky way that *might* work is to merge syscall, inkey and your already packed/debugged procedures with BASIC09 itself - maybe name that file BASIC09-myproject), unlink BASIC09 (as above) and RUNB, and then load the BASIC09+inkey, etc, which may reduce your memory footprint further to allow you to use the debugging features. When your program is completed, use the merged RUNB instead. Just remember to unlink BASIC09 and it’s merged modules before that (or before starting another BASIC09 project), so you aren’t always bring those extra modules in every time you run BASIC09. 

(If you are technically minded and want to get fancy, you can rename the merged modules in there actual headers, so that one character is different (ie inke2 instead of inkey, for example), and debug the program using the renamed ones. Once your program is done, change those RUN xxx2 back to the normal xxxx, save it and then pack that version, and that can run “normally” with RUNB. )

The other option is to chain procedures, because it can unlink the old modules and run the next one, taking place of the first one(s) in memory. 

Sent from my iPhone

> On Mar 2, 2018, at 9:46 PM, Wayne Campbell <asa.rand at gmail.com> wrote:
> 
> It's not about how much free space you have. It's about how big the memory
> block is that's holding syscall and whatever is merged with it. If the
> block is more than 8K, basically long will have a hard time loading it in.
> I can have syscall gfx gfx gfx2 and inkey merged together and it will work
> okay. If I merge all of those with runB and preload runB, basic09 will
> still run into the problem and report a 43 error when trying to run the
> program in its memory. I do not know exactly what the cause is other than
> it has to do with the amount of memory that it is dealing with where
> syscall is concerned. The same applies to any other subroutine that you
> have merged with syscall. If separating syscall by itself still has the
> problem then I don't know what to tell you. If you have not tried loading
> syscall by itself with nothing else merged with it I suggest that you try
> doing that and see what the result is. If it works with syscall by itself
> then whatever you have merged with syscall is exceeding the 8K boundary and
> that is what the problem is. If syscall by itself does not work then you
> are experiencing a different problem and I do not know what to do about it.
> 
> 
>> On Fri, Mar 2, 2018, 7:34 PM phil pt <ptaylor2446 at gmail.com> wrote:
>> 
>> I already tried loading Syscall and then the program and I am getting the
>> same issue, Then I tried merging runb syscall centertext and errmsg and
>> that did not resolve the issue.  When I type mfree It displays that I have
>> plenty of memory available
>> 
>> On Fri, Mar 2, 2018 at 10:01 PM, Wayne Campbell <asa.rand at gmail.com>
>> wrote:
>> 
>>> I run into this problem a lot. What's happening, is that basic09 is
>> trying
>>> to load all of the parts that are merged together into the workspace at
>> the
>>> same time and it's not working. The best way to deal with this issue is
>> to
>>> make sure that you have enough space available in the workspace and load
>>> syscall by itself into memory before running your program. This is not
>> the
>>> best way to deal with these things but at this point it's the only way I
>>> found to deal with it while working in basic09. Perhaps Curtis or someone
>>> else can provide a better way.
>>> 
>>>> On Fri, Mar 2, 2018, 5:58 PM phil pt <ptaylor2446 at gmail.com> wrote:
>>>> 
>>>> I am getting error 43 while trying to call syscall in my basic09 code.
>> I
>>>> have the correct type and runb and syscall merge.
>>>> 
>>>> --
>>>> 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
>>> 
>> 
>> --
>> 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
>