On Sat, 7 Oct 2000, David A. Gatwood wrote:
> You're right.  The P was out of place.  It did some bank-switched stuff,
> as I recall, where certain parts of one bank could be mirrored on other
> banks (used for video and some other reasns that escape me), but....  How
> exactly would you categorize that?  (Besides old :-)

Hmm, I dunno :) I think all of that was done for backward compatibility
reasons... the real video and I/O card memory was in banks $E0/$E1,
which ran at 1MHz. The rest of the RAM ran at 2.5MHz or so, and the
video and I/O space in banks $00/$01 would be shadowed over to $E0/$E1
(although that could be disabled if you wanted).

> Yes, and no.  The stack register is only 16 bits, so if you're indexing
> onto the stack directly, this would be true.  However, these sorts of
> limitations can be gotten around with a little compiler glue.  There's an
> instruction to transfer the stack pointer into the accumulator.  You can
> then add a bank offset, then index with another register.  It's a pain in
> the ... but it's possible.  Of course, rts/rtl becomes a problem.  That
> sort of trick only works for the data portion of the stack.

I bet performance would suffer a lot though... especially if you also
avoid the use of the "zero page" (also located in precious bank 0 space
:). I seem to recall that all indirect indexing had to be done through
pointers in the zero page, so I think use of at least _some_ ZP memory
is pretty much unavoidable. The compiler glue bit might be problematic
too... there was an attempt to port lcc (from Princeton) to the IIgs,
but it wasn't ever completed. Might not be a problem nowadays though,
especially if you only want a cross-compiler; doesn't gcc target the
'816?

> Consider the following grotesque thought: in the context switch to a task,
> copy only the subroutine returns into a "control stack" in bank zero.  On
> the context switch from a task, nuke it and replace it with the pseudo
> stack of another process.  If a function call occurs or if one returns, it
> will have to adjust both stacks, but otherwise....

I think that'd work :) Of course, GNO/ME was designed to support all the
existing GS apps and utilities for the ORCA shell (most importantly the
development tools :) Changing the way apps used the stack would require
new apps...

However, the company that made GNO/ME had another product that would let
you switch between multiple GUI apps (sort of like a MultiFinder, but
without the multitasking :) It copied an app's entire stack/zero page
space out of bank 0 when it was switched out, and restored it when the
app was switched back in. Switches weren't happening 60 times a second
though, so copying all that data wasn't a problem.

Now if someone came up with a PMMU addon for the GS (I think the '816
actually had the pins to support one), I'd love to see a real port of
BSD to it :) I was running NetBSD on a 4MB 386/25MHz for a while (since
upgraded to an 8MB 386/33 :), and it was quite usable... my 5MB 12MHz
IIgs shouldn't be _too_ bad :) I'm sure the lack of 32-bit registers
would hurt a lot though...