Running a 68060 CPU in Quadra 650
Posted2 months agoActive2 months ago
github.comTechstory
excitedpositive
Debate
40/100
RetrocomputingMacintosh68060 CPU
Key topics
Retrocomputing
Macintosh
68060 CPU
A developer successfully ran a 68060 CPU in a Quadra 650 Macintosh, sparking discussion on the potential for further upgrades and modernizations of classic Macs.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2h
Peak period
16
6-9h
Avg / period
4.1
Comment distribution49 data points
Loading chart...
Based on 49 loaded comments
Key moments
- 01Story posted
Nov 7, 2025 at 8:18 PM EST
2 months ago
Step 01 - 02First comment
Nov 7, 2025 at 10:38 PM EST
2h after posting
Step 02 - 03Peak activity
16 comments in 6-9h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 9, 2025 at 12:56 PM EST
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45853204Type: storyLast synced: 11/20/2025, 4:11:17 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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.
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.
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).
That said, I’d possibly contest you on the single source issue you brought up. IBM likely would have told NS… much like they told Intel back in the day… that if they wanted to do business with them, that they needed to ensure second sourcing was possible.
Judging by how desperate NS was willing to make deals, I’m quite sure that hurdle would have been overcome quite easily, with AMD or even MOS Technology stepping up to fill the void.
That said...even if NS could wave a magic wand and produce a second source, there were plenty of other reasons to discount the 32k, and I've never seen the slightest evidence that IBM ever considered it.
Edit: This was wrong ", that they dropped already with the next CPU, the '030."
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.
Weird, I had believed for a long time that the MC68030 had dropped the memory-indirect address modes.
[0] https://en.wikipedia.org/wiki/NXP_ColdFire
And, yeah, they're unfortunately crazy expensive, esp if you get stuck with one of those fakes.
Bus error stack frames have been changed significantly
(per the bulletin board discussion linked below)
“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.”
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.
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.
If NeXT hadn’t killed their hardware division in 93, the RISC Workstation would’ve run an MC88110.
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 µops. 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...
Everyone was encouraged to move on to the fast subset and the new multimedia instructions.
Not only new code. Old code in an high-level language would benefit, too, if the language compiler was updated and the code recompiled.
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...
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" (μops or whatever term you like to use) is harder.
Coldfire V4/V5 are significantly faster than 060.
https://firebee.org/fb-bin/index
https://www.bigmessowires.com/plus-too/
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...
personally I think it's a bit too close to just emulating the whole thing
> personally I think it's a bit too close to just emulating the whole thing
Yes, I do know what you mean.
Although it's functionally more limited, there is also Emu68, which removes the native PiOS from the setup completely.
https://github.com/michalsc/Emu68