[Coco] Syscall

Sat Mar 3 20:12:23 EST 2018

Here is the code

TYPE r=cc,a,b,dp:BYTE; x,y,u:INTEGER
DIM regs:r

10 regs.a=0                             \ (* <-std input *)
regs.b=$26                              \ (* <-SS.ScSiz *)
RUN syscall($8D,regs)
sizeX=regs.x                            \ (* Window Width *)
sizeY=regs.y                            \ (* Window Length *)

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
>