Re: Another New Hardware Thought

["Michael J. Mahon" <mjmahon@aol.com>]

Jeff Blakeney wrote:
>   To: mdj
> On Wed, 2 May 2007 19:29:31 -0700, mdj wrote:
>
>
> > A curious idea, but you really need an OS to support it.
> >
> > MMU's really only become useful when you're running more code than
> > you've got RAM, facilitating virtual memory. There aren't really any
> > practical applications that such small machines can run that require
> > that amount of addressable space.
>
>
> Don't MMU's also keep tasks from writing into the memory area of other
> tasks?  Personally, I usually find virtual memory a performance hit to
> my machine that I don't much like, although it does let me run programs
> that I don't have enough physical memory for albeit slowly.
>
> In the case of an Apple IIgs MMU, having hardware memory protection to
> keep tasks from walking on each other and to inform the developer or
> user of what is happening would be fantastic.

Since any MMU is a fast table look-up of each "logical" address to
form a "physical" address (or a fault), it is quite easy to add
additional bits to regulate access, flag writes, etc.

Usually, the logical address is a large "virtual" address formed by
a (wide) processor, to be converted into a smaller "physical" address
(or a page fault, if the page is not mapped).

But sometimes, the logical address is a small address formed by a
processor with, say, only 16-bit addressing.  Then it can map a
"page" in that smaller address space to a larger physical address.
This is then a more general (discontiguous) approach to bank-switching.

However, a very simple bank-switching approach could also be used,
where a 4- or 8-bit "process ID" is appended to the left of the
processor's 16-bit address, providing rapid task switching of most
(or all) of the processor's address space.  In this situation, it is
common to provide some pages that can be made "common" to all tasks
for the purpose of communication.  Protection is easily attached to
the "common" page(s), and address space isolation protects all the
other pages.

The Apple II memory architecture since the //e has become quite
reticulated, and is not at all linear, so it might be necessary
to use 128KB as the "bank size" for each process, with Apple II
shenanigans within that space.

ROM space and I/O space would also probably be treated as "common"
to all processes, again with (at least) 6502-page-level read/write
protection mechanisms.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."