[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea: Multitasking graphical OS for the GS



Eric Rucker wrote:
On Jan 1, 7:07 pm, Michael Black <et...@ncf.ca> wrote:
On Thu, 1 Jan 2009, Eric Rucker wrote:
I've been thinking about stuff, and got to thinking... it'd be
interesting if there were a semi-modern, multitasking, graphical OS
for the IIGS - not necessarily backwards compatible with GS/OS. (The
semi-modern bit means... The Manager on GS/OS does NOT qualify. ;))
Anyway, I'm thinking that starting from scratch with the OS might just
be the best bet - unlike GNO/ME, which uses GS/OS for a lot of stuff.
That doesn't mean that I'd be shunning all of the built-in IIGS stuff
- the Toolbox would come in handy for the GUI. (FWIW, I think I know
how I'd handle the toolbox in a multitasking environment - simply
create a "virtual toolbox" that apps for this OS would make calls to,
and then pass those calls onto the real toolbox. As far as the real
toolbox is concerned, it's just one app with a bunch of windows, that
wants to change its menus. A lot. ;))
But, I suspect a modern multitasking kernel for all of this would be
more efficient. I know, there's no MMU. That never stopped Minix or
ELKS...
There was multitasking on 8bit computers.  I seem to recall Microware
had it on the 6800, and there might have even been an article about
a multitasking monitor or kernel in Kilobaud (I can sort of picture it).

Then of course, Microware did come out with OS-9 for the 6809, which
admittedly is fancier than the 6502.

The concept of multitasking was fairly easy, there was a book about the
68000 that had a monitor or kernel that multitasked.  Dr. Dobbs probably
ran some stuff on that too.

It just really depends on what you want.  In the old days, the operating
systems were pretty simple, indeed some times it was just a matter of
running two programs that stood alone, the multitasking just being a
switch between the two.  An obvious example was a print spooler, sharing
the CPU to send the characters to the printer in the background.  Those
were described back then too.

Even Unix was simple to begin with, the PDP-11 that it was originally
run on did not have memory management.  Of course, Unix was far more
than the kernel, it was the utilities and the applications that made
it useful, not so much the kernel.

Minix of course was designed to teach about operating systems, so one
might more properly be thinking about Minix in what it can teach about
the concepts, rather than a source to

You really have to decide what you are trying to do.  Do some background
tasking, or a full blown OS?  A completely new system that runs on
the 65816 (or even 6502?), or something that does multitasking but
allows existing programs to run on top of it?  That last is likely
the most useful, since then you have things to actually do with
this OS, but is also likely the hardest since one has existing
specifications to meet.

   Michael

Speaking of Minix, I'm almost wondering if some heavily-modified Minix
derived kernel would do the trick. The stock Minix memory manager can
only handle 64k of code and 64k of data per application on a 16-bit
CPU (I think that's a word-length restriction,) but maybe that could
be fixed? Binary compatibility with Minix would be unnecessary, so...
And, IIRC, it has installable file systems, and stuff like that, which
would work nicely in the IIGS ecosystem.
But, Minix is just an idea, and isn't necessarily the best one. It's
just something to think about.
Is anyone interested in such an OS? Either using it, developing it, or
developing for it?

I'm aiming for a completely new full-blown OS. Maybe it can extend
that "virtual toolbox" idea I had for making the GUI work to
everything that the IIGS uses now, and maybe even just using a couple
elements of Minix (the kernel and some of the driver architecture, for
instance) or another OS to provide a kernel for this OS. That would
facilitate porting of toolbox applications, as you could just
recompile to the new target.

I've obtained a copy of the second edition of Operating Systems:
Design and Implementation, so I can study this. I think my first goal
will be to try to get a barebones Minix 2.0 setup running on a GS
emulator, and work from there, figuring out what's needed and what's
not needed.

Multitasking/multiprogramming OS's have been written for a very large
number of machines, some of which would be considered tiny by even
6502 standards.  Complexity is kept down by restricting the number
and type of machine resources that you want to allocate/share in a
dynamic way, administered by the OS, versus those that you are willing
to allocate/share statically or "manually" by code in the tasks.

The more machine resources you want to virtualize, the more work you
have to do, and the more work the machine has to do.  If the resources
are shared frequently, overall efficiency will suffer, since many
machine cycles will go into presenting the illusion that each app
"owns" the virtual resources.

Memory is one obvious "fine grained" resource that is frequently
used.  If it is desired to allocate it dynamically to tasks of
differing memory requirements, then you must be able to find and
relocate all references to memory addresses that may need to change.
This is sufficiently difficult that mapping hardware is often devoted
to doing this dynamically.

Sharing a screen is another common fine-grained interaction between
tasks, which can be very simple--though possibly time-consuming--if all
tasks will scale their display requirements to a window, or very
difficult if tasks think they have access to the whole screen.

Of course, if you can allocate the machine's resources statically, or
nearly so, you can avoid significant overhead--but at the cost of
constraining the generality of the applications you can support.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."