Xref: utzoo comp.sys.mac:31989 comp.sys.mac.programmer:6330
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!shelby!polya!shap
From: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: System 7.0
Message-ID: <9210@polya.Stanford.EDU>
Date: 16 May 89 02:36:07 GMT
References: <3234@tank.uchicago.edu>
Sender: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Followup-To: comp.sys.mac
Distribution: usa
Organization: Stanford University
Lines: 26

In article <3234@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes:
>In article <SARREL.89May14224531@galley.cis.ohio-state.edu>, sarrel@galley.cis.ohio-state.edu (Marc Sarrel) writes...
>Hm...in the 7.0 Release, it said:
>
>"32-Bit Addressing allows Macintosh computers to extend their
>memory capacities beyond 8 megabytes to 128 MB of physical RAM and
>up to 4 Gigabytes of virtual address space."
>
>
>What's the straight dope here?  Is this large address space just planned for
>future machines (with current machines being limited to 8 MB RAM/VM)?


If you actually look at the low memory pointer to the rom, you will
discover that the rom lives at address 0x40800000.  This means that in
a 32 bit system, there is plenty of room for it.  The NuBus card
addresses can already be mapped into higher memory without error (I
have done it).  The killer is tht the current ROM is not 32 bit clean.
In particular, the current ROM doesn't like to have the MMU turned on
in 32 bit mode, and the memory manager gets most unhappy.

Point is that a new set of ROMS should indeed make it possible to put
in up to 128K of real memory.  Why you would want to isn't clear, as
the system is intrinsically pretty slow.

Jon