Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Apple IIGS's Memory Limit
Message-ID: <16483@smoke.brl.mil>
Date: 22 Jun 91 04:57:17 GMT
References: <1991Jun20.221622.561@crash.cts.com> <17284@darkstar.ucsc.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 33

In article <17284@darkstar.ucsc.edu> unknown@ucscb.UCSC.EDU (The Unknown User) writes:
>	If more memory were needed (I think 8 megs is a HELL of a lot, 
>and even if a MultiFinder GS ever existed, I doubt you'd ever fill that much),
>go through the bother of building in VIRTUAL memory, which makes more memory
>invisible to the application.. That is, the operating system handles 
>dealing with more memory, rather than the program doing bank switching
>crap.

I agree that explicitly dealing with bank switching is crap.
However, I disagree on other points.
No matter HOW much memory (also disk, also CPU power) one has,
he can devise an application that genuinely needs more.
More frequently, the programmer has assumed that a particular
implementation technique will suffice for virtually all uses of
the program; the most common example on the IIGS is requiring
all data of a certain type to fit into an array contained in
one 64KB data bank.  This sort of program limitation is avoidable,
but often avoiding such restrictions requires more work on the
part of the programmer, and if it is not perceived to be a
potentially frequent problem, many programmers would not bother.

In fact, 8MB is not very much memory by the standards of a lot of
applications that I've developed.  Such applications are cramped
when ported to the IIGS.  However, CPU power also gets to be a
factor when large amounts of data need to be processed, so 8MB
may be a fairly good match to the 65816's computational abilities.

One should not rely on virtual memory to extend the address space.
While it technically does that, it does so at a severe cost, such
that in many cases one would be much better off redesigning the
application to take EXPLICIT control over disk I/O rather than
allowing uncontrolled IMPLICIT disk I/O to occur via the virtual
memory system.