pramod@uoregon.uoregon.edu (Pramod Daya) (02/19/89)
Does anyone know of dealers who have good prices on the 68851 PMMU ? Tnx. pramod@drizzle.cs.uoregon.edu
fons@uxh.cso.uiuc.edu (02/20/89)
I would like to know pricing on the PMMU also (sources, prices etc.)
Thanks
Paul Fons
University of Illinois
Coordinated Science Laboratory
1101 W. Springfield Av.
Urbana, Illinois 61801 U.S.A.
email: Fons@uiucvmd.bitnet or...
Fons@uxh.cso.uiuc.edumalczews@castor.usc.edu (Frank Malczewski) (02/23/89)
In article <3885@uoregon.uoregon.edu> pramod@drizzle.UUCP (Pramod Daya) writes: >Does anyone know of dealers who have good prices on the 68851 PMMU ? > >Tnx. >pramod@drizzle.cs.uoregon.edu I believe that developer prices were running somewhere around $350, but not being a developer (under Apple's definition of the word), I would also like to know a cheap source for the chip. -- Frank Malczewski malczews@castor.usc.edu
jchau@castor.usc.edu (Jeffrey Chau) (08/21/89)
HI everyone I'm very new here and though I had my Mac for about one year, this is the first time I subscribe to this newsgroup. Anyway, I got mu Mac II with 5 Meg of rams and 40 Meg HD last september and soon after collecting the machine, Apple introduced the Mac IIx and subsequently the IIcx. Not lone after that, I heard rumors that Apple will be terminating the Mac II and I discovered my machine would soon join my many other apples (mainly apple ][+, //e and ///) as 'orphaned' computers. I started to search for an upgrade path for my Mac II but to my dismay, the cost is fantastic.... just like buying a new machine. With such financial constraints, I can only hope to add a PMMU on my Mac as well as the high density drive. I like to know where I could get a PMMU at a reasonable price. Also, while reading other postings, I kept coming across the 32 bit quickdraw. I have a 8 bit graphic card with the apple RGB color monitor with my system. I was hoping that someone out there would be able to tell me the functionality of the 32 bit quickdraw and the ways and means to get it. Any assistance will be greatly appreciated. Thanks a million Jeffrey Chau jeffchau@skat.usc.edu jchau@girtab.usc.edu
garths%glass@Sun.COM (Garth Snyder) (08/21/89)
jchau@castor.usc.edu (Jeffrey Chau) writes: > I got mu Mac II with 5 Meg of rams and 40 Meg HD last september and > soon after collecting the machine, Apple introduced the Mac IIx and > subsequently the IIcx. Not lone after that, I heard rumors that Apple > will be terminating the Mac II and I discovered my machine would soon > join my many other apples as 'orphaned' computers. I started to > search for an upgrade path for my Mac II but to my dismay, the cost is > fantastic.... just like buying a new machine. There's no need to be so concerned. Except for the high-density floppy drive, there's really little difference between the II and the IIx. The 68030 has no significant advantage over the 68020/PMMU combination except the ability to run the memory with one wait state instead of two. This only buys you about a 15% increase in speed. Put a $250 Sprint II cache board in your II, and it will run faster than a IIx. This info comes from a column in this week's MacWeek written by none other than David Ramsey, the man fired by Apple for having a slightly-too-big mouth on CompuServe. As for the PMMU, there is a Usenet group purchase underway at this very minute. Send mail to Tad, the amazing coordinator, at mblakele@jarthur.claremont.edu for more info. -------------------- Garth Snyder Sun Microsystems, mail drop 14-40 ARPA: garths@eng.sun.com 2550 Garcia Avenue ALSO: garth@boulder.colorado.edu Mountain View, CA 94043 --------------------
sobiloff@thor.acc.stolaf.edu (Blake Sobiloff) (08/22/89)
In article <4804@merlin.usc.edu> jchau@girtab.usc.edu () writes: >Anyway, I got mu Mac II with 5 Meg of rams and 40 Meg HD last september >and soon after collecting the machine, Apple introduced the Mac IIx and >subsequently the IIcx. Not lone after that, I heard rumors that Apple >will be terminating the Mac II and I discovered my machine would soon >join my many other apples (mainly apple ][+, //e and ///) as 'orphaned' >computers. Yeah, this sounds like a typical, whimpy, obolete machine to me! God, with *only* 5 meg of RAM, how do you *run* anything? I guess my Plus and I must be ancient history... :-) Blake -- ******************************************************** * Blake "Hey, where's *MY* fancy .signature?" Sobiloff * * sobiloff@thor.acc.stolaf.edu * ********************************************************
acsh@crcc.uh.edu (08/24/89)
RE: PMMU (& upgrading a II) I also bought a Mac II in 1988 just before the IIx announcement. Because all of my department has 800K drives (and I've heard a lot of gripes about the FDHD) I'm not interested in upgrading the drive, but I am interested in a speed improvement. I spoke with Dove and they have a $1599 68030 chip running at 32 Mhz. With their 30% academic discount it would be about $1120. Since the Apple PMMU sells here for $699 (and wouldn't be compatible with the '030 anyway) I've decided to shoot for the new chip rather than the PMMU. The name of the 30/32 accelerator is the Dove MaraThon 030 Accelerator, BTW. Has anybody had any experience with this product? Also, in the last MacWeek, the upgrade recommended was the PMMU and MacSprint (I think), the board that gives you a 32K RAM cache and costs about $250. The reviewer said that these two parts will make the II run faster than the IIx. Jim
cl1x+@andrew.cmu.edu (C. Kenny Lin) (08/24/89)
Would you (or anyone else) know what it was that David Ramsey said on C-Serve that got him fired by Apple? Inquiring minds want to know. Thanks. ---Ken
hammen@csd4.csd.uwm.edu (Robert J. Hammen) (08/25/89)
In article <gYwzjf600XoI02wEVv@andrew.cmu.edu> cl1x+@andrew.cmu.edu (C. Kenny Lin) writes: >Would you (or anyone else) know what it was that David Ramsey said on >C-Serve that got him fired by Apple? Compu$erve, Ramsey, and Apple aren't talking. However, "industry speculation" is that he made some references to System 8.0 (total OS rewrite, true multitasking?). It was also noted that apparently Sculley made some vague references to these points in some speech, but he hasn't been fired yet :-) This is only what I've heard somewhere, and may be only the result of a LOT of gossip. Take it with a grain of salt. /////////////////////////////////////////////////////////////////////////// / Robert Hammen | Service Bureau Manager and Macintosh Consultant / / Bulfin Printers | 1887 N. Water | Milwaukee WI 53202 | (414) 271-1887 / / hammen@csd4.csd.uwm.edu | uunet!uwmcsd4!hammen | Delphi: HAMMEN / / CI$: 70701,2104 | GEnie: R.Hammen | MacNet: HAMMEN | BIX: rhammen / ///////////////////////////////////////////////////////////////////////////
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (08/26/89)
In article <4804@merlin.usc.edu> jchau@girtab.usc.edu () writes: >HI everyone Hi yourself, and welcome! > I started to search for an upgrade path for my Mac II but >to my dismay, the cost is fantastic.... just like buying a new machine. > >With such financial constraints, I can only hope to add a PMMU on my Mac >as well as the high density drive. I like to know where I could get >a PMMU at a reasonable price. Also, while reading other postings, >I kept coming across the 32 bit quickdraw. I have a 8 bit graphic >card with the apple RGB color monitor with my system. I was hoping >that someone out there would be able to tell me the functionality of >the 32 bit quickdraw and the ways and means to get it. Well, the advantages of the IIx over the II are: 1) 68030 instead of 68020 - built in PMMU. This is solved by adding a PMMU to the II. Since it is built in into the CPU in the IIx, there is one less wait state and it is therefore marginally faster (see performance, below). 2) Slightly improved performance - the IIx is about 15% faster than the II, partially because of the wait state mentioned before, and partially because it has separate data and instruction caches. This performance gap is easily closed with Orchid's MacSprint II cache card for the II (~$299 list). 3) FDHD capability - the IIx comes with an improved disk controller chip (the SIWM) which allows it to control a high density 3.5 inch drive, giving you twice as much storage on a floppy, as well as the capability to read and write to and from IBM 3.5 disks. The FDHD upgrade should do the trick. I am not 100% sure on this next part, but it is my understanding that the FDHD upgrade also allows the II to use 4MB SIMMs, since the SIMM slots in the II are slightly nonstandard. The IIx, cx, and SE30's slots are fully compatible with 4MB SIMMs. 4) ROM SIMMs - Nice for system software upgrades, but not a vital consideration. No way to get this short of getting the expensive upgrade. About getting a reasonably priced PMMU: contact Ted Blakeley (mblakele@jarthur.claremont.edu). He's collecting names to make a quantity net.order for PMMUs from Motorola. I think the price he was quoted was $200 for 1-4 chips, so with the amount of people involved the price could go down significantly (tho' $200 ain't bad at all). Re: 32-bit quickdraw. It allows you to manipulate 32-bit color images on the Mac, giving you photographic quality images. 32BQD, however, just supplies the system software to work with these images - to take advantage of it, the software you use must specifically use 32BQD (and there ain't much out there yet). The nice part, I think, is that it also gives you the ability to halftone color printouts and stuff like that. -Ivan Internet: captkidd@athena.mit.edu
steve@violet.berkeley.edu (Steve Goldfield) (08/26/89)
In article <13820@bloom-beacon.MIT.EDU> captkidd@athena.mit.edu (Ivan Cavero Belaunde) writes:
#>About getting a reasonably priced PMMU: contact Ted Blakeley
#>(mblakele@jarthur.claremont.edu). He's collecting names to make a quantity
#>net.order for PMMUs from Motorola. I think the price he was quoted was $200
#>for 1-4 chips, so with the amount of people involved the price could go
#>down significantly (tho' $200 ain't bad at all).
I don't understand why so many people with edu addresses are
talking about buying PMMUs when Motorola will send them to
you for free. This information has been posted in this news
group already, but if anyone wishes it reposted, let me know.
If you are a student or faculty member, Motorola will send
you a PMMU and a 68882 coprocessor if you ask for it absolutely
free, no charge! It's difficult to find a cheaper upgrade path
than that.
Steve Goldfieldkingman@tci.UUCP (Matt) (08/29/89)
acsh@crcc.uh.edu writes: >RE: PMMU (& upgrading a II) ....... >I spoke with Dove and they have a $1599 68030 chip running at 32 Mhz. With >their 30% academic discount it would be about $1120. Since the Apple PMMU >sells here for $699 (and wouldn't be compatible with the '030 anyway) I've >decided to shoot for the new chip rather than the PMMU. >The name of the 30/32 accelerator is the Dove MaraThon 030 Accelerator, >BTW. >Has anybody had any experience with this product? If you check MacConnection, I believe their latest price is $969. It's simple to install, just pull out the 020 and push the accelerator into the socket. The whole thing is about 2"x4". Then there's an INIT you put in your system folder and that's it. You're screaming. For the money, it's definitely worth it. The only incompatability I've seen is the Moire screen saver when run in color mode (ok in B&W), everything else is great. Dove has a good reputation, and their products are first rate (I have a Fastnet III Ethernet card that I've had no problems with). I have no affiliation with the above mentioned products or companies, just speaking from personal experience..... /Matt
ghh@vertigo.princeton.edu (Gilbert Harman) (08/30/89)
#>The name of the 30/32 accelerator is the Dove MaraThon 030 Accelerator,
#>BTW.
#
#>Has anybody had any experience with this product?
#
#If you check MacConnection, I believe their latest price is $969. It's simple
#to install, just pull out the 020 and push the accelerator into the socket.
#The whole thing is about 2"x4". Then there's an INIT you put in your system
#folder and that's it. You're screaming. For the money, it's definitely
#worth it.
Would this work in an SE with the Hypercharger 020
accelerator. Could you just take the 020 out of that and
put in the Dove 68030 chip?
gil
--
Gilbert Harman
Princeton University Cognitive Science Laboratory
221 Nassau Street, Princeton, NJ 08542
ghh@princeton.edu
HARMAN@PUCC.BITNETaff@lear.cs.duke.edu (Amr F. Fahmy) (09/02/89)
I got the 68851 and the 68882 for my mac II. Can somebody please tell me how to install and test them. Thanks. Amr F. Fahmy aff@duke.edu
steve@violet.berkeley.edu (Steve Goldfield) (09/02/89)
In article <15454@duke.cs.duke.edu> aff@lear.cs.duke.edu (Amr F. Fahmy) writes:
#>I got the 68851 and the 68882 for my mac II. Can somebody please tell me
#>how to install and test them. Thanks.
#>
#>Amr F. Fahmy
#>aff@duke.edu
Somebody sent me a file of instructions I can't find. But
here's what I remember. You will have to disassemble your
Mac II by taking off the cover and removing the panel with
the two disk drives (assuming you have a hard disk). Just
a matter of removing the screws and unplugging a few cables.
If you haven't done so before, note that the cables have a
stripe on one end. Make a rough diagram of where the stripes
are to make sure you reconnect them properly. At this point,
you need some kind of grounding cable. What I did was to get
a couple of feet of copper wire and hook one end to the chassis
and wrap the other around the wrist with which I picked up the
chip. It is important that there not be a voltage difference
between the chip and the Mac II if you don't want to destroy
the chip. [[Note that you turned the Mac II off and even
unplugged it to be doubly safe before doing any of the above.]]
Now you can carefully remove your 68881 and the cap over the
68851. Again note that one corner of the chip has a metal V
and that the board has a corresponding mark. The new chips
should be oriented in the same way. It takes a fair amount of
pressure to remove and insert these chips. I used a thin
screwdriver to pry around the edges of the 68881 and the
plastic cap. Be careful not to put too much pressure on
the printed-circuit board. The person who sent my instructions
recommended placing something flat under the board, but I
managed to get my chips in and out by using only moderate
pressure.
Once the chips are down (sorry about the pun), reassemble
your Mac II. Start up your Mac II. One view holds that if
it still works, you inserted the chips correctly.
If you download Macenvy from sumex, it will tell you what
hardware and software are in your system. It will note the
presence of the PMMU. The current version will say you have
a 68881 rather than a 68882 because it only checks to see
that the chip is there. There is also a patch for Excel,
which also says it sees a 68881. I have the patch, but I
don't know enough to know how to install it or to tell
anyone else how. (If anyone can tell me what software to
use to do so, I'd appreciate the information. In other words,
in CP/M, I'd use ddt. What's the Mac equivalent?)
Frankly, I haven't found much software which takes advantage of
the 68882. And the PMMU won't do you any good unless you have
the available software which facilitates virtual memory. But
at least you'll have the satisfaction of knowing you can use
System 7.0 fully as soon as it arrives, assuming it lives up
to preliminary expectations.
Excel patch follows: (I assume that Ken Hancock won't object
to my posting the mail he kindly sent me)
To make Excel version 1.5 recognize the 68882 Math Coprocessor
(which comes on the SE/30, Mac IIx, and Mac IIcx) instead of the
68881 which comes on the Mac II), make the following modifications:
search for: 6620 4A42 675C
replace with: 6D20 4A42 675C
The logon will still say that the 68881 coprocessor is installed,
but it will use the 68882 instead.
--
Ken Hancock '90 | E-mail: (BITNET/UUCP/INTERNET)
Computer Resource Center Consultant | isle@eleazar.dartmouth.edu
------------------------------------+---------------------------------------d6maca@dtek.chalmers.se. (Martin Carlberg) (09/11/89)
HELP!!!!! Does anyone have the e-mail adress to this Ted B..... He who wrote to Motorola for a good price on an PMMU. I'm one of the buyers and I've had a diskcrash so I lost all of my files forever. They don't know the word backup here :-( This crash was for about 3 weeks ago. The guys was not able to fix it until now. All my mail has bounced for these weeks. I'm back to Zero! - Martin Carlberg - Chalmers University of Technology, Gothenburg, Sweden
bklaas@cmdfs2.intel.com (Brian Klaas~) (09/11/89)
In article <783@mathrt0.math.chalmers.se> d6maca@dtek.chalmers.se (Martin Carlberg) writes: > > HELP!!!!! > > Does anyone have the e-mail adress to this Ted B..... He who wrote to >Motorola for a good price on an PMMU. I'm one of the buyers and I've had >a diskcrash so I lost all of my files forever. They don't know the word >backup here :-( Sorry about the crash. Here is his e-mail address. Tad Blakeley --> mblakele@jarthur.claremont.edu -- ** Brian Klaas, Design Engineer *** DISCLAIMER: All opinions ** ** Intel Corporation *** stated here are strictly my own. ** ** InterNET -> bklaas%cmdfs2.intel.com@relay.cs.NET UUCP: ** ** {hplabs,decwrl,oliveb,pur-ee,qantel,amdcad}!intelca!mipos3!sedona!bklaas **
jstewart@rodan.acs.syr.edu (Ace Stewart [Jonathan III]) (09/24/89)
With all the talk about PMMU chips from Motorola, I ask this. I own an
SE with 1Meg RAM. Its the 68000 and I'm kinda wonderin what kind of chip
(if any) I should ask for. I'm not sure I understand the concept of
PMMU to begin with and ask everyone's advice as well as tap into your
wisdom...
Thanks in advance...Ace
--
| Ace Stewart (Jonathan III) |A /\ |
| Affiliation: Eastman Kodak Company. Rochester New York | _/ \_ |
| Internet/ARPA: jstewart@rodan.acs.syr.edu | \_ _/ |
| Bitnet: jstewart@sunrise.bitnet | /\ A|nagle@well.UUCP (John Nagle) (09/26/89)
In article <822@rodan.acs.syr.edu> jstewart@rodan.acs.syr.edu (Ace Stewart [Jonathan III]) writes: >With all the talk about PMMU chips from Motorola, I ask this. I own an >SE with 1Meg RAM. Its the 68000 and I'm kinda wonderin what kind of chip >(if any) I should ask for. I'm not sure I understand the concept of >PMMU to begin with and ask everyone's advice as well as tap into your >wisdom... A memory management unit is a device which sits between the CPU and the memory. Its purpose in life is to make it possible to implement operating systems where each process is safely confined to its own address space and can't clobber other processes running at the same time. Some memory management units also provide part of the machinery needed for "virtual memory". With this, a program can address data that isn't really in memory, the operating system gets an interrupt when this happens, and a smart operating system can move the data into memory (usually moving something else out to disk to get the space), and after all this happens, the program gets control back as if nothing had happened, but now the needed data is in memory. The MC68000 and MC68010 have no memory management units. The MC68010 can be used with an external memory management unit, and the Sun 2 does this. The MC68000 doesn't have some features needed for virtual memory even with an external MMU, so it can't be upgraded. (The problem with the 68000 is that it is unable to recover properly after a page fault if the instruction causing the fault had automatic incrementation.) The MC68020 does not have a memory management unit either, but like the 68010, can be provided with an external one. This is the "PMMU" (Paged Memory Management Unit) used in the Mac II. It's not standard on a Mac II, but is an expensive extra-cost option. On standard Mac IIs, the MMU socket is filled with a chip which is more of a dummy plug than a component; it just passes the addresses through unchanged. The MC68030 has a built-in MMU comparable to (but not compatible with) the PMMU. So all '030-based machines are in theory capable of running a virtual memory operating system with protected memory. Unfortunately, none of this excellent memory management hardware does you any good unless you run A/UX. The regular Mac operating system just turns any memory management unit off and runs in "real mode". Even release 7, much to the disappointment of people who don't like system crashes, doesn't use the MMU. On a machine with memory management and a solid operating system, an application can't crash the system no matter what it does. Essentially all workstation-class machines (Suns, Apollos, HP workstations, and all the UNIX boxes) work that way. So does the Mac under A/UX, although there's the problem under A/UX that if the application crashes while in control of the screen, it's hard to get control of the machine back, even though the operating system is running quite well inside the box. (If you have an extra terminal or a network, you can talk to the machine that way and kill the offending application. This is Apple's recommendation.) "Release 7 - Bomb Boxes Forever!" John Nagle
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (09/27/89)
In article <13822@well.UUCP> nagle@well.UUCP (John Nagle) writes: [discussion of 680x0 and PMMUs deleted] > The MC68020 does not have a memory management unit either, but >like the 68010, can be provided with an external one. This is the >"PMMU" (Paged Memory Management Unit) used in the Mac II. It's not >standard on a Mac II, but is an expensive extra-cost option. On >standard Mac IIs, the MMU socket is filled with a chip which is more >of a dummy plug than a component; it just passes the addresses through >unchanged. The PMMU costs about $350 dollars. Whether you consider this expensive in view of what it will get is up to you. > The MC68030 has a built-in MMU comparable to (but not >compatible with) the PMMU. So all '030-based machines are in theory >capable of running a virtual memory operating system with protected >memory. The 030 MMU implements a subset of the 68851 PMMU (the one you can use with the 68020). So software written to take advantage of the 030's MMU should work ok on a 020/851 combo. > Unfortunately, none of this excellent memory management hardware >does you any good unless you run A/UX. The regular Mac operating system >just turns any memory management unit off and runs in "real mode". Even >release 7, much to the disappointment of people who don't like system >crashes, doesn't use the MMU. On a machine with memory management and >a solid operating system, an application can't crash the system no matter >what it does. Essentially all workstation-class machines (Suns, Apollos, [etc] Sorry dude, you almost got it but not quite. System 7 implements virtual memory which REQUIRES a PMMU (either the 030's own or the 851 for the 020). What System 7 does not implement is protected memory where the MMU is used to prevent code in one address space from writing directly to another address space. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
chuq@Apple.COM (Chuq Von Rospach) (09/27/89)
>> Unfortunately, none of this excellent memory management hardware >>does you any good unless you run A/UX. The regular Mac operating system >>just turns any memory management unit off and runs in "real mode". Unless you buy the Virtual INIT. >>Even >>release 7, much to the disappointment of people who don't like system >>crashes, doesn't use the MMU. Not true. System 7 will use the MMU to implement virtual memory. As has been mentioned about 4,000,000 times on c.s.m in the last few months. >>On a machine with memory management and >>a solid operating system, an application can't crash the system no matter >>what it does. Essentially all workstation-class machines (Suns, Apollos, Um, that's a nice theoretical ideal, but I spent enough time at Sun crashing machines to know that applications *can* crash the system, even when they're not supposed to be able to. >Sorry dude, you almost got it but not quite. System 7 implements virtual >memory which REQUIRES a PMMU (either the 030's own or the 851 for the 020). Just to make sure it's clear. System 7 does not require a PMMU. To use virtual memory with System 7 does. (there's enough confusion on that point that it needs to be reiterated) >What System 7 does not implement is protected memory where the MMU is used >to prevent code in one address space from writing directly to another >address space. As I said above, even *with* protected memory applications can do all sorts of nasty things. They aren't supposed to be able to, but sometimes they do anyway. (those are called bugs, of course....) -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking. I am not Appl Segmentation Fault. Core dumped.
barmar@kulla (Barry Margolin) (09/27/89)
In article <35041@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >>>On a machine with memory management and >>>a solid operating system, an application can't crash the system no matter >>>what it does. Essentially all workstation-class machines (Suns, Apollos, >Um, that's a nice theoretical ideal, but I spent enough time at Sun crashing >machines to know that applications *can* crash the system, even when they're >not supposed to be able to. The operative words were "a solid operating system". Unless there are CPU or MMU design errors, memory management and protected mode can generally protect a system from crashing due to user code. Most software crashes on multiuser OSes are due to bugs in the kernel; since the kernel often runs in unprotected mode, such bugs CAN crash the system. Of course, once you discover such kernel bugs, it is often easy to write applications that invoke them (I had an Ultrix 2.2 program that accessed tape drives, and running it (without recompiling) on Ultrix 2.4 (the pre-release designation for 3.0) caused the system to crash, even though the new system was supposed to be binary-compatible with the old one). Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
md32+@andrew.cmu.edu (Michael Joseph Darweesh) (09/27/89)
Does anyone out there know where I can get a well priced PMMU for my Mac
II?
I would like to have virtual memory.....
Thanks,
---
The Weesh
md32@andrew.cmu.edu
md32@andrew.bitnet
...!{harvard,ucbvax}!andrew.cmu.edu!md32kehr@felix.UUCP (Shirley Kehr) (09/27/89)
In article <822@rodan.acs.syr.edu> jstewart@rodan.acs.syr.edu (Ace Stewart [Jonathan III]) writes:
<With all the talk about PMMU chips from Motorola, I ask this. I own an
<SE with 1Meg RAM. Its the 68000 and I'm kinda wonderin what kind of chip
<(if any) I should ask for. I'm not sure I understand the concept of
<PMMU to begin with and ask everyone's advice as well as tap into your
<wisdom...
I'm sure plenty of people will tell you that the 68000 doesn't support it
(so I won't :-)
Last night's MacWeek carried an ad (in the back) for 68851 for $200. I
thought that was the price the group purchase was hoping to get. Sort of
makes Virtual's $495 look sick doesn't it?
Shirley Kehrech@cbnewsk.ATT.COM (ned.horvath) (09/28/89)
This is getting silly. What follows is Virtual Memory 101; for a GOOD treatment, go get a book -- NOT from a major hardware vendor! -- on operating systems, or dig out the ancient article on Virtual Memory, by P.J.Denning, in Computing Surveys, early '70s. Read it, understand it, THEN post here. An MMU is a "Memory Mapping Unit," and it does precisely that: addresses generated by the processor go to the MMU, which may: 1 translate them to physical addresses to be passed to the physical RAM; 2 raise an exception because the address is unmapped; or 3 raise a protection violation exception; or 4 pass the address through to physical RAM unchanged. The HMMU (third generation Fake MMU -- get it?) which is standard in the Mac II just does 4. It is basically a NO-OP with the same pin-outs as a 68851. The on-chip MMU in the 68030 is capable of all four. The 68851, aka PMMU, replaces the HMMU in a vanilla Mac II. The 68851 supplies a proper superset of the 68030's MMU capabilities, so any OS designer with the sense Ghod gave a door will program to the '030 subset, which will catch the '020 + '851 crowd for free. Now. An MMU is an ENABLING technology. It maps addresses and/or raises non-present memory exceptions. Several wonderful and INDEPENDENT things can be done with that capability: A. Use a different namespace -> physical space map for each process. This provides the process with the illusion of a virtual machine. It also provides some protection: if MacDraw's map doesn't include RAM assigned to the Finder, then stray pointers in MacDraw can't trash the Finder's RAM. Is it perfect? Of course not. Is it better? You damn betcha. Is it the programmer's friend? Well, when I'm debugging a program, it's nice to know that the debugger isn't being creamed by the debuggee -- more about this presently. B. Use a larger namespace than you have physical space, and plan to fetch stuff you need when you need it. This uses the exceptions raised for non-present memory: the exception handler fetches the desired bit of stuff, patches up the map to indicate its presence, and restarts the instruction (which presumably succeeds). This is not unlike what the segment loader does today, except that the segment loader just colludes with your favorite linker to get the job done, without any special hardware assist. C. Manage your RAM more effectively. There's no longer any reason why the System Heap (or any other heap) can't grow/shrink on demand, since it only needs to be LOGICALLY contiguous, not physically contiguous. D. Permit selective access -- e.g. read-only, execute-only -- to various objects. With a bit more work, provide "read-mostly" access -- e.g., you might mark the low-memory globals read-only, but permit (say) BootDrive to be set by the program by INTERPRETING the instruction in the OS. Now, with all these options, different people will opt to implement different uses. No combination is "true virtual memory," and anyone who attacks system 7 on that basis probably has an axe to grind. Option B is what Virtual provides on a global basis, and that is all that Apple have chosen to do for system 7. No protection, no dynamic system heap or user heaps. Those would be very nice to have, and I'm rather surprised to hear Chuq defending the decision to leave them out. But options A and C would require that Finder, Multifinder, and various debuggers (including, but not limited to, SADE) be modified to deal correctly with the new regime. Those problems aren't insurmountable, particularly for the sort of phreaks who write system software (see ptrace(2) in your favorite unix manual). But the sum total is a lot of interdependent changes, and a delay in releasing system 7. I think of system 7 as "halfway to Unix," and I fully expect that system 8 will finish the job. Now, before you netMacMorons(tm) flame me for that expectation, I'll ask you to recognize the basic facts: Unix is pretty on the inside, ugly on the outside. Macintosh has it the other way 'round. When the MacOS becomes Unix on the inside while remaining Mac on the outside -- like what Jobs is trying to do with NeXT, maybe? -- that will be a *GOOD THING*. Getting from here to there is a lot of work, for third parties as well as Apple. =Ned Horvath=
mclow@telesoft.com (Marshall Clow @telesoft) (09/29/89)
In article <wZ88mN200Wg=A8tEor@andrew.cmu.edu>, md32+@andrew.cmu.edu (Michael Joseph Darweesh) writes: > Does anyone out there know where I can get a well priced PMMU for my Mac > II? > > I would like to have virtual memory..... I called Hamilton-Avnet ( A chip distributor that has an office here in San Diego ), and said I wanted 1 (one) 16Mz Motorola PMMU, chip # 68851, and they sent me one for $202. BTW, these guys have no idea about the mac, they just sell chips. They also were not really happy to sell one, but what the hell, a sale is a sale. Marshall mclow@telesoft.com
daveh@cbmvax.UUCP (Dave Haynie) (09/29/89)
in article <13822@well.UUCP>, nagle@well.UUCP (John Nagle) says: > In article <822@rodan.acs.syr.edu> jstewart@rodan.acs.syr.edu (Ace Stewart [Jonathan III]) writes: > The MC68030 has a built-in MMU comparable to (but not > compatible with) the PMMU. So all '030-based machines are in theory > capable of running a virtual memory operating system with protected > memory. Actually, the 68030 Internal PMMU is very similar to the external 68851 PMMU that can be used with the 68020 in machines like the Mac II. There are a few additional addressing modes for some instructions in the '851, there's no support for CALLM/RTM in the '030's MMU (or the '030 for that matter), and the '030 adds two "transparent translation" registers, which support simple mapping of I/O regions in a virtual system. The 68851 also has a larger Address Translation Cache (64 vs. 22 entries). So, while there are slight differences, it's quite simple to write code that works on both MMUs just fine. If you're looking for a major change in MMU architecture, the 68040 will be along someday soon... > John Nagle -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough