Date   : Mon, 19 Apr 1993 01:05:32 +1200
From   : David Sainty <terros@...>
Subject: Re: A new OS layer?

"I Stephenson" <ian@...> writes:

> I spent quite a while a few years ago writing a multitasking system which use
> sideways ram to hold the images - each image was limited to 16K, but each cou
> then be assembled to run at the same location (0x8000), and was protected fro
> messing with the others data. A 6522 interupt switched between the currently
> active images.
>
> What I had worked fine, but in the end it just got too messy. The problem was
> ensuring that critical routines weren't interupted - in particular most of th
> OS routines re-enable interupts, and hence couldn't be called directly from t
> images.

Did you try using the PC at interrupt to check whether it was in an OS routine
or not? I was thinking about process suspension, in particular being able to
suspend a current process and then set it running in the 2nd processor in the
background. This is the way I was considering ensuring OS and filing calls
didn't clash.

> I'll probably release the stuff before this work is done so I get some feedba
> (I don't realy fancy rewriting the shell myself in any case :-). Despite the
> above warnings it does actually work! It feels sluggish due to the swapping,
> but I've certainly used worse. Being able to write scripts, and redirect outp
> is definatly worth the wait.

It'll be interesting to see!

As you've gone the way of needing to write from scratch any utilities you
intend to use, why not make the program inform the system of memory
requirements etc. Then just store the process information and program in main
memory if it's free. Much faster than disc access. The other one is: support
relocation! Make it mandatory that a program can be relocated, either by a
built in routine in the program, or perhaps a file with a list of offsets into
the programto add the program start page to.