norman@okstate.UUCP (10/01/87)
Does anyone out there know what it would take to have demand paging virtual memory on the Mac II? Could it be as simple as plugging in a 68851 and writing an interrupt handler to take care of swapping the pages? I know, I know... The next thing I'll be asking for is a virtual machine operating system :-) Hey... that might be pretty neat at that!
chow@batcomputer.UUCP (10/03/87)
In article <2653@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: >Does anyone out there know what it would take to have demand paging virtual >memory on the Mac II? Could it be as simple as plugging in a 68851 and >writing an interrupt handler to take care of swapping the pages? > One thing which you might want to question is whether if you want to add an 68851 MMU to your Mac II. I'm not a hardware guru, but from what understand, the 68851 chip adds wait state(s) to every memory reference. How's that for slowing down your machine. Note that Suns, etc., all use their custom MMU chips to avoid the wait state problems with the Motorola chip. Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699, USPS: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/04/87)
>One thing which you might want to question is whether if you want to add an >68851 MMU to your Mac II. I'm not a hardware guru, but from what >understand, the 68851 chip adds wait state(s) to every memory reference. Right. One Wait-State as Peter tells me. That and a 16 bit data path (correct me if I'm wrong, this is 5 times handmedown info). Still, it's a pretty damn fast machine. -Matt
jww@sdcsvax.UCSD.EDU (Joel West) (10/04/87)
It would take plugging in a 68851 and waiting about 18 months
for Apple to develop a virtual memory capability for the Mac OS. :-)
--
Joel West (c/o UCSD)
Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083
{ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edu
or ihnp4!crash!palomar!joel joel@palomar.cts.comstew@endor.harvard.edu (Stew Rubenstein) (10/04/87)
>In article <2653@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: >>Does anyone out there know what it would take to have demand paging virtual >>memory on the Mac II? Could it be as simple as plugging in a 68851 and >>writing an interrupt handler to take care of swapping the pages? In article <2542@batcomputer.tn.cornell.edu> chow@tcgould.tn.cornell.edu (Christopher Chow) writes: >One thing which you might want to question is whether if you want to add an >68851 MMU to your Mac II. I'm not a hardware guru, but from what >understand, the 68851 chip adds wait state(s) to every memory reference. The wait states are already there. Two of 'em. The 851 doesn't add any more. As I understand it, it's a drop-in replacement for the fake MMU that's in there now. I don't think that interrupt handler is so simple. You also have to worry about getting the page map set up to begin with, and a million other things. I am sure Apple is working on it, and I hope they've hired some folks who know something about multi-user operating systems. They've said that the Multifinder we are seeing now is just the first generation in an evolution towards real multi-tasking. Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421 Internet: rubenstein@harvard.harvard.edu MCIMail: CSC
alan@pdn.UUCP (Alan Lovejoy) (10/04/87)
In article <2542@batcomputer.tn.cornell.edu> chow@tcgould.tn.cornell.edu (Christopher Chow) writes: /In article <2653@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: />Does anyone out there know what it would take to have demand paging virtual />memory on the Mac II? Could it be as simple as plugging in a 68851 and />writing an interrupt handler to take care of swapping the pages? /> / /One thing which you might want to question is whether if you want to add an /68851 MMU to your Mac II. I'm not a hardware guru, but from what /understand, the 68851 chip adds wait state(s) to every memory reference. /How's that for slowing down your machine. Note that Suns, etc., all use /their custom MMU chips to avoid the wait state problems with the Motorola /chip. / Not quite. The Mac II in its present form uses either the "HMMU" (a 68461) or the "PMMU" (a 68851), either of which introduces a wait state. Therefore, taking out your current 68461 and putting in a 68851 should have no effect on wait states. Also, the extra wait state is due more to the memory access protocol and architecture of the 68000, 68010 and 68020 than to the particular brand or model of MMU you use. Only by designing the MMU with a *large* external cache is it possible to virtually avoid wait states (or incurr them only on cache misses, that is). Someone should market a 68851 compatible MMU with a large on-chip cache (Hey! Motorola! Pay attention!). --alan@pdn
fnf@mcdsun.UUCP (Fred Fish) (10/06/87)
In article <2929@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes: >The wait states are already there. Two of 'em. The 851 doesn't add any more. >As I understand it, it's a drop-in replacement for the fake MMU that's in >there now. On the back of a recent EE Times was an ad from Hamilton-Avnet for something called an MC68020KIT, which included a 68851, 68020, and 68881 (all 16Mhz) for $399. I ordered one, snarfed out the 68851 (actually an XC68851) and popped it into my Mac-II. As far as I can tell, everything works exactly as before. So yes, it does look like it is a drop in replacement. I've since resold the remainder of the kit to someone who could use the 020 and 881, so my net cost for the PMMU was about $100. Now if I could just get A/UX... :-( -Fred -- # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA
kateley@apple.UUCP (Jim Kateley) (10/06/87)
In article <2542@batcomputer.tn.cornell.edu> chow@tcgould.tn.cornell.edu (Christopher Chow) writes: >In article <2653@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: >>Does anyone out there know what it would take to have demand paging virtual >>memory on the Mac II? Could it be as simple as plugging in a 68851 and ^^^^^ >One thing which you might want to question is whether if you want to add an >68851 MMU to your Mac II. I'm not a hardware guru, but from what >understand, the 68851 chip adds wait state(s) to every memory reference. ^^^^ As I understand it, there is currently a wait state for the HMMU anyway, so adding the 68851 will not add another. According the the Macintosh family hardware reference, there are 5 clock cycles in a RAM/ROM access. -- Jim Kateley Applelink: kateley1 UUCP: {sun, voder, nsc} apple!kateley CSNET: kateley@apple.COM Disclaimer: All the usual stuff, I speak for myself, etc... Remember: When you smile :-), the world smiles with you, When you frown :-(, the world thinks you are hung over...
keith@apple.UUCP (Keith Rollin) (10/06/87)
In article <2542@batcomputer.tn.cornell.edu> chow@tcgould.tn.cornell.edu (Christopher Chow) writes: >In article <2653@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: >>Does anyone out there know what it would take to have demand paging virtual >>memory on the Mac II? Could it be as simple as plugging in a 68851 and >>writing an interrupt handler to take care of swapping the pages? >> > >One thing which you might want to question is whether if you want to add an >68851 MMU to your Mac II. I'm not a hardware guru, but from what >understand, the 68851 chip adds wait state(s) to every memory reference. >How's that for slowing down your machine. Note that Suns, etc., all use >their custom MMU chips to avoid the wait state problems with the Motorola >chip. > >Christopher Chow I'm not a hardware guru either, so take this with a grain of whatever's handy. Document BR299 from Motorola ("MC68851: Technical Summary") says: "The address translation mechanism provides full logical-to-physical mapping in less than one clock cycle for a very high percentage of all bus cycles." The way it works is like this: 1) A request for some memory is made by the 68020. This is intercepted by the 68851 and compared against a 64-entry onchip translation cache. If a match is found, and their are no extenuating protection modes set, then the translated address is put on the line. (They also note a neat feature here. It says that you can also specify a 3-bit 'task alias' for each address. This is intended for use by multi-tasking operating systems that can optimize the caching of up to 8 tasks. Each task is assigned some unique 3-bit pattern which is used to identify addresses that it frequently uses. In effect, the 64-entry table can be evenly divvied up into 8 parts for 8 tasks.) 2) If the PMMU cannot find a match, then it must generate a translation on its own. It does this by first simultaneously aborting the logical bus cycle, signalling the 68020 to try again, and requesting mastership of the logical bus. It then performs the necessary translation lookup and passes it back to the 68020 when it is completed. This is an extremely simplified view of what is going on, and I may have horribly mangled it in trying to summarize. In addition, I have excluded all mention of RPTs (Root Pointer Tables) and the format of the translation tables. Feel free to make any corrections and/or additions where necessary. And remember the disclaimer below... -- Keith Rollin Sales Technical Support Apple Computer Stupid Disclaimer: I read this board for fun, not profit Stupid Quote: If god had meant man to fly, he would have given him plane tickets
kateley@apple.UUCP (Jim Kateley) (10/07/87)
In article <8710040406.AA20847@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Right. One Wait-State as Peter tells me. That and a 16 bit data > ^^^^^^^^^^^ > -Matt The MacII has a 32 bit data path, and adding the PMMU does not change that... -- Jim Kateley Applelink: kateley1 UUCP: {sun, voder, nsc} apple!kateley CSNET: kateley@apple.COM Disclaimer: All the usual stuff, I speak for myself, etc... Remember: When you smile :-), the world smiles with you, When you frown :-(, the world thinks you are hung over...
cm450s02@uhccux.UUCP (jeff t. segawa) (10/09/87)
Could you find out which issue of EE Times the Hamilton Avnet ad appeared in? Are these prices only for developers, or the general public? Oh yes, an address for H-A would also be appreciated. I don't really NEED the memory management chip right now, but at those prices, what the heck. Never can tell...
gustav@swanee.OZ (Gustav) (10/09/87)
in article <4007@sdcsvax.UCSD.EDU>, jww@sdcsvax.UCSD.EDU (Joel West) says: > It would take plugging in a 68851 and waiting about 18 months > for Apple to develop a virtual memory capability for the Mac OS. :-) I wish they would do this (i.e. develop a virtual memory for the Mac OS), otherwise Mac is going to be overtaken by OS/2 machines early next year. Probably, a good enough reason for concern.
north@apple.UUCP (Donald N. North) (10/11/87)
In article <1478@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >/One thing which you might want to question is whether if you want to add an >/68851 MMU to your Mac II. I'm not a hardware guru, but from what >/understand, the 68851 chip adds wait state(s) to every memory reference. >/How's that for slowing down your machine. Note that Suns, etc., all use >/their custom MMU chips to avoid the wait state problems with the Motorola >/chip. >Not quite. The Mac II in its present form uses either the "HMMU" (a 68461) >or the "PMMU" (a 68851), either of which introduces a wait state. >Therefore, taking out your current 68461 and putting in a 68851 should >have no effect on wait states. For the record, the HMMU (an Apple custom, not a 68461) adds ONE wait state to each basic memory access; when it is replaced with a PMMU (68851) TWO wait states are added to each memory access. Thus it only pays to use the 68851 when you really need it (ie, for A/UX). It not only costs you $$ but degrades performance too. -- Don North Apple Computer, Inc. Advanced Technology Group UUCP: {voder,nsc,dual,sun,ucbvax!mtxinu}!apple!north CSNET: north@apple.CSNET {{ Facts are facts, but any opinions expressed are my own, and do not }} {{ represent any viewpoint, official or otherwise, of Apple Computer, Inc.}}
stew@endor.harvard.edu (Stew Rubenstein) (10/13/87)
In article <6453@apple.UUCP> north@apple.UUCP (Donald N. North) writes: >For the record, the HMMU (an Apple custom, not a 68461) adds ONE wait state >to each basic memory access; when it is replaced with a PMMU (68851) TWO wait >states are added to each memory access. Thus it only pays to use the 68851 >when you really need it (ie, for A/UX). It not only costs you $$ but degrades >performance too. > >Don North >Apple Computer, Inc. >Advanced Technology Group The March APDA draft of "Macintosh Family Hardware Reference" states, on page 149, that "With either the PMMU or HMMU, one additional wait state is imposed to do address translation. Remember that there is one wait state for the ROM and RAM accesses because of the basic hardware timing (4 clock cycles for memory access), thereby making ROM and RAM accesses take a total of 5 clock cycles." Is it wrong? Wouldn't be the first time... Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421 Internet: rubenstein@harvard.harvard.edu MCIMail: CSC
alan@pdn.UUCP (Alan Lovejoy) (10/13/87)
In article <6453@apple.UUCP> north@apple.UUCP (Donald N. North) writes: >For the record, the HMMU (an Apple custom, not a 68461) adds ONE wait state >to each basic memory access; when it is replaced with a PMMU (68851) TWO wait >states are added to each memory access. Thus it only pays to use the 68851 >when you really need it (ie, for A/UX). It not only costs you $$ but degrades >performance too. >-- > >Don North >Apple Computer, Inc. >Advanced Technology Group It appears my sources were wrong (I've never looked inside a Mac II myself). One of my sources also maintains that two wait-states are necessary for mother-board memory accesses so that NuBus devices can access it. Is there any truth to this (now I doubt everything!)? --alan@pdn
shap@sfsup.UUCP (J.S.Shapiro) (10/20/87)
In article <2929@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes: > > The wait states are already there. Two of 'em. The 851 doesn't add any more. > As I understand it, it's a drop-in replacement for the fake MMU that's in > there now. > > I don't think that interrupt handler is so simple. A somewhat more interesting question is whether or not if you wanted to experiment with this chip there is sufficient code out there in the current System version to at least initialize the page maps right for *normal* operation (i.e. no paging, just act like the existing fake). As to the interrupt driver, I see no reason whatsoever to believe that the interrupt driver is terribly hard. Paging algorithms are well understood, and a number of adequate ones are publicly available (see, for example, Doug Comer's book on XINU). Putting together a buffer cache and setting up a paging area is straightforward. Getting paging to work correclty directly from the application binary file, on the other hand, might require some very delicate manipulation and the use of some bit to mark the binaries busy (consider, for example, the problem of someone compacting your disk while you are paging from one of the applications, which is possible under multifinder. This raises an interesting question. If I attempt some clever disk compaction scheme while a file is open, what happens? Jon Shapiro AT&T