🚀 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

In article <1102@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes:
>
>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?
>Will we have to "poke" the GIME chip's DAT registers "by hand?"
>
Don't quote me, but I believe Level II has syscalls for swapping around the
memory.
>
>PS: Is the Coco III keyboard truly interrupt-driven, or does it
>still go dead while the disk is transferring data?
>It's hard to call Coco OS9 "multi-tasking" until this restriction
>goes away.
> 
It's not the keyboard that is the problem, it's the disk controller.
The disk controllers (all of them, clones etc.) use the 6809's HALT
line to synchronize data transfers. This means that the CPU is  halted
during the time that it is waiting for the next byte from the controller.
This makes it rather hard to run any other tasks while the disk is transfering.
OS9 also turns off interupts during the actual disk transfer. That is why
the keyboard goes dead, since it is scanned on clock ticks.
(Thats also why the clock loses time more when you do more disk accesses.)
The fix, to make both Level I and II work better, is a real DMA disk interface.
Unfortunatly that would probably lead to compatability problems between
the old and new interfaces. (IE the DISK BASIC ROM's probably wouldn't work
with a new controller.) OS9 is still multitasking, its just that one task
(the disk driver) hogs the buss and preempts all the other tasks.


-- 

               Roger Sanderson P.Eng.
               Electrical Engineering Dept.
               University of Waterloo
	       Waterloo Ontario Canada
               N2L 5E6
               519-885-2122 Ex.6184

               {decvax,allegra,ihnp4}!watmath!watale!rsanderson