🚀 go-pugleaf

In article <1102@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes:
> I'd like to second the request for further development
> of Emacs for OS9, especially for 80-column hardware
> like the PBJ WordPak.
> 
> What could uEmacs become on the Coco III under Level II?
> Well, to start with, could we restore one of Emacs's
> most valuable features, multiple buffers?
> I can't express how valuable these are at work, but for
> the existing Cocos uEmacs got stripped down to one buffer.
> The trick may be to create a separate Data Module for each
> file buffer being edited, and to switch the current buffer
> into the working 64K address space.  I'm thinking ahead to
> when we get 512K in the beastie.
Using data modules for the buffers would be tricky.  uEmacs stores
lines in linked lists.  Since a data module might be at different locations
each time you link to it this would have to be worried about.  They are
also difficult to expand/contract.
My first idea for handling multiple buffers is to fork a process for each
buffer.  Let it manage the buffer's memory and hand uEmacs one line at
a time through a data module.  I think uEmacs' structure would make this
"easy."
> How well does Level II provide for playing games with the
> memory mapping?  Are such tricks supported, or are Level II
> users just supposed to enjoy the one larger (almost 64K) space?

There are Level Two system calls that let you access memory by
physical address or by address space and offset.  They are NOT
very easy to figure out.  It took me many hours to decipher them enough
for the memory management chapters of the Complete Guide.

> Will we have to "poke" the GIME chip's DAT registers "by hand?"

   A very bad idea.  You could get OS-9 all wrapped around the axle.

> 
> On that topic -- we know that since Level II switches out OS9
> itself while a user's process is running, each process can have
> almost 64K.  Can I assume the reverse also, that my version of
> OS9 (booted plus any LOADed modules) can be almost 64K too,
> or at least a lot bigger than under Level I?

You can assume that -- with warnings.

> I mean, no more ripping out Pipes, graphics, and modem drivers
> just so I can compile larger C programs?  Imagine, putting
> everything back in the bootfile, and then some!
> 

Don't put non-OS stuff in your bootfile.  When OS-9/L2 processes
do a link, they map the address space of the module you link to into
your address space.  If you put a module (say GoToXY) in OS9Boot and
link to it from an application, the application gets all the modules
in the boot mapped in.  This is a dandy way to use up lots of memory.
Since the CoCo3 uses 8K pages, the optimum way to load modules is
from files with just under 8K in them.  You use at least one page
for each file you load so you might as well fill it.

Peter Dibble