[Coco] Syscall

[Wayne Campbell]

You are misunderstanding. I'll try to explain. What Curtis is asking is,
how many procedures are in the workspace, is the code you show in a
procedure by itself or is it part of a larger procedure, and is the first
line of the source for the procedure a PROCEDURE statement (ie. PROCEDURE
myProgram).

You also need to understand what is causing your 43 error. Your Basic09
workspace is full with the procedure(s) you have in it. There is not enough
free space to run the procedure and run syscall too. If you are not using
memory modifiers to increase the workspace size, all you need to do is
increase the workspace size. You can do this from within Basic09 by typing
mem and the size you want (in bytes). For example, to increase to (roughly)
24k, type mem 24000. From the command line, you can run Basic09 using a
memory modifier to open it with a larger workspace. For example, Basic09
#24K will open basic09 with 24k of workspace memory. Any amount above 32K
will give you problems when it comes to running the program from within
Basic09. You will likely have to pack the procedure and run it from the OS9
command line. For example, OS9: myProgram.

This is all elementary explanation. I hope you are understanding what I am
saying. If increasing the workspace memory doesn't work, you will have to
pack the procedures and run them from the OS9 command line. I only have
this problem with procedures that require me to open Basic09 with large
workspace sizes (above 32k).

You can ask if you have more questions and I will try to answer them.

Wayne



On Sat, Mar 3, 2018 at 5:32 PM, phil pt <ptaylor2446 at gmail.com> wrote:

> No, Nothing in the other parts of the code does not have anything to do
> with interfering with the syscall routine.
>
> On Sat, Mar 3, 2018 at 8:30 PM, L. Curtis Boyle <curtisboyle at sasktel.net>
> wrote:
>
> > That’s the entire program? Is their a PROCEDURE (program name) above what
> > you have shown here?
> >
> > Sent from my iPhone
> >
> > > On Mar 3, 2018, at 7:12 PM, phil pt <ptaylor2446 at gmail.com> wrote:
> > >
> > > 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
> >
> >
> > --
> > 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
>



-- 
Wayne

The Structure of I-Code
http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code

decode
http://cococoding.com/wayne/