Xref: utzoo comp.sys.mac.hardware:4237 comp.sys.mac.misc:1067 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.sys.mac.hardware,comp.sys.mac.misc Subject: Re: Addressable memory of 68000 (was Re: New Macs) Message-ID: <26940618.477@intercon.com> Date: 6 Jul 90 03:31:35 GMT References: <90178.172523KPURCELL@LIVERPOOL.AC.UK> <268ACACA.44FD@intercon.com> <316@opusc.CS.SCAROLINA.EDU> <1990Jul4.003731.336@hellgate.utah.edu> <26708@netnews.upenn.edu> <42651@apple.Apple.COM> <1990Jul5.204534.14336@efi.com> Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Lines: 22 In article <1990Jul5.204534.14336@efi.com>, tim@efi.com (Tim Maroney) writes: > Couldn't you do a software fix? At startup, tweak the MultiFinder > pseudo-heap so that the ROM space is marked as allocated? Nice idea, but as I remember, the Mac Plus/SE hardware doesn't do full address decoding above the 4M boundary. Normally, all this means is that the ROM image and I/O spaces are duplicated throughout the upper parts of the processor's address space. However, if you wanted to put more RAM in, you'd have to intercept the processor's address lines before they hit the normal decoding hardware (by moving the 68000 to a daughterboard, for example). If you're going to go to all that trouble, you may as well map the ROM and I/O out of the way while you're at it... The "make the ROMs an unrelocatable block in the heap" idea *is* quite clever, though. -- Amanda Walker InterCon Systems Corporation -- "I can only assume this is not the first-class compartment." --Hitchhiker's Guide to the Galaxy