[Coco] Syscall

Sat Mar 3 22:16:03 EST 2018

Cool the mem 24000 worked.

On Sat, Mar 3, 2018 at 8:54 PM, Wayne Campbell <asa.rand at gmail.com> wrote:

> 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/
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>