On Sat, 7 Oct 2000, Dave Huang wrote:

> Yeah, the Ensoniq sound chip supported stereo output (8 channels,
> actually), but the audio out jack was mono only. There was a connector
> on the motherboard that had a multiplexed audio output, along with 3
> bits of channel number, so you could buy an addon card that would look
> at the low bit of the channel number and demultiplex and amplify the
> output. Input was mono though; if you wanted stereo input, you had to
> buy a card with its own ADCs.

Yeah.  I was amazed that it even had an input.  :-)  I remember building a
project box to feed it a signal.  Worked pretty poorly, but it worked.


> I can't think of anything that would qualify as even a primitive PMMU...

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 :-)


> there is, however, a product that gave you a preemptive multitasking
> unix-ish environment: GNO/ME (GNO's Not Orca/Multitasking Environment :)
> http://www.hypermall.com/companies/procyon/gnome.html The big limitation
> is that due to the way the 65816 CPU works, the stack has to reside in
> the lower 64K of RAM,

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.

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....

Either that or keep a control stack and a data stack in two different
places and don't purge it on context switch and restore on the switch
back.  Leave it in bank zero and do occasional defragmentation of bank
zero.  (With stack pointers stored in the process table, this shouldn't be
hard for the OS to do safely).

Sick idea?


Later,
David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.