I don't understand why Western Design Center made the 65816 a 16-bit upgrade to the 6502 but Commodore Semiconductor Group/MOS Technology didn't make their own variant & why neither company made 32-bit or 64-bit versions of the architecture.
Also I don't understand why Motorola switched over to PowerPC architecture instead of developing a 64-bit variant of the 68000 architecture or why they never made more powerful 32-bit processors after the 68040.
The premise in the question is incorrect. There were such chips. The question also fails to allow for the way that the silicon-chip industry developed.
Moore's Law basically said that every 18 months, it was possible to build chips with twice as many transistors for the same amount of money.
The 6502 (1975) is a mid-1970s design. In the '70s it cost a lot to use even thousands of transistors; the 6502 succeeded partly because it was very small and simple and didn't use many, compared to more complex rivals such as the Z80 and 6809.
The 68000 (1979) was also from the same decade. It became affordable in the early 1980s (e.g. Apple Lisa) and slightly more so by 1984 (Apple Macintosh). However, note that Motorola also offered a version with an 8-bit external bus, the 68008, as used in the Sinclair QL. This reduced performance, but it was worth it for cheaper computers because it was so expensive to have a 16-bit chipset and 16-bit memory.
Note that just 4 years separates the 6502 and 68000. That's how much progress was being made then.
The 65C816 was a (partially) 16-bit successor to the 6502. Note that WDC also designed a 32-bit successor, the 65C832. Here is a datasheet: https://downloads.reactivemicro.com/Electronics/CPU/WDC%2065C832%20Datasheet.pdf
However, this was never produced. As a 16-bit extension to an 8-bit design, the 65C816 was compromised and slower than pure 16-bit designs. A 32-bit design would have been even more compromised.
Note, this is also why Acorn succeeded with the ARM processor: its clean 32-bit-only design was more efficient than Motorola's combination 16/32-bit design, which was partly inspired by the DEC PDP-11 minicomputer. Acorn evaluated the 68000, 65C816 (which it used in the rare Acorn Communicator), NatSemi 32016, Intel 80186 and other chips and found them wanting. Part of the brilliance of the Acorn design was that it used slow DRAM effectively and did not need elaborate caching or expensive high-speed RAM, resulting in affordable home computers that were nearly 10x faster than rival 68000 machines. (The best layman's explanation of this I've seen is the Ultimate Acorn Archimedes Talk at the Chaos Computer Congress 36C3.)
The 68000 was 16-bit externally but 32-bit internally: that is why the Atari machine that used it was called the ST, short for "sixteen/thirty-two".
The first fully-32 bit 680x0 chip was the 68020 (1984). It was faster but did not offer a lot of new capabilities, and its successor the 68030 was more successful, partly because it integrated a memory management unit. Compare with the Intel 80386DX (1985), which did much the same: 32-bit bus, integral MMU.
The 80386DX struggled in the market because of the expense of making 32-bit motherboards with 32-bit wide RAM, so was succeeded by the 80386SX (1988), the same 32-bit core but with a half-width (16-bit) external bus. This is the same design principle as the 68008. Motorola's equivalent was the 68EC020, as used in the Amiga 1200.
The reason was that around the end of the 1980s, when these devices came out, 16MB of memory was a huge amount and very expensive. There was no need for mass-market chips to address 4GB of RAM — that would have cost hundreds of thousands of £/$ at the time. Their 32-bit cores were for performance, not capacity.
The 68030 was followed by the 68040 (1990), just as the 80386 was followed by the 80486 (1989). Both also integrated floating-point coprocessors into the main CPU die. The progress of Moore's Law had now made this affordable.
The line ended with the 68060 (1994), but still 32-bit — but again like Intel's 80586 family, now called "Pentium" because they could't trademark numbers — both have Level 1 cache on the CPU die.
The reason was because at this time, fabricating large chips with millions of transistors was still expensive, and these chips could still address more RAM than was remotely affordable to fit into a personal computer.
So the priority at the time was to find way to spend a limited transistor budget on making faster chips: 8-bit → 16-bit → 32-bit → integrate MMU → integrate FPU → integrate L1 cache → integrate L2 cache
This line of development somewhat ran out of steam by the mid-1990s. This is why there was no successor to the 68060.
Most of the industry switched to the path Acorn had started a decade earlier: dispensing with backwards compatibility with now-compromised 1970s designs and starting afresh with a stripped-down, simpler, reduced design — Reduced Instruction Set Computing (RISC).
ARM chips supported several OSes: RISC OS, Unix, Psion EPOC (later renamed Symbian), Apple NewtonOS, etc. Motorola's supported more: LisaOS, classic MacOS, Xenix, ST TOS, AmigaDOS, multiple Unixes, etc.
No single one was dominant.
Intel was constrained by the success of Microsoft's MS-DOS/Windows family, which sold far more than all the other x86 OSes put together. So backwards-compatibility was more important for Intel than for Acorn or Motorola.
Intel had tried several other CPU architectures: iAPX-432, i860, i960 and later Itanium. All failed in the general-purpose market.
Thus, Intel was forced to to find a way to make x86 quicker. It did this by breaking down x86 instructions into RISC-like "micro operations", re-sequencing them for faster execution, running them on a RISC-like core, and then reassembling the results into x86 afterwards. First on the Pentium Pro, which only did this efficiently for x86-32 instructions, when many people were still running Windows 95/98, an OS composed of a lot of x86-16 code and which ran a lot of x86-16 apps. The Pentium Pro also had 8KB of onboard L1.
Then with the Pentium II, an improved Pentium Pro with L2 cache (first on a separate die, later integrated) and improved x86-16 optimisation — but also around the time that the PC market moved to Windows XP, a fully x86-32 OS.
In other words, even by the turn of the century, the software was still moving to 32-bit and the limits of 32-bit operation (chiefly, 4GB RAM) were still largely theoretical. So, the effort went into making faster chips with the existing transistor budget.
Only by the middle of the first decade of the 21st century did 4GB become a bottleneck, leading to the conditions for AMD to create a 64-bit extension to x86.
The reasons that 64-bit happened did not apply in the 1990s (EDIT: OK, except in high-end RISC chips for workstations -- between 1991 - 1994, all the main RISC processors went 64-bit: MIPS, SPARC and finally IBM POWER. DEC's Alpha chips were 64-bit from the start in 1992 and were arguably the only fully-native 64-bit mass-market CPU.)
From the 1970s to about 2005, 32 bits were more than enough, and CPU makers worked on spending the transistor budgets on integrating more go-faster parts into CPUs. Eventually, this strategy ran out, when CPUs included the integer core, a floating-point core, a memory management unit, a tiny amount of L1 cache and a larger amount of slower L2 cache.
Then, there was only 1 way to go: integrate a second CPU onto the chip. Firstly as a separate CPU die, then as dual-core dies. Luckily, by this time, NT had replaced Win9x, and NT and Unix could both support symmetrical multiprocessing.
So, dual-core chips, then quadruple-core chips. After that, a single user on a desktop or laptop gets little more benefit. There are many CPUs with more cores but they are almost exclusively used in servers.
Secondly, the CPU industry was now reaching limits of how fast silicon chips can run, and how much heat they emit when doing so. The megahertz race ended.
So the emphases changed, to two new ones, as the limiting factors became:
These last two things are two sides of the same coin, which is why I said two not three.
Koomey's Law has replaced Moore's Law.
I think Alpha was 1992 and SPARC v9 1994. (I can't quickly find when MIPS went 64-bit.) It took a while after that for them to become affordable. They weren't competing in the same market at all.
– Liam Proven Oct 30 '20 at 21:19http://wilsonminesco.com/links.html
There are more here, too: http://forum.6502.org/viewtopic.php?f=1&t=4216
I even got a comment from Bill Mensch himself!
– Liam Proven Oct 31 '20 at 22:01Pentium Pro had Level 2 cache 256K or even 512K of 2nd level cache at full CPU speed on package. Pentium II had the Level II at only half the clock speed.
– Patrick Schlüter
Nov 03 '20 at 13:24
The 65816 was close to the bare minimum of a 16 bit processor. It was primarily used where compatibility with existing 6502 code was needed, such as with the Apple IIgs. It was also used where the designers of a new 16-bit system were already familiar with 6502. This is probably why the SNES has the 65816, given the NES had the 6502.
By the time the 32 bit era came into its own, the 8-bit 6502 codebase was very obsolete. Apple never developed a successor to the IIgs and there were few if any other consumer computers using the 65816. Given that most programming had shifted from assembly to high level languages, designers would have also felt more free to switch architectures. I suspect there was no real target market for this processor, so it was not developed.
Regarding the 68000, that is part of a much larger industry switch away from the CISC (complex instruction set computer) architectures of the 70s and 80s to RISC (reduced instruction set computers) which offered superior performance.
In my view, it's more of the exception that the PC family did not migrate to RISC as well. The need to maintain compatibility with an extraordinarily diverse set of hardware and the need for binary compatibility (with multiple operating systems) created a unique pressure to maintain the architecture. For vendors like Apple, with a closed system and control over the software stack and hardware, something like the PowerPC transition was much easier to pull off. Same for the UNIX world, where most software was in C and readily recompiled.
So once RISC chips offered better performance, many of the vendors using the 68000 started to abandon it. Motorola could probably have pursued the same CISC-to-RISC translation approach used in the Pentium Pro, but they already had their own RISC designs that were faster than any 68000, and with a shrinking 68000 market segment. They probably saw no market for a "68080".
I don't understand why western design centre made the 65816 a 16bit upgrade to the 6502 but commodore semiconductor group/MOS technology didn't make their own variant
For one, the 65816 is only a 16 bit CPU in a very restricted way. All external transfers are still 8 bit wide and address expansion is rather clumsy. The main improvement wider architectures offer is plain management of large address space. As a result the 65816's performance isn't much higher than a plain 6502. Improved performance comes mainly from increased clock speed.
& why neither company made 32bit or 64bit versions of the architecture.
32 or 64 bit do not increase much performance on their own - and not much without new software. Performance gain comes from wider buses and most importantly a larger usable address space. The 8088 is a great example. Performance wise, a 4.77 MHz 8088 doesn't deliver notably more processing punch than a 1 MHz 6502 - but the ability to address up to 1 MiB without much hassle (*1) made a huge difference.
Any 65xx extension to 32 bit would have been essentially a complete new CPU, maybe offering some emulation mode, which wouldn't carry over the many advantages of the 6502, being dead simple and cheap to produce. Chip technology had advanced by several magnitudes between the mid 1970s when the 6502 was done and mid 1980s, making more complex but also more powerful CPUs taking up that niche.
Also I don't understand why Motorola switched over to powerPC architecture instead of developing a 64bit variant of the 68000 or architecture or why they never made more powerful 32bit processors after the 68040
For one, there was of course the 68060, which was at the time comparable to a Pentium, delivering up to 3 times the throughput of an 68040.
More importantly, in the mid 1990s (the '060 came in 1994) the usage of non-x86 CPUs in (consumer) desktops was history. Amiga and Atari were gone, Sun had already switched to SPARC. There was simply no way that Motorola as a single designer could compete with close to a dozen different companies designing x86 CPUs and pushing performance limits at an unimaginable speed.
At the time (early 1990s), Motorola investing in two different and incompatible CPU lines, 68k and PowerPC, for the same market (high performance) doesn't make much business sense, so joining forces with IBM and focusing on PowerPC (*2) was the sensible way to go.
*1 - No, segment registers aren't a hassle - in fact, they are a huge performance boost, comparable to the gain ZP addressing has on the 6502. Especially not when considering what effort 8-bit machines, such as the Apple II, required to manage larger data sets.
*2 - In turn Motorola not only reduced the 68k development effort, but also scrapped their beautiful new 88k RISC line.
Because binary compatibility in most cases is overrated and not worth compromising a design to maintain.
The only reason to extend a chip family like that is to maintain binary compatibility. In contrast, "reinventing the wheel" with a new design empowers the designers embrace everything the field has gained over time.
If anything, Intel is the exception to that, putting a lot of work in to ensure its chips are compatible, but nobody else was in the position Intel to really need to maintain that. (That said, Intel certainly innovated the underlying processor design while still maintaining compatibility.)
Apple felt they needed that when they worked with WDC for the 65816 in order to leverage the Apple II market, but that ended up being a dead end compared to the path of the Macintosh, which is a great example of how binary compatibility isn't necessary for a successful platform.
Apple switched over to the PPC because it was a better chip in terms of power and performance than what the 68K line was, important for their laptop series, and clearly IBM/Motorola felt that they could do better (for assorted values of "better") investing in the Power architecture than sticking with the 68K family.
Similarly, they switched to Intel because PPC was not advancing more on the power/performance spectrum since PPC was being more deigned to the server market.
The IBM PC helped establish that the industry was able to easily move from one architecture to another by establishing a "CP/M like" environment that was ostensibly "source code" compatible with the legacy CP/M base. Software vendors readily adopted the PC. The early PC was, essentially, a "better" CP/M platform with better, standard hardware, a better OS (MS/PC-DOS), and more memory. This made legacy code easy to port, even at machine language.
But by them, the modern machines were powerful enough to be efficiently coded in high level languages which were more readily ported. The UNIX market demonstrated that hardware manufacturers that adopted UNIX could rapidly see vendors support their platform, regardless of the underlying architecture. 68000, PPC, PA-RISC, 88000, x86, SPARC, single processors, multi processors, etc. etc. etc. The UNIX server and workstation market was incredibly diverse, yet the overlying UNIX OS allowed vendors to quickly move their software from platform to platform.
This diversity and rapid expansion allowed companies to truly innovate at all levels, rather than be trapped with 15 year old design decisions of 5 generations of technology.
To add to the other answers, the 65xx family design, with just a few on-chip registers, made sense when transistors were expensive, and memory accesses were cheap. That allowed using the zero page as, essentially, a large and flexible register set. A quick look at the WDC 65C832 datasheet reveals that it sticks to that philosophy, presumably because the instruction encoding doesn't have room for addressing a lot more registers.
However, this approach stopped working as clock speeds advanced, because memory access times didn't increase as fast as clock speeds. That makes more registers, capable of being used flexibly, very valuable for saving memory accesses, and the 65xx approach of a few registers, all with specific jobs, became a major handicap.
The x86 family had more registers than the 65xx, and managed to maintain competitive performance via complex and hard-to-design cache systems. Until quite recently, Intel were the world experts at running processor fabrication plants. They've lost that position to TSMC at present, but their abilities in manufacturing were important to keeping x86 competitive.
WDC has always been a small operation, did not have the manpower to design high-end cache systems, and could not rely on Intel-level manufacturing.
I found this quotation of an RISC-based supercharged 6502 interesting and may clarify to some extent this question and its comments on the relation of RISC and 6502.
A RISC based implementation of the Apple II 6502 Processor: In mid ’85 I performed an analysis that showed a simple RISC style implementation of a 16‐bit binary compatible superset of the 8‐bit microprocessor used in the Apple II 6502, along with some judicious use of on‐chip caching, could substantially improve performance – to the point of potentially outperforming the 68000 used in the Mac, and given the simplicity of the 6502 the implementation was “doable” by a small team. This was a more direct approach than emulating 6502 compiled binaries by a different processor as was done some four years later in the Mobius project in the Advanced Technology Group (ATG). I set about completing a feasibility study that went through several revisions (Turbo‐I and Turbo‐II), which included a complete micro‐architecture design of the processor along with resource usage diagrams for every clock phase of every instruction. When the design seemed solid and I was ready to move on to an implementation, I sought the counsel and the support of my mentors in the IC Technology group (to whom I owe a huge debt of gratitude), Bob Bailey and Walt Peschke. As usual, when they felt it was time to impart some wisdom upon me, they said, “Pete, lets go for a walk”. As we walked around the local residential neighborhood in Cupertino they explained to me that marketing/sales/biz dev would have no idea what to do (how to position, etc) with such a thing and I would just end up with a black eye. Of course they were right and I stopped working on it. Their warnings were prescient, as four years later Jean-Louis Gassee was to shut down a similar project called Mobius in the Advanced Technology Group (ATG) where the ARM microprocessor was used to emulate another architecture. .
Source: https://www.byrdsight.com/apple-macintosh/
YCombinator:
https://news.ycombinator.com/item?id=18807490
https://news.ycombinator.com/item?id=27843189
Some dedicated Amiga fans have produced a new-generation 68000-family processor, in FPGA form. The Apollo Core 68080 seems to be considerably faster than the 68060, and has some 64-bit instructions, although it is limited to 32-bit addressing.