Path: utzoo!attcan!uunet!unisoft!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.sys.mac Subject: Re: 4 Meg simms Message-ID: <311@taniwha.UUCP> Date: 14 Dec 88 05:07:28 GMT References: <19553@uflorida.cis.ufl.EDU> <246@taniwha.UUCP> <6051@hoptoad.uucp> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 27 In article <6051@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >A lot of people have mentioned that the Mac II OS can't cope with more >than 8 megabytes of RAM -- here's why. The ROM starts at the 8 meg >mark. I guess A/UX gets around this by using the PMMU to remap it. >This implies that the Mac OS won't be able to cope until it has PMMU >support (which will be a great day for us developers), and of course >you'll need to buy a 68851 to have more than 8 megabytes. The Mac hardware PHYSICALLY maps ROMS at 0x40000000, (but degeneratly so that 0x40800000 works too), RAM space is available from 0x00000000 to 0x40000000. The black fake mmu thingy in the PMMU's socket remaps this so that the top 8 bits coming out of the CPU are ignored and ROM is remapped down to 0xXX400000, slots to 0xXXS00000 etc It's pretty trivial to make a PMMU do the same thing (that's how come I can boot my Mac II under the MacOS with a PMMU in the socket). The A/UX kernel of course doesn't have to run in 24 bit compatability mode so all that RAM space is available .. plus any that's on the NuBus (like the Nat Semi board). Processes are paged so where they are physically doesn't really matter (they might be on disk). Paul -- Paul Campbell ..!{unisoft|mtxinu}!taniwha!paul (415)420-8179 Taniwha Systems Design, Oakland CA "Read my lips .... no GNU taxes"