[HN Gopher] Running a 68060 CPU in Quadra 650
___________________________________________________________________
Running a 68060 CPU in Quadra 650
Author : zdw
Score : 71 points
Date : 2025-11-08 01:18 UTC (21 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| zdw wrote:
| Related message board thread:
| https://68kmla.org/bb/index.php?threads/macintosh-68060-redu...
| ido wrote:
| Isn't the 68060 backward compatible? Why wouldn't it run the same
| binaries compiled for other 68k CPUs?
| Someone wrote:
| https://www.cpu-world.com/CPUs/68060/index.html:
|
| _"Supervisor mode of the Motorola 68060 CPU differs from the
| 68040 due to changes in exception processing. User mode of the
| Motorola 68060 is object-compatible with MC68040, assuming that
| the CPU uses special software to simulate a few instructions
| that were present in 68040 CPU and are missing in MC68060."_
| homarp wrote:
| 68060 has a reduced integer and floating point instruction set
| ( Motorola cut down some of the lesser used instructions in
| order to keep the die size under control. However, to remedy
| this they made available an ISP (Integer Support package) and
| FPSP (Floating point support package))
|
| Bus error stack frames have been changed significantly
|
| (per the bulletin board discussion linked below)
| bell-cot wrote:
| Big picture: Motorola's 68K architecture was a case study in
| Death by Feature Creep.
|
| Short-term: The 68K was loved by assembly language programmers
| - a big thing, in the 80's. And it felt and sounded so cool for
| Motorola to add even more great features to each generation of
| the architecture.
|
| Long-term: If you want your microprocessor architecture to stay
| a thing in higher-performance desktop/server use (vs. toaster
| ovens & thermostats & such) - then you need to have a few
| Senior Implementation Engineers looking a decade or so ahead,
| and saying "NO" to cool features that could turn into
| implementation hell.
|
| The 68060 was where the long-term issues really caught up with
| the 68K architecture, and it hit the brick wall / grave stone.
| Which is why Motorola pretty much dumped their 68K for IBM's
| Power architecture, in the PowerPC.
| rjsw wrote:
| Motorola built the 88K in between the 68K and PowerPC.
| RJIb8RBYxzAMX9u wrote:
| Well, 68k lived on in spirit for a while in ColdFire[0].
|
| [0] https://en.wikipedia.org/wiki/NXP_ColdFire
| badgersnake wrote:
| So nothing like x86 then?
| Tuna-Fish wrote:
| x86 is not nearly as bad as 68k, more by lucky accident
| than design. As it was a stop-gap project designed to
| hastily extend an earlier design to 16 bit and 20-bit
| addressing while the proper cpu of the future (iAPX432)
| needed a few extra months to bake, the designers didn't
| have enough time to properly fubar the core of the
| instruction set. This made x86 assembly much less nice to
| write than the nearly fully orthogonal 68k, but also made
| it much easier to make the subset of it that was in actual
| use faster later.
|
| 68k designers were not being dumb when they designed it. At
| that time pretty much the entire industry was deep in the
| weeds of "closing the semantic gap", or making CPUs
| directly run the operations that would be encoded in high-
| level languages. All CPUs designed to this paradigm were
| doomed, and how doomed they ended up being depended mainly
| on how well they managed to implement it.
|
| IBM's 801 and Patterson's RISC would blow it all up in the
| early 80's.
| TheAmazingRace wrote:
| A shame, really. 68k was (and is) much more approachable
| for those learning assembly. No need to deal with 64k
| segmented memory, for instance.
|
| As an aside... National Semiconductor also had an ill-
| fated architecture in the NS32000, which I also wish took
| off. On paper, it really did a lot right (VAX-like
| design, flat memory model, 32-bit almost immediately out
| of the gate) yet NS was woefully incapable of producing
| masks without bugs. It took them many tries to get it
| right, and before then, they already were being beat to
| market by their competition.
|
| Then to add insult to injury, NS' own compiler for
| NS32000 chips was producing rather unoptimized code. It
| took GNU porting GCC to the platform in 1987 for them to
| fully realize their potential, years after they missed
| their chance.
|
| If NS did have their act together... dare I say an IBM PC
| built around their CPU would have been possible and more
| interesting than the 8088 they ultimately went with.
| kjs3 wrote:
| AFAIK, NS used the Green Hills compiler; at least, my
| ns32532 dev system comes with it. It's not great, but not
| terrible. I personally don't remember the compiler being
| in the top 5 show-stopper issues with the 32k (the first
| 3 were 'cpu bugs', 'mmu bugs' and 'fpu bugs'). And it was
| slow, particularly if you used the MMU.
|
| The 32000 line (like the 68000) found a very long life as
| an embedded processor, particularly in the printer/fax
| space (ns32cg16 and followons, ns32gx32).
|
| The 32332 was a nice processor. The 32532 was very, very
| nice. Both way too late.
|
| Given what IBM was trying to deliver with the PC, I doubt
| they'd have looked at the 32000. Single source, few i/o
| support chips, relatively expensive, etc., etc. Way more
| likely that a non-Intel IBM PC would have had a Z8000
| inside (and not a 68k, for mostly IBM political reasons).
| Findecanor wrote:
| Motorola added too many complex addressing modes in the '020
|
| Edit: This was wrong ", that they dropped already with the
| next CPU, the '030."
| adrian_b wrote:
| They dropped them only much later, in Coldfire, not in
| 68030, which was completely compatible with 68020. MC68040
| dropped some features, then MC68060 dropped more features,
| but for user programs they remained binary compatible with
| MC68020.
|
| They have probably realized quickly that adding memory
| indirect addressing modes was a mistake, but they could not
| drop them because that would have broken all programs
| ported to MC68020.
|
| With Coldfire, they were able to prune the unwanted
| addressing modes, because Coldfire was intended for
| embedded computers, where the software is recompiled for
| every new project and binary compatibility with legacy
| programs is not necessary.
|
| Both the addressing modes of Intel 80386 (1985) and of
| Motorola MC68020 (1984) were inspired by the addressing
| modes of DEC VAX, but in a very rare event in the history
| of Intel processors the Intel designers have done the right
| thing by choosing the useful subset of the DEC VAX
| addressing modes, while the Motorola designers have made a
| mistake by choosing to implement an even more complex set
| of addressing modes than that of DEC VAX.
| Findecanor wrote:
| I double-checked, and you're right. I stand corrected.
|
| Weird, I had believed for a long time that the MC68030
| had dropped the memory-indirect address modes.
| eschaton wrote:
| The 68030 really only dropped the Call Module and Return
| from Module instructions, which nobody used anyway since
| relatively few developers wanted to write code only for
| 68020 and higher around the time the 68020 and then 68030
| shipped.
| badgersnake wrote:
| I've got a 68060 RC (MMU, no FPU) in my Amiga 1200 and it seems
| to work alright. The full 68060 is insanely expensive these
| days though, you could get a decent Ryzen for a lot less money.
| TheAmazingRace wrote:
| In your specific case too, I believe there are options for
| soft emulation of the FPU if you needed support for one in a
| pinch. I can't say how the performance is, but I'd imagine it
| would be insanely slow.
| kjs3 wrote:
| That would be a 68LC060. And the 68EC060 was no MMU, no FPU.
| The RC just means it's a ceramic PGA package, so an
| MC68LC060RC50 would be a 68060 with MMU, without FPU, in a
| ceramic PGA206 package binned to run at 50MHz. If you have a
| 68060RCxx chip that doesn't have a (functioning) FPU, it's
| probably a relabled 'fake' LC, which is actually pretty
| common.
|
| And, yeah, they're unfortunately crazy expensive, esp if you
| get stuck with one of those fakes.
| badgersnake wrote:
| Ahh yes you're right. I mixed up my RCs and LCs.
| wat10000 wrote:
| I'm far from an expert, but it seems pretty common for new CPUs
| to be compatible with old ones at the application level, but
| not fully compatible with OSes. It seems like there's a
| (reasonable, I'd say) assumption that vendors are willing to
| update the OS when they ship new hardware. Of course, this
| makes it hard to upgrade the CPU in a machine that hasn't been
| supported for decades.
| zatkin wrote:
| I appreciate how in the YouTube video on the repo's README, his
| cat walks right on top of his project, and he doesn't even react
| at all. The cat just gets out of the way all by itself. But I
| guess it _had_ to be part of the clip, heh.
| kjs3 wrote:
| As a cat owner, you get used to it.
| LeoPanthera wrote:
| Was the 040/060 always supposed to be the end of the line, or
| might we have seen more advanced "68k" chips if sales had
| continued?
| kalleboo wrote:
| Motorola wanted to replace the 68000 series with their RISC
| design, the 88000, so it was probably always going to end
| there. Their customers were also all in full RISC hype fever
| and were looking for RISC chips to move to.
|
| In Apple's search for a RISC chip, didn't want to be stuck
| being single-sourced again so they had IBM and Motorola work
| together to launch PowerPC instead, so Motorola gave up on the
| 88k.
| Findecanor wrote:
| I have seen mentioned a couple of times that the 88K would
| have had some inherent design flaw that made the architecture
| a dead end. I have never found an explanation _what_ that
| would have been though.
|
| Perhaps this had just been a misunderstanding of a second-
| hand statement. Its _first_ _iteration_ was flawed in that it
| was an expensive multi-chip solution with few buyers. The
| second was more integrated though.
| fredoralive wrote:
| If there was demand for more high performance 68k processors,
| presumably Motorola would have made more. But by the time of
| the 68060 customers for high end 68k had either already moved
| onto various RISC architectures (Mac, UNIX workstations) or
| were dead / dying (ST, Amiga).
|
| A related question would be if Motorola could pull off what
| Intel did with x86, and drag the architecture to be competitive
| with RISC. Part of Intel's trick was that x86 isn't the most
| CISCy of chips, so it was easy to implement a processor that
| takes a "RISCy subset" of instructions and translate them into
| one or two uops. 68k is perhaps more on the VAX side of things,
| so whether they'd be able to pull off the same trick is a bit
| unclear. Clearly we need to check the parallel universes where
| IBM chose the 68008 for Chess instead of the 8088...
| actionfromafar wrote:
| I checked one of the adjacent ones, and there Motorola used
| traps and microcode internally for emulation of some of the
| CISCier instructions and a fast RISCy core for the rest.
|
| Everyone was encouraged to move on to the fast subset and the
| new multimedia instructions.
| Tuna-Fish wrote:
| The problem was mainly in x86, existing code already mostly
| used instructions that belonged to the fast subset, and on
| 68k, it didn't. So while you could evolve the instruction
| set towards a saner design (and the 68060 was well on the
| way towards that), only new code would benefit from it.
| Someone wrote:
| > only new code would benefit from it.
|
| Not only new code. Old code in an high-level language
| would benefit, too, if the language compiler was updated
| and the code recompiled.
| actionfromafar wrote:
| Or sometimes, binary pached.
| Findecanor wrote:
| This. Don't underestimate the amount of M68K code written
| in assembly language.
| fredoralive wrote:
| Not everyone has that sort of luxury of access to source
| etc., people want their existing binaries to run faster.
|
| Also, if you need to recompile to get a performance
| boost, why not recompile for a cleaner modern
| architecture? You can always use an emulator for legacy
| code, if it isn't going to run fast on a modern CPU
| either way...
| robinsonb5 wrote:
| And of course that's exactly what they did with Coldfire
| - rounding off the inconvenient corners of the ISA to
| produce CPUs with lower power requirements and able to
| run at higher clock speeds.
| kjs3 wrote:
| They did it with the 68030 before Coldfire. They
| discarded a number of things (e.g. addressing modes) that
| seemed like good ideas for the <=68020 but didn't end up
| being used in practice.
| fch42 wrote:
| on the m68k, the "cisc-y-ness" is in the many many
| addressing modes, whereas x86 in that particular aspect
| of the architecture has always been rather "risc-y"
| (read: rather limited compared to other CISC
| architectures, including m68k).
|
| The core instruction set of the m68k, as far as ALU/FPU
| is concerned, is simple enough. But converting the
| addressing modes to "risc building blocks" (mops or
| whatever term you like to use) is harder.
| bryanlarsen wrote:
| We did, sort of: https://en.wikipedia.org/wiki/NXP_ColdFire
|
| Coldfire V4/V5 are significantly faster than 060.
| lproven wrote:
| And there's an Atari ST compatible based on them.
|
| https://firebee.org/fb-bin/index
| Aloha wrote:
| I've always wondered if someone could build a new FPGA based 68k
| mac, I know this isnt that, but it brings the thought to mind.
| AntiRush wrote:
| There's at least one implementation, a Mac Plus:
|
| https://www.bigmessowires.com/plus-too/
| zozbot234 wrote:
| inb4 the fastest 68k-based Mac is an Apollo Vampire running a
| Macintosh emulator
| vardump wrote:
| Vampire is not _really_ a 68k, it 's an FPGA based system. A
| kind of fantasy could-have-been system.
| lproven wrote:
| Can someone with a bit more chip-level knowledge explain to me
| why nobody has put a PiStorm into a classic Mac yet?
|
| https://github.com/captain-amygdala/pistorm
|
| If there are problems with the ISA or something, they're much
| much easier to tweak here. It already works in multiple models of
| Amiga, including both 68000 and 68020, and there's at least one
| effort to get one working in an Atari ST...
| Palomides wrote:
| someone did https://tinkerdifferent.com/threads/pistorm-on-the-
| macintosh...
|
| personally I think it's a bit too close to just emulating the
| whole thing
___________________________________________________________________
(page generated 2025-11-08 23:02 UTC)