I've replaced several 68LC040's with a full RC040 on Quadra 605s with no
problem. You can buy a dedicated CPU extractor but I've found that a
*careful* removal with a jewelers screwdriver and/or plastic tweaker works
just as well. You really should have a static strap as well.
On Sun, Nov 1, 2009 at 6:23 PM, Gorka L Martinez Mezo <g...@gmx.net> wrote:
--- On Sun, 11/1/09, Gorka L Martinez Mezo <g...@gmx.net> wrote:
> I have a Performa 631 with the standard 68LC40 processor > (no heatsink). The > CPU is socketed but I have never tried to extract it.
> Could the 68LC40 be replaced straight away with a full > 68040 as fitted to > the Quadra 630? Do I need any special tools to remove the > original CPU?
Yes, you can replace the CPU with the full 040.
The ideal method of removing the CPU is with a puller. It's a two part tool with an outer "U" shaped piece with the ends covered to protect the board and an inner, spring steel "U" with the ends bent in to catch two edges of the chip. A screw is used to pull up on the inner part to pull the chip.
Those might not be easy to find these days since PGA style chips and sockets aren't very common.
I never used one back in the days before ZIF sockets. I just used a small, flat blade screwdriver and carefully pried up a little at a time on each edge until the chip was out.
DayStar sent a puller with any of their CPU upgrades and adapters that required pulling chips. (Except for the IIcx, you had to verify the CPU was socketed before they'd send the puller - after they had some people destroy their boards trying to pull soldered CPUs.)
If you bend a pin, here's the perfect tool for straightening them. Find a syringe needle that will just slip over the pin and grind the point off so its straight. Use a sharp and pointy knife to deburr the inside of the needle after grinding it. A metal file should work, just slower than a Dremel or bench grinder.
The needle lets you get to any pin without touching the ones around it. Look sideways across the chip from all directions, the slightest bend in a pin will show easily.
You can straighten pins with a credit card or three, whatever fits in the
spaces between the pins, then go at 90 degrees to the bent pin. After
getting all 4 sides, the pin should be straight.
On Mon, Nov 2, 2009 at 4:07 AM, Gregg Eshelman <g_ala...@yahoo.com> wrote:
> --- On Sun, 11/1/09, Gorka L Martinez Mezo <g...@gmx.net> wrote:
> > I have a Performa 631 with the standard 68LC40 processor
> > (no heatsink). The
> > CPU is socketed but I have never tried to extract it.
> > Could the 68LC40 be replaced straight away with a full
> > 68040 as fitted to
> > the Quadra 630? Do I need any special tools to remove the
> > original CPU?
> Yes, you can replace the CPU with the full 040.
> The ideal method of removing the CPU is with a puller. It's a two part tool
> with an outer "U" shaped piece with the ends covered to protect the board
> and an inner, spring steel "U" with the ends bent in to catch two edges of
> the chip. A screw is used to pull up on the inner part to pull the chip.
> Those might not be easy to find these days since PGA style chips and
> sockets aren't very common.
> I never used one back in the days before ZIF sockets. I just used a small,
> flat blade screwdriver and carefully pried up a little at a time on each
> edge until the chip was out.
> DayStar sent a puller with any of their CPU upgrades and adapters that
> required pulling chips. (Except for the IIcx, you had to verify the CPU was
> socketed before they'd send the puller - after they had some people destroy
> their boards trying to pull soldered CPUs.)
> If you bend a pin, here's the perfect tool for straightening them. Find a
> syringe needle that will just slip over the pin and grind the point off so
> its straight. Use a sharp and pointy knife to deburr the inside of the
> needle after grinding it. A metal file should work, just slower than a
> Dremel or bench grinder.
> The needle lets you get to any pin without touching the ones around it.
> Look sideways across the chip from all directions, the slightest bend in a
> pin will show easily.
On Nov 2, 10:39 am, Britt Dodd <brittman...@gmail.com> wrote:
> You can straighten pins with a credit card or three, whatever fits in the
> spaces between the pins, then go at 90 degrees to the bent pin. After
> getting all 4 sides, the pin should be straight.
I like to use a PCI slot cover for that. It's a nice stiff flat
piece of metal which works well as a pin straightener.
The hazard in removing the 68040 (or any PGA chip) with a screw driver
is bent pins. The pins are bent when one accidentally raises one edge
of the PGA chip up out of the socket while the opposite edge stays in
the socket. This causes the pins on the engaged edge of the chip to
bend severely.
One solution is to use a twisting motion. Start with a very small
(narrow blade) flat head screwdriver and do not pry the chip up.
Instead insert the screwdriver between the edge of the chip and the
socket and gently rotate the screwdriver to raise the chip. Go
around and do this on all four edges of the chip. The advantage of
this method is that the amount by which you can raise one edge of the
chip is limited to the width of the screw driver blade. And if you
rotate carefully, you can control that to limit it further.
What about a heat sink after upgrading with a full 68040? How much
more heat does the floating point logic add?
In my upgrade to a LC 575 board in a Color Classic I haven't placed a
heat sink on the replacement chip, but then I haven't run the
assembled computer for any length of time yet either.
Dave
>What about a heat sink after upgrading with a full 68040? How much >more heat does the floating point logic add?
>In my upgrade to a LC 575 board in a Color Classic I haven't placed a >heat sink on the replacement chip, but then I haven't run the >assembled computer for any length of time yet either. >Dave
Can't hurt. 33 MHz 040's can run a bit hot and it's always a good idea to
keep vintage components as cool as possible. However unless you're running a
math intensive program that uses the FPU I doubt a full 040 will run too
much warmer than it's LC brethren. I have an "040 Chiller" I bought from
Output Enablers on my 48 MHz overclocked Quadra 840av and it does a great
job of keeping things cool. A touch expensive though...
On Mon, Nov 2, 2009 at 11:51 AM, Dave <v8d...@gmail.com> wrote:
> What about a heat sink after upgrading with a full 68040? How much
> more heat does the floating point logic add?
> In my upgrade to a LC 575 board in a Color Classic I haven't placed a
> heat sink on the replacement chip, but then I haven't run the
> assembled computer for any length of time yet either.
> Dave
On Nov 2, 3:17 pm, Scott Henderson <scotth...@gmail.com> wrote:
> Can't hurt. 33 MHz 040's can run a bit hot and it's always a good idea to
> keep vintage components as cool as possible. However unless you're running a
> math intensive program that uses the FPU I doubt a full 040 will run too
> much warmer than it's LC brethren. I have an "040 Chiller" I bought from
> Output Enablers on my 48 MHz overclocked Quadra 840av and it does a great
> job of keeping things cool. A touch expensive though...
> On Mon, Nov 2, 2009 at 11:51 AM, Dave <v8d...@gmail.com> wrote:
> > What about a heat sink after upgrading with a full 68040? How much
> > more heat does the floating point logic add?
I replace the LC in my quadra605, and did not put a fan. but it is
only running at 25mhz and it is rated at 33.
However my quadra630, had a full '040 to start with and there is no
heat sink IIRC. that is a 33 rated and running at.
If I overclocked the 630 then I would put a heat sink. If I ran the
605 above 33 I would.
But you can always just try it and if it hangs then do the sink. I
have done these experiments on Beige G3 where overclocking is EZer,
and I have not hurt the cpu overheating it.
BTW the fpu on '040 is not very good, but is usually required for
certain things. The FPU is weak, but software FPU is impossibly so.
Even for the first powerpc 601/60 the FPU is 10x the '040.
As fas as I know, the EC is a further stripped down 040. From Wikipedia:
"Versions of the '040 were created for specific market segments, including the 68LC040 which removed the FPU, and the 68EC040 which removed both the FPU and MMU. Motorola had intended the EC variant for embedded use but embedded processors during the 68040's time needed nowhere near the power of the '040, so EC variants of the '020 and '030 continued to be common in designs."
The Amiga 1200 had an EC020 and ran fine, but at least on paper the EC40 should be even slower than the LC40 as fitted to Performas.
Gorka -------- Original-Nachricht --------
> Datum: Tue, 24 Nov 2009 13:32:54 -0500 > Von: Britt Dodd <brittman...@gmail.com> > An: vintage-macs@googlegroups.com > Betreff: Re: Installing a full 68040 in a Performa 631 > I heard from a well-known mac guy in my area that the EC chips were better > than the full 040, so I swapped him for a EC in my 610. It runs poorly.
-- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
On Nov 24, 12:38 pm, "Gorka Martinez Mezo" <g...@gmx.net> wrote:
> > Datum: Tue, 24 Nov 2009 13:32:54 -0500
> > Von: Britt Dodd <brittman...@gmail.com>
> > I heard from a well-known mac guy in my area that the EC chips were better
> > than the full 040, so I swapped him for a EC in my 610. It runs poorly.
> As fas as I know, the EC is a further stripped down 040. From Wikipedia:
> "Versions of the '040 were created for specific market segments, including the 68LC040 which removed the FPU,
> and the 68EC040 which removed both the FPU and MMU.
I'm surprised it would run at all. I had always assumed that with the
MMU stripped out the Macintosh would be missing an essential
component. I'm surprised the operating system can handle the lack of
an MMU. It would be interesting to see what happens if Britt tries to
turn Virtual Memory on.
> I'm surprised it would run at all. I had always assumed that with the > MMU stripped out the Macintosh would be missing an essential > component. I'm surprised the operating system can handle the lack of > an MMU. It would be interesting to see what happens if Britt tries to > turn Virtual Memory on.
> Jeff Walther
For a long time, the 68k Mac emulators like Basilisk II didn't emulate the MMU. I don't know if they still don't, I haven't messed with it in awhile (Plenty of real Macs to mess with now ;) ). But, they pretty much worked fine.
The net result was the Virtual Memory was completely non-functional; if you turned it on, it'd just show off the next time you booted. Also, alternative OSes such as Linux and BSDs that depend on MMUs for core functions wouldn't work. Apparently, the Mac OS itself (at least through the 8.1 that 68ks support) doesn't need or care about the MMU aside from VM. I don't recall now whether some of the specialized apps like Photoshop that did its own VM and caching worked, but I think they did.
On Wed, Nov 25, 2009 at 11:27 AM, Scott Holder <sc...@iamscott.net> wrote:
> Jeff Walther wrote:
> > I'm surprised it would run at all. I had always assumed that with the
> > MMU stripped out the Macintosh would be missing an essential
> > component. I'm surprised the operating system can handle the lack of
> > an MMU. It would be interesting to see what happens if Britt tries to
> > turn Virtual Memory on.
> > Jeff Walther
> For a long time, the 68k Mac emulators like Basilisk II didn't emulate
> the MMU. I don't know if they still don't, I haven't messed with it in
> awhile (Plenty of real Macs to mess with now ;) ). But, they pretty
> much worked fine.
> The net result was the Virtual Memory was completely non-functional; if
> you turned it on, it'd just show off the next time you booted. Also,
> alternative OSes such as Linux and BSDs that depend on MMUs for core
> functions wouldn't work. Apparently, the Mac OS itself (at least through
> the 8.1 that 68ks support) doesn't need or care about the MMU aside from
> VM. I don't recall now whether some of the specialized apps like
> Photoshop that did its own VM and caching worked, but I think they did.
Since the (real) Mac OS and all Mac OS applications run in the same (supervisor) memory space, it doesn't seem like there would be any need for the MMU except for VM... That said, the lack of an MMU would prevent the running any Unix OS as they all (to my knowledge) require it.
>> I'm surprised it would run at all. I had always assumed that with >> the >> MMU stripped out the Macintosh would be missing an essential >> component. I'm surprised the operating system can handle the lack of >> an MMU. It would be interesting to see what happens if Britt >> tries to >> turn Virtual Memory on.
>> Jeff Walther
> For a long time, the 68k Mac emulators like Basilisk II didn't emulate > the MMU. I don't know if they still don't, I haven't messed with it in > awhile (Plenty of real Macs to mess with now ;) ). But, they pretty > much worked fine.
> The net result was the Virtual Memory was completely non- > functional; if > you turned it on, it'd just show off the next time you booted. Also, > alternative OSes such as Linux and BSDs that depend on MMUs for core > functions wouldn't work. Apparently, the Mac OS itself (at least > through > the 8.1 that 68ks support) doesn't need or care about the MMU aside > from > VM. I don't recall now whether some of the specialized apps like > Photoshop that did its own VM and caching worked, but I think they > did.
Derek Morton wrote: > Since the (real) Mac OS and all Mac OS applications run in the same > (supervisor) memory space, it doesn't seem like there would be any > need for the MMU except for VM... That said, the lack of an MMU > would prevent the running any Unix OS as they all (to my knowledge) > require it.
> Derek
The only UNIXy thing that works would be MacMinix, since it runs as an application in Mac OS rather than a standalone OS. It's pretty limited though, really only good for playing with something remotely UNIX-like and learning the basics of command line rather than getting anything real done.
On Wed, Nov 25, 2009 at 1:23 PM, Scott Holder <sc...@iamscott.net> wrote:
> Derek Morton wrote: >> Since the (real) Mac OS and all Mac OS applications run in the same >> (supervisor) memory space, it doesn't seem like there would be any >> need for the MMU except for VM... That said, the lack of an MMU >> would prevent the running any Unix OS as they all (to my knowledge) >> require it.
>> Derek
> The only UNIXy thing that works would be MacMinix, since it runs as an > application in Mac OS rather than a standalone OS. It's pretty limited > though, really only good for playing with something remotely UNIX-like > and learning the basics of command line rather than getting anything > real done.
Indeed... Perhaps another Unix option would be MachTen by Tenon... I really don't know what the system requirements are , but it is also a 68K / PPC MacOS application Unix, not as robust as a traditional Unix, but full featured. Might be an interesting try... If I cared for Unix. LOL
> Derek Morton wrote: >> Since the (real) Mac OS and all Mac OS applications run in the same >> (supervisor) memory space, it doesn't seem like there would be any >> need for the MMU except for VM... That said, the lack of an MMU >> would prevent the running any Unix OS as they all (to my knowledge) >> require it.
>> Derek
> The only UNIXy thing that works would be MacMinix, since it runs as an > application in Mac OS rather than a standalone OS. It's pretty limited > though, really only good for playing with something remotely UNIX-like > and learning the basics of command line rather than getting anything > real done.
J. Alexander Jacocks wrote: > On a connected topic, how much of a difference in performance would it > make, to replace the 25mHz 68LC040 in a Quadra 605 with a full '040?
> Thanks!
> On Wed, Nov 25, 2009 at 1:23 PM, Scott Holder <sc...@iamscott.net> wrote:
>> Derek Morton wrote:
>>> Since the (real) Mac OS and all Mac OS applications run in the same >>> (supervisor) memory space, it doesn't seem like there would be any >>> need for the MMU except for VM... That said, the lack of an MMU >>> would prevent the running any Unix OS as they all (to my knowledge) >>> require it.
>>> Derek
>> The only UNIXy thing that works would be MacMinix, since it runs as an >> application in Mac OS rather than a standalone OS. It's pretty limited >> though, really only good for playing with something remotely UNIX-like >> and learning the basics of command line rather than getting anything >> real done.
On Wed, Nov 25, 2009 at 2:13 PM, Scott Holder <sc...@iamscott.net> wrote:
> Depends on what you're doing with it. For general OS, word processing, > internetting, etc... not a whole lot. Most of that doesn't hit the FPU > at all.
> If you're looking to do some gaming with the fancier later games, or > Photoshop, or some other specific things, it would have a pretty huge > impact.
> Scott
> J. Alexander Jacocks wrote: >> On a connected topic, how much of a difference in performance would it >> make, to replace the 25mHz 68LC040 in a Quadra 605 with a full '040?
>> Thanks!
>> On Wed, Nov 25, 2009 at 1:23 PM, Scott Holder <sc...@iamscott.net> wrote:
>>> Derek Morton wrote:
>>>> Since the (real) Mac OS and all Mac OS applications run in the same >>>> (supervisor) memory space, it doesn't seem like there would be any >>>> need for the MMU except for VM... That said, the lack of an MMU >>>> would prevent the running any Unix OS as they all (to my knowledge) >>>> require it.
>>>> Derek
>>> The only UNIXy thing that works would be MacMinix, since it runs as an >>> application in Mac OS rather than a standalone OS. It's pretty limited >>> though, really only good for playing with something remotely UNIX-like >>> and learning the basics of command line rather than getting anything >>> real done.
On Nov 25, 11:13 am, Scott Holder <sc...@iamscott.net> wrote:
> If you're looking to do some gaming with the fancier later games, or
> Photoshop, or some other specific things, it would have a pretty huge
> impact.
I disagree with this from experience. Things like filters in Photoshop
which are impossible (disallowed) without the FPU or impossible slow
do work however they are still much too slow for any practical use,
even with smallish pictures (like 320x240 -- which might appear on a
web page).
For any real FPU usage better to have even one of the earliest
powerpc. Those machines that came with any '040 will accept a ppc
upgrade. The FPU is like 10X faster on ppc.
The separate chip FPU on the '30 machines was a more significant gain
(for them at the time). (?partly because it was a true coprocessor,
like the AV model DSP chips?).
And BTW there was also a separate MMU chip for earlier MMU-less 68k (?
'020?)
> J. Alexander Jacocks wrote:
> > On a connected topic, how much of a difference in performance would it
> > make, to replace the 25mHz 68LC040 in a Quadra 605 with a full '040?
On Nov 25, 9:32 pm, tortoise <cymraeg...@gmail.com> wrote:
> And BTW there was also a separate MMU chip for earlier MMU-less 68k (?
> '020?)
The Macintosh II had a 68020 with an AMU (?) (IIRC) chip which could
be updated to the PMMU.
My understanding is the the 68K emulator built into the PPC Macintosh
ROMs emulates a 68020. So the hooks for this kind of system must
still be in the operating system at that time. The thing that
surprises me is that the OS could detect a 68040 and then use the
68020 system in which a PMMU may be absent. Perhaps if the OS does
not detect a PMMU it assumes it is running on a 68020 or earlier? It
would all depend on how Apple built those case statements (or
equivalent).
> On Nov 25, 9:32 pm, tortoise <cymraeg...@gmail.com> wrote:
>> And BTW there was also a separate MMU chip for earlier MMU-less 68k (?
>> '020?)
> The Macintosh II had a 68020 with an AMU (?) (IIRC) chip which could
> be updated to the PMMU.
I believe that Apple referred to their ASIC replacement for the PMU as an HMMU.
> My understanding is the the 68K emulator built into the PPC Macintosh
> ROMs emulates a 68020. So the hooks for this kind of system must
> still be in the operating system at that time. The thing that
> surprises me is that the OS could detect a 68040 and then use the
> 68020 system in which a PMMU may be absent. Perhaps if the OS does
> not detect a PMMU it assumes it is running on a 68020 or earlier? It
> would all depend on how Apple built those case statements (or
> equivalent).
The existence of an MMU is only going to be of concern to an OS and (just guessing) an emulator is probably not going to deal with it at all. The emulator would just let the native OS it's running under deal with memory.
IIRC the 68030 had no user level code differences with the 68020. The 68040 had a few but very few programs made use of them in order to maintain code compatibility with older computers. So emulating a 68020 would work with most apps.
-- Clark Martin
Redwood City, CA, USA
Macintosh / Internet Consulting
"I'm a designated driver on the Information Super Highway"
>On Nov 25, 9:32 pm, tortoise <cymraeg...@gmail.com> wrote:
>> And BTW there was also a separate MMU chip for earlier MMU-less 68k (?
>> '020?)
>The Macintosh II had a 68020 with an AMU (?) (IIRC) chip which could
>be updated to the PMMU.
>My understanding is the the 68K emulator built into the PPC Macintosh
>ROMs emulates a 68020. So the hooks for this kind of system must
>still be in the operating system at that time. The thing that
>surprises me is that the OS could detect a 68040 and then use the
>68020 system in which a PMMU may be absent. Perhaps if the OS does
>not detect a PMMU it assumes it is running on a 68020 or earlier? It
>would all depend on how Apple built those case statements (or
>equivalent).
The 68 k series had instructions that, if not present in the hardware, would generate "A_line" traps that would interrupt to run user-provided code buried somewhere in the operating system.
I doubt that the OS did much to emulate a real PMMU but it's quite possible that Apple's virtual memory did. The floating point instructions were certainly emulated by A_line traps.
Since there were resources that could be loaded on demand in those days it was just a matter of loading up the trap code if and only if an A_line trap appeared. Things ran more slowly but the instructions in the main part of the OS were the same either way. Just assume an 040 even though the first one had never been delivered.
Actually the PMMU socket on the Mac-II was filled with some cross connections and nothing else. It was the UNIX types who actually installed a chip.
-- --> So do we celebrate the start of a new decade at the end of this year? Or do the tens start at in January 2011? Was the first year, 0000 ACE, assigned Roman numeral I ?<--
|
