🚀 go-pugleaf

To: coco@pucc.princeton.edu
Reply-To: m.j.knudsen@att.com


>understand using MWC... I've got one module that compiles to 34k and
>has a 9k data area (total 43k).  Problem is, it's not LOADable.
>That is typing "load prog.mod" at the OS9 prompt returns an error
>#207 (memory full).  However, just typing "prog.mod" at the OS9
>prompt and executing it that way works fine, and once it's in memory
>and executing, I can use "link prog.mod" to keep it from being
>unlinked at termination.

I think what's happening is that if you just say "prog.mod"
then the only thing in memory besides prog.mod is your shell
process.

If you say "load prog.mod" then LOAD has to have its 8K of program RAM
and 8k of data RAM.  Note that your prog.mod takes 7 blocks (5 code,
2 data).  OK, well, 6.5 blocks of program -- this matters saometimes,
since the top 8K block must really be under 7.5K, since the top
512 bytes are reserved for interrupt vectors, I/O, and some
special code that OS9 uses to copy data between User and System spaces.

I know that OSTerm (pre-swapping version) could be run but not
LOADed, just like your prog.mod.

Years ago I wrote a couple little utilities that I may have
uploaded to Delphi, called NMLink and NMLoad.  They used the new L2
system calls that can load or link a module WITHOUT mapping it
into your current process' address space.  So with these you can
load/link full 63.5K programs like OSTerm.

If you had NMLoad I'd bet you could load your prog.mod.
BTW, UltiMusE-II's main program maps out like this:

16K Data, including stack
 8K Virtual-Memory data page
 8K Swapped subroutine/function page
31.5K Main resident program

Lots of linking & loading going on there.... mike k