knudsen@ihwpt.UUCP (mike knudsen) (09/15/86)
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.
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?"
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?
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!
mike knudsen
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.
--
Mike J Knudsen / \ ...ihnp4!ihwpt!knudsen
/ NO \
Bell Labs / BABY \ (312)-979-4132 (work)
(AT & T) /ON BOARD\
\GO AHEAD/ BORED SAILORS
IH 6D-319 \ & HIT/ go BOARDSAILING.
x4132 \ ME /
\ /
Bell Labs pays \/ me for my thoughts; my opinions are all mine!dibble@rochester.ARPA (Peter C. Dibble) (09/17/86)
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