Re: Idea: Multitasking graphical OS for the GS

["geoff" <geoff@a2central.com.remove-g3g-this>]

  To: Eric Rucker

Fully understanding the toolbox, GS/OS, and the 65816 processor is extremely 
important to develop preemptive multitasking on the IIgs.

I think you will find GNO/ME does many things right already (basic kernel, 
context switching, etc) that you also find in ELKS or uCLinux.  GNO/ME patches 
GS/OS and the toolbox to get it functional to the state that it is now.  It 
makes more sense to extend GNO/ME then to start from scratch.  A GUI 
environment has additional states to track during context switching.  Take a 
look at The Manager and/or MultiGS documentation to see what issues they 
faced.

If GNO/ME is then modified to start in a GUI instead of the text command line, 
users will be willing to use it, especially if it provides the multitasking 
solution and runs reliably.  This wouldn't be much different than Mac OS X--it 
is basically a UNIX with a set of GUI tools on top.

Since you are proposing to preempt tool and maybe GS/OS calls, you may want to 
document your ideas and have it reviewed by your peers to ensure technical 
viability.  Apple developed the IIgs as a single-tasking OS so there will be 
many challenges to overcome.  It would be a shame to spend months on 
development and then discover hurdles too difficult to overcome.

Geoff

 > On Jan 1, 6:24=A0pm, Sheppy <the.she...@gmail.com> wrote:
 > > This is something I thought about a lot over the years. =A0I even wrote a 
 > > paper in college about such an operating system, with basic design 
 > > concepts and the like laid out. =A0I toyed with code on and off for a 
 > > while but never made all that much progress since it's a big project
 > > and I had so many other things I wanted to work on.
 > >
 > > With enough interested people working on it as an open source effort,
 > > I think it's feasible and could be a fun project.
 > >
 > > Sheppy
 > 
 > Yeah, that's why I'm thinking open source - more interested parties
 > could participate. (And, I don't claim to actually be a programmer,
 > so... I know the concepts, but implementing them is a weak point for
 > me.)

 > Anyway, I was doing some research on ELKS as a possible basis for the
 > OS (why reinvent the wheel if there's already a suitable OS?) and saw
 > some references that Minix's 64k program, 64k data restriction on the 
 > 16-bit x86 CPUs actually wasn't because of it being 16-bit, but rather 
 > because of an artificial address space limitation in the 16-bit x86 - 
 > apparently, it can only handle 64k segments of RAM, despite having a 20-bit 
 > address space, thanks to full assembly backwards compatibility
 > with the 8080 and 8085. I know the GS does something similar, but the 65816 
 > does have true 24-bit addressing... I don't fully understand how
 > the GS's bank addressing works, though. Could you safely ignore it, 
 > especially if you allocate a memory sandbox of sorts for the toolbox
 > to play in? (Keep in mind that I also don't fully understand the
 > toolbox, but do think using it would be a good idea for handling the
 > GUI.)