Re: X server for GNO/ME

[dempson@atlantis.actrix.gen.nz (David Empson)]

[Note: this discussion is getting rather technical, so I've added
comp.sys.apple2 to the newsgroups list, and directed follow-ups there.]

In article <49q0nv$mth@nnrp3.news.primenet.com>,
John Bowling <johnlb@Primenet.Com> wrote:
> In article <49ih2u$add@cville-srv.wam.umd.edu>,
> David R. <snakey@exp3.wam.umd.edu> wrote:
> >
> >...but the fact that a GS can have only 8 megs of ram and no virtual
> >memory, as well as the fact that the GS has no memory protection are
> >serious problems.  I seem to remember someone saying at one time
> >that it would be possible to add a small piece of hardware to the GS
> >that'd add in the capability for virtual memory.

I don't know about "small", and it isn't just a question of hardware.

The 65816 provides an ABORT input which can be used by external
hardware to implement memory protection, by aborting an instruction
when an illegal access is performed.

The ABORT signal is available on the memory expansion connector, so, in
theory, a memory expansion card could implement some kind of memory
protection system.

There are some problems using this: certain instructions cannot be
aborted cleanly, and there are likely to be holes due to limitations
of the IIgs architecture (e.g. it is not possible to use the Valid
Program Address and Valid Data Address signals to qualify memory
accesses).

Memory protection should be relatively easy to implement.  The main
problem is working out what areas need to be protected, and being able
to change the protection under special situations, e.g. when an
interrupt occurs.  Multitasking situations (including context switches
such as with NDAs) would also need special handling, probably with
support at the operating system and toolbox level.

An actual virtual memory system would be a LOT harder.  It would
probably require complete replacement of the Memory Manager toolset,
and a fair part of the operating system as well.  The system virtual
address space could not easily be expanded above 16 megabytes, because
some code uses the high byte of a four-byte pointer to store special
information.

> The memory protection would be quite easy designed into a when a 
> memory board.  It might be possible to add a IIe style memory board that is
> paged with 64K protected banks allocatable to specific users or processees.
> It would be slow though at a 1MHz bus rate.

A card in a standard slot cannot be addressed as normal memory, unless
it makes use of the INHIBIT signal, which requires the IIgs to run at 1
MHz whenever the signal is to be used, and only banks 0 and 1 can be
affected.

> Has anyone checked into what problems there would be with GS/OS if the upper
> 8 meg were to be made available via hardware mods?

The Memory Manager is likely to be the main problem.  It
only supports fast memory up to 8 MB.  Some fiddling with the
low-level data structures would be needed to allow it to access memory
in banks $80 to $DF.

Hardware compatibility is unknown - the FPI chip might not provide the
right signals to access memory via the expansion slot if you address
banks $80 or higher (except $F0 and up, which are for ROM expansion
and a ROM disk).  It certainly won't provide memory refreshing for
dynamic RAM.

Another problem would be compatibility with accelerators.  The
TransWarp has some special stuff in the higher $Dx banks.  I expect
both cards have built-in assumptions about the memory architecture of
the IIgs.


One way to do all this cleanly would be to design a new accelerator
which provided the desired functions on the card itself - extra
memory, hardware support for memory protection and virtual memory,
etc.  Then all you have to worry about is the software.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand