Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 1, 6:24 pm, Sheppy <the.she...@gmail.com> wrote:
> This is something I thought about a lot over the years.  I even wrote
> a paper in college about such an operating system, with basic design
> concepts and the like laid out.  I 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.)