Re: 65816 abort line on the AppleIIgs

[mjmahon@aol.com (Michael J. Mahon)]

Roy wrote:

>Michael J. Mahon wrote:
>> Roy replied:
<snip>
>> A virtual memory scheme can also support more total memory
>> space than the processor can simultaneously address.  In such
>> an approach, the processor's effective addresses are extended by,
>> for example, a process id, which is then mapped into the physical
>> memory through page tables.  This is a "segmented" virtual
>> memory, since the high order virtual address bits do not participate
>> in the processor's effective address calculations.
>> 
>> In both schemes, it is common to associate interprocess access
>> permissions with the page table, allowing "protected" multi-
>> programming and controlled interprocess communication.
>> 
>> It sounds like you are thinking more of the second scheme, 
>
>Exactly.
>
>to
>> permit more real memory to be used than the processor can
>> directly address.  In this scheme, the physical memory may be
>> much greater than the processor's address space (16MB), and
>> paging to disk may be a non-issue.
>
>The LIM EMS specs 3.2 and 4.0 did this, allowing (under 3.2) an 8086 to 
>address 8 megs of RAM (4.0 was more, but I can't remember how much more 

Strictly speaking, it didn't increase the amount of memory that
the 8086 could _simultaneously_ address, but simply standardized
a bank switching scheme--much like RamWorks did for the Apple II.

At an application level, if data memory was always accessed using
certain standardized library routines, then it created the software
abstraction of a larger virtual address space (like Lissners storage
access routines in AppleWorks).  But such a scheme does not
support all the standard memory reference instructions of the host
processor--usually only load byte/word and store byte/word.

Alternatively, it may support the idea of copying or bank-switching
a software selected region of memory into one or more "windows",
where up to a "window-full" can be accessed with full generality
(but any pointers outside the "window" will need to be handled
interpretively by the storage manager).

>- it also allowed multitasking with the programs and data in the EMS 
>space.) Both specs used a 64K bank in the upper one third of the 8086 
>address space as the "window" to the EMS space, allowing a program to 
>move data into and out of the EMS space (the "L" was Lotus, as some 123 
>spreadsheets were so large they couldn't fit into the 640K of a PC's 
>user's space, and, since "A-DOS" wasn't around yet, Lotus' customers 
>needed a way to have the future then), as well as moving not just data 
>but program code: overlays, and sometimes whole programs into and out of 
>the DOS space (task switching - WordPerfect's "Library" [later named 
>"Office" before any "Suites" were ever sold] would move WP's WP, 
>spreadsheet, database, and accessory programs like calculator and 
>calendar in and out with their data in a task switching mode.)

Yes, these were all handled very much like AppleWorks handles
its extended memory through its storage manager.

>> Unfortunately, no individual program could see more memory
>> space than what the processor can currently address, since
>> all existing applications operate within the processor's address
>> space limits.  To use more address space than this would
>> require application changes, akin to explicit bank switching,
>> since the processors effective address calculations extend
>> only to its native address space.  The primary value of applying
>> this approach to the IIgs would be to permit it to multiprogram
>> multiple applications.
>> 
>> Although this would be interesting, the relatively low performance
>> of the IIgs processor generally requires dedicating it to a single
>> task at a time, 
>
>Which is why a task switching scheme would make more sense than a 
>multitasking one. Of course, currently, how many IIgs programs can one 
>fit into the 8 megs of memory space? If I had the entire Spectrum 
>Internet Suite loaded, could I also have AppleWorks GS fit in memory at 
>the same time? Can anyone conceive of loading all the programs they 
>might really want to be using, and have 8 megs not be enough RAM?

And since each of these applications could use more memory in some
circumstances, do they contain the logic to request more memory after
they have been started?  I suspect not, since the concept of using only
as much memory as you need, and requesting more as the need grows,
is a concept that comes from multiprogramming, where it is assumed
that some other task can make good use of what you are not using.

>and there are no popular multiprogramming
>> environments for the IIgs (GNO is pretty much a niche OS).
>> 
>> A virtual memory system involves some pretty specialized
>> hardware support (the address translation hardware), 
>
>That's why EMS cards weren't cheap. If done on the IIgs, I would imagine 
>that the "window" would need to be loaded in the 8 meg ROM space.

I expect that the IIgs wouldn't work if writes were done to this space.

The windows would have to come out of normal RAM space.

EMS cards were software-controlled explicit bank-switching
devices, so they only required selective re-mapping of a few high-
order address bits.  This would not have been very expensive.  On the
other hand, the large number of DRAMs on the card would account for
most of its cost.

The virtual memory support on a processor chip (TLB, etc.) is
a small, specialized associative memory.  Though it is specialized,
it does not occupy a large fraction of the chip (5% might be typical),
and so is not a primary cost determinant.  For many years, the
80386 had an on-chip TLB that went virtually (!) unused by any
Microsoft OS.

It's a lot cheaper (and faster) to build it in than to add it on externally,
as was done with the 680x0 Macs when virtual memory was introduced.

>plus an
>> OS which handles the setup of that hardware and the page
>> and protection faults which it detects.  
>
>For the PC, the EMS drivers took care of that. I would think that such 
>would also be the case with GS/OS. But it certainly wouldn't be a 
>trivial programming job.

The only way to make it truly like virtual memory would be to find a
way to reference all the memory you could ever wish for (probably more
than the 8MB supported by the IIgs hardware) and have the processor
be interrupted on any access to non-mapped memory, but allowed
to proceed at full speed if the memory were already mapped.

This would necessitate a larger-than-24-bit effective address in the
65816 and (since we're postulating a processor which does not
currently exist) a built-in TLB to efficiently handle the mapping and
interrupt when mapping fails.

Alternatively, the 65816 and IIgs could be left alone, and external
mapping hardware could support up to 8MB per application, for
several concurrently loaded applications.  This would also require
that the OS manage the mapping hardware upon task switch.

The latter is more easily done, but would offer a smaller set of
advantages.

>It seems unlikely that
>> anyone would invest the design and implementation time to
>> create these for the IIgs at this point.
>
>I think that's a realistic assessment. I was just asking "in theory."
>Thanks Michael.

It's interesting to consider "alternate realities".  ;-)

-michael

Check out 8-bit Apple sound that will amaze you on my
Home page:  http://members.aol.com/MJMahon/