In the '80s and '90s the Intel x86 and Motorola 68000 families were the two leading microcomputer architectures in the 16-bit/32-bit personal computer scene. The 68000s were even preferred by the purists because of its orthogonal instruction set. The Intel x86 family, although always the market leader, has been criticized for its non-orthogonal instruction set and segmented addressing.

When the Macintosh line switched to PowerPC, the Motorola 68000 family began to disappear as a contender for newly designed personal computers outside the “Wintel” ecosystem. New contenders, such as the PowerPC, ARM and MIPS, take the 68000 family’s place.

I cannot find on the internet the reason why the 68000 family fell out of favor in the personal computer market.

Can someone explain this or point me in the direction of the answer?

  • 17
    High cost and low volume meant Motorola couldn't afford the engineering to keep making them faster, so by early/mid 90s the x86s were both faster and cheaper. RISC cpus, being much simpler/cheaper to build took over everything not requiring Windows.
    – Chris Dodd
    Commented Sep 25, 2023 at 5:07
  • 20
    The success of x86 is not just the CPU, but the whole PC machine, e.g. BIOS and the peripheral hardware, timers, DMA and interrupt controllers. For a few decades we kept duplicating and emulating the entire original PC machine, and x86 ISA is just part of it. Even if someone designed a computer with a x86 core but with different set of peripherals such that it's not compatible with PC versions of available software, then it won't sell. Commented Sep 25, 2023 at 6:04
  • 15
    Processor architectures come and go. The history of the 68k architecture is perfectly normal. It's the x86 that's anomalous. I believe that is the result of Microsoft's peculiar inability to switch architectures. No other software company seems so stuck: they move opportunistically to whatever architecture suits their immediate needs. Apple has evolved 6502->68k->PPC->x86->ARM.
    – John Doty
    Commented Sep 25, 2023 at 12:14
  • 17
    But Microsoft has (or had) the ability to switch architectures. Windows has been available on MIPS, PowerPC, Alpha, Itanium, etc. Why MS no longer supports those is due to application unavailability. Unless 3rd party apps are available for a platform, no-one wants to buy that platform, and therefore OS support is an undue burden on MS. (Granted, the argument here is parallel support, rather than serial changes of ISA).
    – dave
    Commented Sep 25, 2023 at 12:37
  • 15
    @JohnDoty: Microsoft could and did switch architectures, as another-dave said, at least for their server OSes. The problem with making that commercially relevant for desktop/laptop home users is the 3rd-party ecosystem that's designed around binary compatibility not source, the strong backwards-compat of x86 which is or was its reason for commercial success, and crufty 3rd-party codebases that make all kinds of assumptions that aren't documented but are de-facto true on x86 Windows, like little-endian, stack-args calling conventions, etc. (Even moving to x86-64 was slow for some code.) Commented Sep 25, 2023 at 13:20

7 Answers 7


The Apple-IBM-Motorola alliance was created in 1991 to compete with the Windows/Intel market. Its main successes were the creation of the PowerPC instruction set, derived from IBM's POWER architecture, and Apple's Power Macintosh line of computers.

IBM originated the idea, having seen that Windows on Intel was out-competing OS/2, and wanting to avoid being dependent on Intel. Apple joined it, seeing the chance to grow out of their existing markets, and Motorola presumably saw it as a successor to 68000, having failed comprehensively with the MC88000.

While the 68000 was used in the Macintosh series, Atari STs and Amigas, all of which sold in large numbers, all the operating systems involved were quite different, so there was no unified software base. That meant there wasn't the sustained demand for 68000 that could have paid for chip development on the scale required to keep it competitive with x86. The engineering workstation market had started with the 68000, but had already switched to RISC before AIM was created.

  • 3
    Good answer, however I have to object to "home computers, plus the Macintosh". The "home computers" (I assume you mean the Amiga and Atari ST) were on the same level as the 68k Macs - ok, the Amiga was held back by only having "TV-compatible" video output (so its high-resolution mode was interlaced and flickering), and the Atari ST was derided as the "Jackintosh", but still, both of them were equally capable as the 68k Macs and also saw professional use.
    – rob74
    Commented Sep 26, 2023 at 14:34
  • @rob74: They had the hardware capabilities, but did they have the range and quality of software that the Macs did? See what you think of this edit. Commented Sep 26, 2023 at 21:35
  • 2
    @JohnDallman It feels like one of the long, fruitless discussions we held back in the days :) High regard for Macintoshes was mostly an American thing. In Europe - Amiga and Atari ST were seen as both less expensive and better for professional use. The killer applications were music and DTP for Atari ST (it had built-in MIDI and was the host to the original Digital Audio Workstation - Cubase) and video for Amiga (due to availability of inexpensive Genlock hardware).
    – fdreger
    Commented Sep 27, 2023 at 13:30
  • Bingo. Basic capitalism wins every time. If there's no demand for your product, it will necessarily be supplanted by products that consumers do want (or are willing to pay for).
    – Ian Kemp
    Commented Sep 27, 2023 at 15:59

