[Coco] Syscall

[L. Curtis Boyle]

Heh… yep.


L. Curtis Boyle
curtisboyle at sasktel.net



> On Mar 3, 2018, at 12:27 PM, Mike Delyea <mdelyea at gmail.com> wrote:
> 
> Holy Cow! you typed all that on your iPhone keypad!
> 
> On Sat, Mar 3, 2018 at 5:19 AM, L. Curtis Boyle <curtisboyle at sasktel.net>
> wrote:
> 
>> 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
>>> 
>> 
>> 
>> --
>> 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
>