Thread
Motorola 68060 upgrade
Depends on how you define shove. You can shove an '060 in an LC, but it won't do anything except take up space.
There are lots of threads on 68kmla where we lead the horse to water, try to make it drink, kill it, beat it after it's dead, try to ride it again, try to make it drink again, flog it some more, put on some techno and dance around it, et cetera. Just do a search for 68060.
There are lots of threads on 68kmla where we lead the horse to water, try to make it drink, kill it, beat it after it's dead, try to ride it again, try to make it drink again, flog it some more, put on some techno and dance around it, et cetera. Just do a search for 68060.
They're not socket compatible. For one, the m68060 is a 3.3 volt chip and the m68040 used in all Macs is a 5 volt chip. You can make or buy an adapter board, but then you have to reprogram the ROMs so that the '060 gets initialized correctly and the trap handlers know about the '060.
Simple, right?
Simple, right?
That is a great, succint summary of the issues involved. :lisa2:
The number one thing as mentioned is the voltage difference.
Number two is that only the "User Mode" of the 68060 is instruction-compatible with the same in the 68040. Mac OS runs in the "Supervisor Mode" of the CPU, which expressly is not 100% the same.
The number one thing as mentioned is the voltage difference.
Number two is that only the "User Mode" of the 68060 is instruction-compatible with the same in the 68040. Mac OS runs in the "Supervisor Mode" of the CPU, which expressly is not 100% the same.
Ah, this old chestnut...
What Coxy said. The electrical issues aren't much of a problem, IMO. But differing instruction sets kind of make it pointless for me. Probably more fruitful to explore 040 overclocking. Unless you have the source and skills to port some classic MacOS to 060, in which case I would say go for it!
What Coxy said. The electrical issues aren't much of a problem, IMO. But differing instruction sets kind of make it pointless for me. Probably more fruitful to explore 040 overclocking. Unless you have the source and skills to port some classic MacOS to 060, in which case I would say go for it!
Depending on the complexity, it could be possible to translate the incompatible instructions in hardware with an FPGA. This would allow the original Mac ROM and OS to continue working. If the substituted instruction is shorter than the original 040 code, NOPs can simply be inserted to direct the program counter back to the proper spot. But if the substituted instruction is longer than the original 040 code, things become more complicated pretty fast. You would have to line the program counter back up with a backwards jump and make absolutely sure that the condition codes were preserved. This would cause hiccups in cycle-exact-timed code, I'm not sure if that's a problem or not.
If the only issue is in ROM, it may be easier to fix it in software by opening the ROM, translating it, and burning it to new chips.
If the only issue is in ROM, it may be easier to fix it in software by opening the ROM, translating it, and burning it to new chips.
To reiterate earlier threads on this issue: by which time you may as well have done the same for a 200MHz+ ColdFire processor.
The 68060 processor costs something like $200+ new. Sure, they're available on the used market for about $50 but not reliably. Brand new Coldfire processors are less than $30 and easy to buy and probably almost as compatible in slightly different ways as a 68060 is almost compatible.
The 68060 processor costs something like $200+ new. Sure, they're available on the used market for about $50 but not reliably. Brand new Coldfire processors are less than $30 and easy to buy and probably almost as compatible in slightly different ways as a 68060 is almost compatible.
To quote from the "NATIVE CPU" section of the Basilisk II TECH documentation:
Code:
d) 68060 systems are a small problem because there is no Mac that ever
used the 68060 and MacOS doesn't know about this processor. Basilisk II
reports the 68060 as being a 68040 to the MacOS and patches some places
where MacOS makes use of certain 68040-specific features such as the
FPU state frame layout or the PTEST instruction. Also, Basilisk II
requires that all of the Motorola support software for the 68060 to
emulate missing FPU and integer instructions and addressing modes is
provided by the host operating system (this also applies to the 68040).The salient point in all of this, which gets reiterated every time someone makes a new thread about this, is that unlike x86 CPUs, in which newer CPUs with the exception of a few model-specific hardware control instructions are essentially always superset implementations of earlier models, Motorola's CPUs essentially peaked in complexity with the three-part MC68020+68851PMMU+MC68881/2 FPU chipset and that all subsequent models have actually *trimmed down* bits of the basic instruction set (particularly supervisor-mode and FPU instructions) and replaced the missing pieces with exceptions which jump to a software support bundle which then emulates the lacking function. Thus for all practical purposes you can't go beyond the 68040 without addressing this *software issue*. The idea of trying to trap the incompatibilities with some sort of hardware FPGA in front of the CPU is pretty laughable... it would require an instruction decoder sophisticated enough that at that point you might as well just create a whole CPU which is fully 68040 compatible. (But faster obviously, which would be a hugely challenging "garage project".)
The progress the ST people have had with their Atari Coldfire project indicates it *just might* be feasible to use a software library and some patching to run Mac II/Quadra ROM code and binaries on a newer CPU, but ironically it'd probably be much easier to do this in the form of a completely new-build "Coldfire Mac" board leveraging Basilisk II-style ROM patches for *all* the peripherals than it would be to do it in the form of an accelerator card for a real Mac. Such a machine equipped with the fastest Coldfire CPUs available might run 68k code about as fast as a mid-level G3 machine. (Of course, the G3 will completely crush the Coldfire running programs that have PowerPC binaries available.) If someone is really dying to embark on a multi-year project, well... it's an idea.
You could also check on the Natami website. It is a project aiming at building a modern 68k Amiga computer. The CPU is emulated within a FPGA and is 68040 compatible. I think I read somewhere that the performances where similar to a 100 (or was it 166?) mhz 68040, which is already quite impressive.
Obviously, the product is not finished and I don't know how much work would be required to run Mac OS on top of it.
Obviously, the product is not finished and I don't know how much work would be required to run Mac OS on top of it.
I would rather see an overclocked 68040 chip on a PDS card with some cache and modern high speed RAM. There is a new accelerator for the Amiga 600/1200 series that has a much faster modern RAM on the card and the speed improvement is pretty good (using a real 68030 CPU).
http://www.amiganews.de/en/news/AN-2010-09-00024-EN.html
The issue is few 68K mac users would bother paying for it. I have a 68040/50 with 128K cache in one of my 950's and it does rock, if you could mount that on a PDS card and stick in some super fast RAM it would be much faster and still be 100% compatible with all software that works on a 68040. Still there is a limit on how much I would pay for that setup.
If you are going to hack a CPU like a 68060 you might as well go PPC and then you might as well just get a newer mac for little on the used market. Amiga users spend the cash because there are no PPC Amigas to buy (well outside of a few super expensive rare upgrades and the A1 which will run old apps under emulation anyway).
http://www.amiganews.de/en/news/AN-2010-09-00024-EN.html
The issue is few 68K mac users would bother paying for it. I have a 68040/50 with 128K cache in one of my 950's and it does rock, if you could mount that on a PDS card and stick in some super fast RAM it would be much faster and still be 100% compatible with all software that works on a 68040. Still there is a limit on how much I would pay for that setup.
If you are going to hack a CPU like a 68060 you might as well go PPC and then you might as well just get a newer mac for little on the used market. Amiga users spend the cash because there are no PPC Amigas to buy (well outside of a few super expensive rare upgrades and the A1 which will run old apps under emulation anyway).
Off topic, but there's the SAM Flex units if you want to buy a PowerPC Amiga. The CPU is a PowerPC 440, which is a bit dire spec-wise compared to the G4, for example, but the architecture is impressively solid (I used one at a Commodore festival in Las Vegas and AmigaOS 4 -- now that it has a useful selection of web browsers between Timberwolf [Firefox 3.5] and Origyn Web Browser [WebKit] -- is really quite practical as a day-to-day OS now).
Just for random kicks, why not just emulate the 68060 and all necessary adaptions inside the FPGA? Even better, emulate both the 68040 and the 68060 in the FPGA and find a way to route all 68040 operations to the 68040? While your at, find a way to use them as some kind of dual-core setup that's masked to the mac os as one 68060.
You might be correct to say that it's nothing like software emulation, but emulation is emulation. It's not simulation.
FPGA implemented CPU cores are not very fast even on larger and more expensive FPGAs. The Natami project, for example, uses a real m68060 because the softcores are not as fast as a real m68060.
The m68060, you must remember, is no slouch. I'm often reminded because I see my m68060 systems (60 and 66 MHz) outrunning 133 MHz SH3, 100 MHz MIPS, 100 MHz SPARC, and 72 MHz VAX systems is most things as well as 200 and 233 MHz StrongARM systems in certain things.
If you really want m68k MacOS on an m68060, your best bet is an Amiga with an '060 accelerator or something like the Natami running AmigaOS with ShapeShifter to run MacOS. One of the good things about running under AmigaOS is that you get certain improvements such as a real multitasking OS which can do things when MacOS would typically busy-wait (such as when disk activity is going on).
FPGA implemented CPU cores are not very fast even on larger and more expensive FPGAs. The Natami project, for example, uses a real m68060 because the softcores are not as fast as a real m68060.
The m68060, you must remember, is no slouch. I'm often reminded because I see my m68060 systems (60 and 66 MHz) outrunning 133 MHz SH3, 100 MHz MIPS, 100 MHz SPARC, and 72 MHz VAX systems is most things as well as 200 and 233 MHz StrongARM systems in certain things.
If you really want m68k MacOS on an m68060, your best bet is an Amiga with an '060 accelerator or something like the Natami running AmigaOS with ShapeShifter to run MacOS. One of the good things about running under AmigaOS is that you get certain improvements such as a real multitasking OS which can do things when MacOS would typically busy-wait (such as when disk activity is going on).
The Natami won't run AmigaOS 4 any time soon because the main processor is an m68k, not PowerPC. Also, I don't think Natamis are for sale yet.
But if you're Ok with running AmigaOS 3.x and not 4, then my guess is that the Natami would run circles around other systems which emulate the Amiga chipset because they've reimplemented AGA and the original chipset, but in a highly modernized way (128 megs of ChipRAM, anyone?)
Personally I think the amount of hardware which AmigaOS supports is too small. I prefer what the MorphOS people did - porting the OS to run on PowerMac hardware opened up possibilities for many more people. I have a PowerPC Mac mini which is wonderfully fast, tiny, and works well with modern peripherals, and if I had the option to run AmigaOS on it, I'd definitely do it.
But if you're Ok with running AmigaOS 3.x and not 4, then my guess is that the Natami would run circles around other systems which emulate the Amiga chipset because they've reimplemented AGA and the original chipset, but in a highly modernized way (128 megs of ChipRAM, anyone?)
Personally I think the amount of hardware which AmigaOS supports is too small. I prefer what the MorphOS people did - porting the OS to run on PowerMac hardware opened up possibilities for many more people. I have a PowerPC Mac mini which is wonderfully fast, tiny, and works well with modern peripherals, and if I had the option to run AmigaOS on it, I'd definitely do it.
I'm happy MorphOS runs on minis, but good grief, it needs to run on {i,Power}Books more (and the hardware is so similar between minis and iBooken that I can't believe they're not doing this or at least not planning to). There are plenty of POWER desktop form factors but very few laptops.
I know I would be limited to AmigaOS 3.x on a 68K, and I would be fine with that if the Natami were significantly better/higher performance. Still, 4.0 is pretty practical as an OS. I played with a SAM Flex at the last Commodore fair I went to and found I could do most of my daily tasks including net access (Origyn, Timberwolf, etc.). If I didn't have such a huge Mac investment I'd probably switch to Amiga, and if MorphOS gets certified for iBooks then I will be putting it on my spare for sure.
Btw, got my POWER6 server coming soon! I wanted a POWER7, but this will still do nicely. (2-way 4.2GHz)
I know I would be limited to AmigaOS 3.x on a 68K, and I would be fine with that if the Natami were significantly better/higher performance. Still, 4.0 is pretty practical as an OS. I played with a SAM Flex at the last Commodore fair I went to and found I could do most of my daily tasks including net access (Origyn, Timberwolf, etc.). If I didn't have such a huge Mac investment I'd probably switch to Amiga, and if MorphOS gets certified for iBooks then I will be putting it on my spare for sure.
Btw, got my POWER6 server coming soon! I wanted a POWER7, but this will still do nicely. (2-way 4.2GHz)
http://www.gnu.org/fun/jokes/know.your.sysadmin.html
I'm mostly under thug, with a dash of fascist. }
I totally should see if I can get SheepShaver to compile ...
I'm mostly under thug, with a dash of fascist. }
I totally should see if I can get SheepShaver to compile ...
Is it a personal machine or a work machine? I would like to get one for use at home, but they are too rich for my tastes.
I have a POWER 7 machine at work. Holy Crap it is fast.
Back to the topic.
Is the 68060 microcoded? If it is you could reprogram the microcode to work around the problem instructions.
It's a personal box mostly. My long-suffering Apple Network Server is finally exceeding my tolerance for flakiness, and I need another small-iron server. I still got almost 13 years out of it, though, and I expect to get the same or more from this 520. The ANS isn't being disposed of, just demoted to a playbox. They're a real collector's piece anyway, and it's certainly served me well.
Nope. The m68060 is not microcoded.
Just curious - what kind of flakiness have you been seeing? I'm still using a PowerMac 9600 (which is only slightly younger than the ANS), and while it is currently 100% stable (uptime of a year before moving datacenters while staying pretty busy), I'd like to keep my eye out for any warning signs.
I suppose you were running AIX on your ANS?
Just FYI, even if the 68060 were microcoded *very few* microcomputer CPUs allow the microcode to be modified by the user. ("Writable Control Stores" were fairly common in old CISC mainframes and some Minicomputers, however.) Nearly all eight and sixteen-bit CPUs are fully microcoded, but to change anything in almost every possible instance you'd be looking at having to modify a mask ROM on the CPU die itself.
And yeah, I know Intel CPUs since the Pentium Pro can be loaded with runtime microcode patches, which is a fairly unique ability, but even in that case I don't think you could use that facility to, say, force a Pentium 4 CPU to recognize some hardware-specific instruction unique to the Pentium III series. Only Intel knows for sure (Intel's updates are encrypted and highly obfuscated to prevent them from being exploited or even accidentally loaded on the wrong CPU.), but the little research I've done seems to indicate that the Intel microcode table is essentially a breakpoint *after* the instruction decoder which allows a sequence of RISC-like "micro-ops" to be substituted for an existing operation sequence. (Usually the replacement string bypasses some hardware acceleration feature found to be buggy, thus trading off some performance for reliability.) Whether you could actually trap an "illegal" instruction and make it valid with a Microcode update *alone* on an an Intel CPU is something only they know, but it would probably be a non-trivial exercise.
In a purely theoretical sense I've wondered if it would be possible to modify a Transmeta VLIW CPU to run Motorola 68k code. In principle a Crusoe or Efficeon with appropriate code-morphing software could probably easily outperform *any* real 68k CPU, even the fastest Coldfires. Of course, Transmeta never released the tools or documentation you'd need to write your own code-morphing microcode so... that's that. We'll never know whether a 68k-morphing Efficeon would be able to outperform a conventional Intel or AMD CPU running a "normal" 68k emulator or not.
Now you are onto something with the Transmeta CPUs.
Back in college I had a professor that updated the microcode on a Pentium III as part of his research. It has been about 10 years, but IIRC he change the processor mode that an instruction was available in. As you said it is a non-trivial exercise.
I'm wonder what the performance of a ARM core would be while emulating 68k code. If the performance is good enough it might be possible to use it to build a drop in replacement.
Of course now we are entering the world of the incredibly complex. A much simpler way would be to patch the ROMs to work around the offending instructions.
Back in college I had a professor that updated the microcode on a Pentium III as part of his research. It has been about 10 years, but IIRC he change the processor mode that an instruction was available in. As you said it is a non-trivial exercise.
I'm wonder what the performance of a ARM core would be while emulating 68k code. If the performance is good enough it might be possible to use it to build a drop in replacement.
Of course now we are entering the world of the incredibly complex. A much simpler way would be to patch the ROMs to work around the offending instructions.
Yes, AIX 4.1.5 with my own security patches. I shouldn't be too hard on it, it's a pretty busy server, considering (the web server handles around 10,000 transactions a day -- not bad for a vintage server).
Part of the problem is probably the RAM. It uses the parity FPM option, and when it heats up, a bit probably flips somewhere and AIX MCHKs since it doesn't do ECC. The system stays up, but it forces a reboot and kicks me off. This happens a couple times a week and it's enough to finally annoy me sufficiently. However, NSDU can't handle more than 256MB of RAM and the RAM always passes the ROM-based Long RAM test because nothing's hot yet, so I've never been able to track it down (and try finding parity FPM RAM today!). Cache had also occurred to me, but I would have expected more than just an intermittent fault for that, and it kernel-panics with a stock PCI Power Mac cache stick so I'd have to wait around for another 700 1MB cache.
By comparison, the Power Mac 7300 that runs my Gopher server is rock-solid, but there's no parity RAM (let alone ECC), and it's got a G3 card and I've got plenty of spares for that (I bought lots of Sonnet's CPU cards when they were blowing them out so I would have parts). I think the issues I'm seeing are more specific to the ANS, because after all it was intended as Apple's "big iron."
At one time trag was looking at designing a CPU card for the ANS, but he never was able to get far enough with it, and I think there would be exactly two people who would buy it (he and I). I'm sure there are people still using ANSes in production environments, but very few, and I'm the only one I know of that still runs AIX.
I actually built a card for it, but it didn't work. However, it gave me a bunch of ideas of things to try, which I (mostly) never did. It would be an interesting project to go back to just for interest's sake, but there are so many other projects in the queue ahead of it... It was pre-offspring.
With no components installed: http://www.io.com/~trag/PCB/ANSCPU_blank.jpg
With connectors and clock magic chips installed: http://www.io.com/~trag/PCB/ANSCPUw_parts.jpg
The bottom of the board is an edge connector that plugs into the ANS CPU socket. The brown connector is a standard x500 style CPU socket meant to take any (604(e)) CPU card that will work in a Macintosh, and possibly G3s as well. Those sockets were already mostly unobtainium when I started the project. I managed to get two samples from AMP/Tyco. But no distributor had stock, so building the upgrade in any number would have required ordering 1000+ of them at $8+ each and there might have been a market for 100 upgrades back then.
The various jumpers are there because while I had most of the 300+ pins figured out, there were some for which I was not absolutely certain of the proper connection. I suspect that many of them were actually don't cares. But I put in jumpers just in case. But then I calculated that in the worst case (i.e. every signal mattering) there were 1024 possible combinations of jumper settings.
However, I'm pretty certain that the worst case did not apply as I had some email help from one of the engineers at XLR8 and he had answered my questions about those last few questionable signals. So the jumpers were really there in case the XLR8 guy got something wrong, or just to cover the possibilities.
But it did not work. My next experiment was going to be to see whether I could clock chip the ANS bus down to 10 - 20MHz from 50MHz. If that worked with a stock CPU card, then I would retry my card, which might have noise issues at higher speeds. If that did work, then I would consider laying it out again as a four layer board. If it didn't work, I'd either invent some other experiments, or perhaps just lay it out again in four layers anyway, because the two layer layout probably is never going to work. I also needed to take an oscilloscope to the clock signals to make sure I got them in phase properly. But I didn't have an oscilloscope until near the end of the project, and I'm not sure the one I got even works (came from a coworker) and cheap PC based O'scopes weren't available back then.
I did have to create a pinout list for the x500 Mac CPU socket so at least that came out of it. The pinout for the ANS socket is in the ANS Hardware Developer Note. In the course of learning about the X500 CPU socket, I also learned some things about the Catalyst CPU socket and the PowerBase CPU socket and why those machines (from Power Computing) had the upgrade issues that they had.
But this was all back around 2001.