Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 2, 6:08 pm, "geoff" <ge...@a2central.com.remove-g3g-this>
wrote:
>   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.)

This is all why I posted my ideas here, rather than trying to
implement them without understanding what I was doing. ;)

I will take another look at GNO/ME... that may be the way to go,
because of how it hooks into the existing GS/OS. Use it as the
multitasking kernel, add in a toolbox interface, and go from there.