The 68k family instruction set, as elegant as it appeared to the casual assembler programmer (been there), had several flaws that made it very difficult to get fast in hardware. Out of order or superscalar execution were very, very difficult to implement.

  • Over-complex addressing modes, especially the indirect one introduced with 68020: when combined with virtual memory made it theoretical possible to get up to 16 page faults in 1 instruction (move long indirect with displacement and shifted index from an odd address touching 2 pages etc.). These indirect addressing modes were the first to be removed when defining the Coldfire ISA.
  • Exposure of the pipeline internals on traps and exceptions: the idea was that on a trap, the instruction could be resumed after fixing the error cause. This made it very difficult to get performance out of the kernel as it wrote more and more data to the stack at each generation, and it also limited the internal state that could be saved. x86 was much more pragmatic and just restarted the cancelled instruction from start.
  • Compatibility between successive family members was not as good as in intel CPUs. If you want to compile a program that runs on 68000 and on any of 680[2346]0 you will lose a lot of features on the side.

There is the famous newsgroup post from John Mashey explaining the fundamental issue with the 68k ISA in comparison to other ISAs of that time.

  • 3
    An excellent explanation! I'd like to argue a bit: 1. x86 is also having insns that can create lots of page faults, for example block move insns. There's still a way to execute them slow yet correct, for example from within a microcode engine. 2. Those incompatibilities between families are at the same time a way to move further while dropping lots of no more necessary legacy en route.
    – lvd
    Commented Sep 25, 2023 at 13:20
  • 8
    @lvd: x86 rep movs is interruptible, though, so it can make partial progress through those page faults. (Same for AVX2 / AVX-512 gather / scatter instructions) Patrick is talking about the worst-case number of pages that all have to be present for a program to make forward progress. In x86's case, that's 6 (Do x86 instructions require their own encoding as well as all of their arguments to be present in memory at the same time?) for one step of a misaligned rep movsd with the 2-byte instruction spanning a page boundary itself. Commented Sep 25, 2023 at 13:27
  • 3
    Perhaps worth pointing out that 386 made x86 much more orthogonal than before, at least in 32-bit mode. (But if you're writing 16-bit code that cares about compat with 8086 or even just 286, you're in the same boat as 68k in terms of leaving new features unused because 68000 doesn't have them. Also, if the first hypothetical m68k Windows PCs used 68020, that would be the baseline for m68k PC software, not 68000.) Commented Sep 25, 2023 at 13:34
  • 4
    @PeterCordes: On the 68000, if memory address 0x1234FFFC holds the value 0x1234FFFE, code performs an indirect store of some 32-bit number through the address held in address 0x1234FFFC, and a page fault could occur when accessessing the least-significant halfword of the destination (0x12350000), that fault wouldn't occur until the 0xFFFE part of the address had been overwritten and the target address didn't exist anywhere in the universe outside the internal CPU state.
    – supercat
    Commented Sep 25, 2023 at 15:34
  • 2
    @Pierre: The 68000 had real advantages in ease of programming, until it was possible to use i386 flat mode in 1985-86. But before then, in 1984, Motorola had lumbered themselves with indirect addressing modes which made pipelining hard, limiting the performance of future 68000s. They then didn't do a very good job of the 88000, and joined the AIM alliance in 1991. Commented Oct 7, 2023 at 19:08

Motorola stopped investing in MC68000 family when everyone thought that RISC was the future and that CISC CPUs would be soon non competitive. So it switched to PowerPCs.

Even Intel thought this and developed RISC CPUs (i860, i960...). Intel reluctantly continued investing in x86.

For Motorola, it was probably true, the last version, MC68060 was competitive with Pentium but it was quickly surpassed because of Intel manufacturing superiority allowing lower dissipation, higher frequencies. Switching to simpler RISC CPUs could allow to stay in the race.

Now, the difference between RISC and CISC (eg x86) is less relevant performance-wise due to the possibility of putting 100 times more transistors on a die.

  • 3
    Before Motorola joined the AIM alliance it had a hand at creating its own RISC architecture, the 88000 line (m88k, consisting of two models shipped over the course of three years, before being discontinued in 1991).
    – njuffa
    Commented Sep 25, 2023 at 9:05
  • Yes, and AMD tried RISC with AMD29K.
    – Grabul
    Commented Sep 25, 2023 at 20:40
  • 3
    The main difference between CISC and RISC is in the engineering cost and complexity. As long as you have enough volume (sales), that cost can be made up. x86 had the volume and 68K did not.
    – Chris Dodd
    Commented Sep 26, 2023 at 21:51
  • 2
    @ChrisDodd: Another detail is that executing RISC code from cache is faster than executing CISC code from cache, but if CISC code is smaller than CISC code, it can be fetched from main memory faster than RISC code. Having a system store CISC code in main memory but convert it to a RISC representation before storing it into the internal cache offers the best of both worlds.
    – supercat
    Commented Sep 28, 2023 at 16:03

When the Macintosh line switched to Power PC, the Motorola 68000 family begun to disappear

It's been rather the other way around. Apple switching was a result of Motorola losing the race.

New contenders, such as the Power PC, ARM and MIPS take the 68000 family’s place.

Not really - also you forget the NS32k family going away at the same time, being maybe less visible but at least as successful as the 68k.

I cannot find in the internet the reason why the 68000 family fell out of favor in the personal computer market.

Cost on either side:

  • Motorola wasn't able to keep up investment to improve their CPUs the same way that Intel did
  • Resulting CPUs were considerably more expensive than Intel's offering.

This is not only true at upper end offerings with '060 vs. Pentium but even more for embedded. Basic 80(1)88 based systems could be delivered at considerable lower development and production cost.

  • 3
    Let me be doubtful about NS32032 success, as at that time I was a fan of NS products, and in the market of MCU/MPU for some time, and I've never seen a single design with it. I knew it had been employed in some high-end (for the time) laser printer, no idea what. MC68K was simply anywhere, its assembly language, high-level language friendly, was unbeatable. Only heavy-weight IBM could have decided by marketing for a technical freak CPU, coming from a company that didn't even believe in microprocessors.
    – LuC
    Commented Sep 25, 2023 at 16:02
  • 1
    Well, one example might be Siemens switched (ca. 1985) their Unix line (PC-MX) from Intel to NS. Those systems were way into the late 1990s the best selling Unix systems in Europe, covering a range from single 32032 CPU all the way to 16 way 32532. For market share in that segment 68k was at best a third.
    – Raffzahn
    Commented Sep 25, 2023 at 16:58
  • Well, starting from the mid-eighties I would recall Apple Macintosh, Commodore Amiga, and Atari ST/TT lines, without forgetting the venerable Sinclair QL. I'm quite sure they could have sold a few units more than Siemens' devices. On the industrial side, I've witnessed a few VME bus systems with MC68K, running Sys V too.
    – LuC
    Commented Sep 26, 2023 at 10:44
  • 2
    @LuC Sure, but whats your point? You assumed there weren't any NS systems, which he MX family proves different. Same goes for embedded. Especial in high reliability environments. Also, do you really think the National would have poured the money needed to developing the series all the way to the 32641, a 1992 superscalar server CPU - not to mix up with the embedded 32x160 series, developed until 1997 - if it wasn't successful and generating positive ROI?
    – Raffzahn
    Commented Sep 26, 2023 at 10:59
  • I'm still convinced that besides any great innovation in the NS32K series, they didn't have as much market success as you said. Of curiosity, I found a historical fan site mentioning the selling numbers of the Siemens MX 300 as 13000 units over its life span. In the early '90s, I collaborated with a small company (let's say insignificant, compared to Siemens) that was selling that number of 68K systems every month, and then I found strange reading of a similarity in success.
    – LuC
    Commented Sep 26, 2023 at 12:30

Motorola lost the race to 32 bit computing from a simple engineering mistake. In the era when the 68k and x86 were very popular, the shift to 32 bit CPUs was a race to mass production. No question the 68020 was a cleaner design and almost destined to be the no. 1 choice for new machines. Friends of mine paid around $400 at the time for early 68020 chips to build test boards. X86 at the time was hopelessly behind. BUT, the first iteration of the 68020 had pushed the design parameters of the chip process to the point that yields were appalling. Every chip sold at a loss. Motorola then had to redesign all the masks which was an 18 month engineering exercise. 18 months was the window that let x86 get ahead in the market and that was the end of the 68k family's dominance. Shame


I was at Intel from the late 80’s to the early 00’s first as a CPU architect then running various design teams and research teams. Prior to Intel I was an architect/designer of systems using 68K, x86, and custom CPU’s.

Readers of this forum are mostly technologists and will tend to answer from a technology-centric perspective (as the saying goes: To a carpenter with a hammer, everything looks like a nail). The reality is that market outcomes are the result of multiple inter-dependent factors. Technologies are only one factor and frequently not the most important. These factors include market participants (buyers and sellers), market structure (supply chains, sales channels), as well as technologies. All of these factors rest on a foundation of organizational execution and economic behavior.

When assessing market outcomes one needs to understand what is being purchased, who is making the purchase decision, and what their value propositions are. The question was about CPU’s but buyers weren’t buying “CPU’s”, they were buying “boxes” containing CPU’s and other components such as DRAM, disks, and operating systems.

