Xref: utzoo comp.sys.mac.misc:8042 comp.sys.mac.system:3011 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!cruff From: cruff@ncar.ucar.edu (Craig Ruff) Newsgroups: comp.sys.mac.misc,comp.sys.mac.system Subject: Re: mac IIsi slowdown (long) Message-ID: <10140@ncar.ucar.edu> Date: 1 Feb 91 16:13:45 GMT References: <1991Jan31.123728.4540@esat.kuleuven.ac.be> Reply-To: cruff@handies.UCAR.EDU (Craig Ruff) Organization: Scientific Computing Division/NCAR, Boulder CO Lines: 34 In article bruner@sp15.csrd.uiuc.edu (John Bruner) writes: >In article <1991Jan31.123728.4540@esat.kuleuven.ac.be> Patrick Wambacq >describes the bus structure of the IIsi and some experiments he >performed to increase the processor speed. I confess that I have not >seen any hard technical information about the hardware of the IIsi. According to the IIsi developer notes and my poking around the MMU page tables, this is what takes place: Bank A memory resides from 0 to 64 Mb (physical). The video part starts at 0 physical and goes until the end of the screen is reached (in what ever screen depth you are in at the moment). Bank A memory is buffered from the CPU and Bank B. Bank B memory starts at 64 Mb (physical). The MMU is programed to place all of Bank B starting at 0 (virtual). The portion of Bank A that is used for the screen is placed to look like a NuBus slot ($E, I think). The remainder of Bank A is appended to the end of Bank B in the virtual space. The effects of this is that anything that is placed into high memory will end up in Bank A first. BTW, figuring out how to access physical memory (where the page tables reside) from the virtual space without screwing up the running program was an interesting exercise. The answer is left for the student to discover. -- Craig Ruff NCAR cruff@ncar.ucar.edu (303) 497-1211 P.O. Box 3000 Boulder, CO 80307