Why were they buying boxes? To run application software – which over the time period in question was bought as a product (a binary), not as a service (SaaS). Binaries were compiled to a particular CPU instruction set and OS API – changing either would require buyers to pay for a new binary. To maximize the return of acquisition cost these binaries were re-used over multiple box/CPU generations.

In approximate order of units shipped, the ecosystems using microprocessors in the late 80’s were: Wintel PC, Apple, Sun Microsystems workstations, other workstation vendors (e.g. Apollo, SGI), and a smattering of microprocessor-based mini-computers. Except for the Wintel PC ecosystem, all used 68K.

In 1986 Sun replaced the 68K with SPARC, their home-grown RISC. In 1994 Apple replaced the 68K with PowerPC. In the 90’s SGI moved to MIPS. Other 68K vendors were either acquired or went out of business. Each vendor changed CPU’s for different reasons. Sun wanted to move to RISC – no doubt influenced by Bill Joy who joined Sun from Berkeley where a RISC project was ongoing. By the 90’s, Apple had become worried about Motorola’s ability to keep pace with Intel in both performance and power (Apple threw a bone to Motorola by including them the AIM Alliance making PowerPC’s).

As the installed base of an instruction set or OS API increases, the incentive for software developers to target their binaries to these interfaces also increases – to amortize their upfront cost of development over a larger number of units shipped. This instantiates a feedback loop: Increasing ecosystem volume attracts more apps which increases demand for that ecosytem. Exacerbating this feedback loop was the fact that x86 volume was overhwelmingly concentrated on a single OS API (DOS then Windows) while 68K volume was split over multiple, incompatible, OS API’s (Apple, Sun, et al).

The profit from CPU generation N needs to pay for all the components of generation N+1: CPU development, fab process development, and at least one fab. The underlying economics of fabs are such that, as soon as a new fab process is ready, there should be a new CPU design ready to take advantage of the higher transistor budget enabled by that process and begin amortizing the very large upfront cost of building a fab. Adding to this was the fact that Intel’s yields were significantly higher than other CPU vendors.

One of the largest causes of 68K’s demise was Motorola’s execution relative to Intel. It was clearly the case that over the course of the 90’s the cadence at which Motorola shipped new CPU’s fell relative to Intel. These CPU execution cycles destructively (Motorola), or constructively (Intel), resonated with the underlying economics of silicon fabs, ecosystem platform volumes, and app development. Motorola’s CPU execution descended a vicious economic cycle while Intel’s ascended a virtuous economic cycle.

These are the broad strokes. There’s more detail here but this answer is already getting long.


This was purely economics. By about 1988 the ready availability of IBM AT clones had the effect of pushing the price of support hardware- including cases, discs etc.- down enormously, and even on the '286 there were UNIX variants that demonstrated that such things were possible. The '386, when introduced, exploited that, and from that point onwards it became a race between what Intel- with a growing income- and Motorola et al.- with static incomes- could do with the available semiconductor technology.

By about 1995 Intel's price/performance ratio was unassailable, and graphics accelerators which could operate in conjunction with PC hardware were starting to erode the market for specialist workstations.

  • 1
    Kinda misses the window. Apple and Motorola committed to PowerPc (thereby dooming the 68000) in 1991. With the AIM alliance (Apple, IBM, Motorola) backing PowerPC it was not at all clear that Intel's price/performance ratio was unassailable. The first PowerPC Mac shipped with the then-state-of-the-art ATI Mach 8 on the motherboard-- the ATI Mach 8 being essentially the first-generation of graphics accelerators on both platforms. Plus the PowerPc macs shared the same ISA bus with IBM machines. Mac has never particularly been a "specialist workstation". Commented Oct 7, 2023 at 0:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .