42

Quite a few successful early microcomputers used the MOS 6502 CPU. This included, but was not limited to, systems like the Apple I, Apple II, Commodore PET, and Ataris. A followup known as the MOS 6510 was used as the main CPU for the Commodore 64 (the floppy disk drive used its own 6502), and variants of these were used in many other systems of the time.

But why? What made the 6502 the CPU of choice for so many different computer designs over several years? (The Apple I was introduced in 1976, and the C-64 was introduced in 1982, which conservatively gives a time period of at least five years. I also suspect that the Apple I wasn't the first system to use the 6502, though it might well have been one of the first that were widely available.)

For comparison, the Intel 8085 was introduced in 1975, and could run at up to 3-6 MHz, while the 6502 was introduced in the same year but could run only at up to 1-3 MHz, both depending on variant. The Intel 8086 came later, in 1978, and even the slow variants could run at up to 5 MHz; faster 8086 CPUs could be clocked at up to 10 MHz.

Was it an issue of cost? Availability? Simplicity of board design? Instruction set? Or what?

What do we know, and what can we deduce from available information? Bonus points for answers that include citations.

Cactus
  • 2,700
  • 14
  • 43
user
  • 5,286
  • 2
  • 26
  • 43
  • 14
    https://retrocomputing.stackexchange.com/questions/2760/how-much-did-the-6502-and-z80-cost gives a lot of of the answer: the 6502 was a third of the price of the Z80. – pndc May 14 '17 at 13:01
  • It had to be - It entered a market occupied by the Intel 8080 one year late. The Z80 improved the 8080 considerably and supposedly profited from Intel marketing - They probably charged more money because they could – tofro May 14 '17 at 13:21
  • 1
    @wilson I don't think so. Whether you have I/O circuitry listen to /RD and /WR only or /IORQ and the above as you do on a Z80 doesn't really make a difference - It's just one more logic gate. On the other hand, separating I/O from memory makes the memory map much cleaner. – tofro May 14 '17 at 19:05
  • 10
    You mention clock speed; the 6502 at 1-2MHz often outperformed higher-clocked contemporaries (I remember reading an article talking specifically about efficiency of handling interrupts as one of the reasons, can't find it at the moment) – Joe May 14 '17 at 19:38
  • Compared with the Intel and Zilog CPUs, the 6502 had a very simple architecture which was easy to understand (only 3 registers, plus the stack pointer and program counter) and ran fast (fewer clock cycles per instruction), so it naturally appealed to "minimalist" system designers and programmers. – alephzero May 15 '17 at 02:39
  • 15
    Clock speed probably isn't terribly relevant as the Z80 family takes 7 cycles for LD A,$34 but the 6502 takes 2 cycles for LDA #34. For clock comparisons I seem to recall that a figure of 3 times was used to compare 6502 with Z80 clock rates. Also the 6502 made it easy to use the other edge of the clock cycle to steal bus access for the video system as the Apple ][ did (and I think Atari did for spriteless video lines). To be honest I suspect cost was the major driver. – PeterI May 15 '17 at 09:54
  • 1
    I think it's possible to overestimate the technical factors; in addition to price it's strongly implied that MOS were strong on outreach — e.g. via the KIM-1, or Peddle himself out in the field doing technical support (such as the famous visit to Wozniak & Jobs). There's also a simple matter of momentum: the initial hit computer, the Apple 2, had a 6502. So after that, if you're looking for contractors to write the software you need to launch a new machine, which assembly language do they probably know? The Z80's co-dominance could similarly be viewed as momentum from the Altair. – Tommy May 15 '17 at 15:38
  • @PeterI it was always a factor of two such as I was aware. – Tommy May 15 '17 at 15:41
  • 5
    6502 is awesome. 'nuff said. – cbmeeks May 15 '17 at 18:47
  • 5
    @cbmeeks Care to post that as an answer, so the community can vote on it? ;-) – user May 15 '17 at 18:57
  • 1
    @MichaelKjörling I would...but some Z80 fanboys would just vote me down...then I'd have to make some Star Wars reference to fight back. – cbmeeks May 15 '17 at 18:58
  • 1
    I am Z80 fanboy and I will vote you UP! Because I'm also 6502 fanboy :) – lvd May 19 '17 at 05:36
  • 1
    All of these technical reasons are why WE would choose one or the other...but the real answer for business almost always comes down to cost. We can quote clock cycles and I/O mapping all day long but it really comes down to what can make the most profit. The 6502 was much cheaper. It's just fortunate for us that for once the cheaper CPU turned out to be one of the better ones for the market it targeted. – cbmeeks Aug 16 '17 at 15:42
  • 1
    read this, is awesome and all your questions will have an answer https://www.amazon.com/Edge-Spectacular-Rise-Fall-Commodore/dp/0973864907 :) – Mario Caronna Aug 17 '17 at 18:56
  • By 1980 I'm assuming (don't have data on bulk pricing for these chips) that the pricing had equalized. Sinclair launched the ZX80 that year at a $100 price point. I'm assuming that CBM stayed with 6502 for the C64 as they owned MOS and had the design experience. – Rich Mar 18 '20 at 01:25
  • We are colored today when looking back on the vast game catalogue of especially the C64, and the high degree of pirating. When introduced this was very different - home computers were often sold simply just to play with programming at home as very little software was available, and what was, was very expensive. Hence BASIC (which was what people expected to program in) and as low a price as possible. Hence the cheapest, widely available 8-bit CPU. – Thorbjørn Ravn Andersen Feb 21 '22 at 15:11
  • @PeterI CPU cycles are not useful for speed comparisons between significantly different architectures. The important thing is not how many cycles your CPU runs within a given memory cycle, but how much work it does. If a register load takes one microsecond at the fastest speed of a given memory device, you don't really care whether you run 2 or 6 cycles in that one microsecond. – cjs May 14 '23 at 02:50
  • But the biggest contribution to the Z80's speed was probably it's much larger register set (which allowed it to do fewer loads/stores than the 6502 for many operations) and the larger instruction set, allowing more compact (and thus faster) code. So even if you compared the wall-clock speed of LDA #12 to LD a,34 and found the 6502 to be faster, you also need to look at how often you need to do such register loads, which will usually be less often on a machine with more registers. – cjs May 14 '23 at 02:52

5 Answers5

53

First, for Commodore's part, it should be obvious the reason for choosing the 6502 microprocessor for all their 8-bit machines (notwithstanding the dual-processor SuperPet and C128) - Commodore owned MOS. Jack Tramiel was very focused on vertically integrating his manufacturing, which basically assured Commodore's use of MOS CPUs and support chips. Since Commodore sold more 8-bit home computers than any other vendor, this fact alone greatly influenced the 6502's preeminence.

Second, the aggressively low price point of the 6502. Chuck Peddle's team developed the 6502 to be a low-cost, compatible, Motorola 6800 "killer", much the same way as Zilog did in targeting the Intel 8080 with the Z80. Again, Jack Tramiel's willingness to far undercut his competition kept the 6502 as a relative bargain among the early 8-bit options. As noted in this question the 6502 was around 1/3 the cost of the Z80, and both were far cheaper than Motorola and Intel equivalents.

Third, MOS also created system support chips that were designed to easily interface with the 6502, such as the 6522 VIA. This made adding I/O capabilities very simple for system designers, and that freed them to focus more on custom circuitry that would help distinguish their system in the marketplace of many computers built around this basic chipset.

Fourth, the early success of the several 8-bit machines in both North America and Europe created a virtuous ecosystem of hardware designers and software programmers that knew how to work with the 6502. The momentum and professional user base made for a popular "platform" even before that term was widely used, and this reinforced vendors to stick with it as long as it remained technologically competitive with newer CPUs, and perhaps even longer. Indeed, the video game console industry shared in this platform ecosystem, and the 6502 dominated that category too. First in Atari consoles and then in the original NES, which used an ASIC version of the 6502 in the form of the Ricoh 2A03.

Fifth, the 6502 had robust industry support that delivered enhanced versions (65C02 CMOS version, 65C816 16-bit version), higher clock speeds (capping out at 14MHz), alternative chip manufacturing sources (Rockwell, Synertek), and licensing of the 6502 IP to create custom ASIC devices. In this sense, it was a precursor to what happened with the ARM platform in the embedded computer (phones, etc.) industry. These enhancements and licensing extended the lifespan of the platform, leading to its inclusion in many additional computer and console products.

If the KIM-1, released in 1976, and the Super NES (65c816 core), released in 1991, can serve as "bookends" for the 6502 platform dominant years, that represents a 15-year run in the home computer and console market. Of course, by 1991, the computing world was rapidly consolidating around the IBM PC "clone" standard, but the low-cost, high-volume, Super NES was capable of graphics, sound, and gaming abilities that exceeded much more expensive PCs. It was even competitive with newer 16-bit CPU systems more purpose-built for gaming, like the Amiga, Atari ST, and of course the 68000-based Sega Genesis. Even today, the 65C02 CPU continues to be manufactured and licensed (as a core CPU) for use in embedded systems.

Brian H
  • 60,767
  • 20
  • 200
  • 362
  • 2
    See Mitsubishi MELPS 740 series for descendents of the 6502. – amI Aug 25 '17 at 20:13
  • Actually the NES is not a good example here; it was practically unknown in Japan. It was used anyway because a) Ricoh lacked a manufacturing license for the far more popular Z80, and b) Yamauchi felt that using such a processor that nobody else used would give them a competitive advantage. (Altace, Nathan, I Am Error, pp. 14-15.) – cjs May 14 '23 at 02:26
  • Regarding point 3, the 6502 also had the advantage that it was explicitly designed to be compatible with 6800 peripherals. In fact, the 6520 was a copy of the earlier Motorola 6820/6281 PIA, and the 6522 (and the RIOT, RRIOT, 6526, and many others) all used that same core PIA functionality, working in the same way. – cjs May 14 '23 at 02:36
  • As for the Super NES's graphics and sound capabilities, that was nothing to do with the CPU and everything to do with the peripheral chips. You'll note that Nintendo also produced best-in-class graphics and sound capabilities for a handheld in the Game Boy, using very similar graphics and sound hardware, but a completely different CPU (one based on the Z80). – cjs May 14 '23 at 02:39
23

There were two major reasons:

1: On introduction, the 6502 (at $25) was considerably cheaper than its nearest competitors; at the time, those were the 6800 ($175) and the 8080 ($179); the Z80 would not be released until the following year, and even then its initial price was $200.

2: Despite its low cost and simplicity, the 6502 was relatively fast for a given clock speed and memory type. At the time, CPU speed was limited more by memory access constraints than anything else. The program code it needed was also acceptably compact for the time.

Chromatix
  • 16,791
  • 1
  • 49
  • 69
  • 8
    Nobody else seems to have mentioned it, but the price consideration counts doubly for Atari: the 28-pin 6507 significantly reduced board costs over a full 40 pins, encouraging their entry into MOS world. – Tommy Jun 29 '19 at 15:10
  • "Despite its low cost and simplicity". I think its simplicity actually contributed to its relative speed. – JeremyP Feb 23 '22 at 09:22
  • A low speed CPU also meant you could use low-speed memory, which added to the cost effectiveness. – Francis Pierot Apr 28 '22 at 07:59
  • 1
    IIRC the 6502 actually requires relatively fast memory compared to it's nominal clockspeed, because it does a memory access on every cycle. – Peter Green Sep 21 '22 at 16:27
  • 1
    @PeterGreen It does (same as the 68xx series, actually), but conversely you could say that Intel-type CPUs (eg. Z80) used more clock cycles than they needed per single memory access. For the same speed of memory, the 6502 tended to yield more practical performance than its competitors. Even more so, the 68xx/65xx bus was more conducive to multiplexing video output onto the same memory, another potential cost saving. Early Z80 machines either halted the CPU during video scanout or had a separate memory system to drive it. – Chromatix Sep 24 '22 at 12:07
  • The 6502’s alleged comparative speed depends on what you’re doing with it, of course. If there’s any sixteen-bit addressing involved then good luck to you. – Tommy Nov 27 '23 at 12:55
  • @Tommy The 6502 can do 16-bit pointer arithmetic just as fast as any other 16-bit arithmetic, which admittedly isn't terribly fast, but isn't excruciatingly slow either. For sequential accesses you can take advantage of the post-indexed indirect addressing mode to reduce the need to update the 16-bit base pointer. It is sometimes also possible to do speedup tricks with self-modifying code (ie. put the result of the pointer arithmetic directly in the load and store instructions, rather than in zero page). With practice, you learn how to get the best out of it. – Chromatix Nov 28 '23 at 14:12
  • @Chromatix I'm very familiar with the 6502; e.g. here's a perspective floor I implemented on the Atari Lynx which doesn't have rotation hardware. So there was quite a lot of 16-bit-address memory walking in that. From the other side of the fence here's isometric display code I wrote for the ZX Spectrum, which also has to walk a large memory area. From these experiences I am fully aware: the 6502 is behind its competitors for any data manipulation that you can't coerce into 256-byte tables. – Tommy Nov 28 '23 at 16:46
  • (... but, on the plus side, I guess it got a lot of people to have to think about data locality and optimal layout versus execution order well before we needed to start factoring caches and things like GPU swizzling into decisions) – Tommy Nov 28 '23 at 16:47
11

The fast "zero page" addressing mode of the 6502, allowing to think of the lowest 256 bytes as "registers", could have contributed to its popularity among programmers, prolonging the demand for 6502-based systems.

Quoting from Wikipedia:

Many instructions are coded differently for zero page and non-zero page addresses:

LDA $00            ; zero page
LDA $0000          ; non-zero page

The above two instructions both accomplish the same thing: they load the value of memory location $00 into the .A register (accumulator).

However, the first instruction is only two bytes long and requires three clock cycles to complete. The second instruction is three bytes in length and requires four clock cycles to execute. Obviously, the difference in execution time could significantly improve performance in repetitive code.

Using single-byte addresses for size-critical code could also somehow mitigate the difference in code density compared to Z80.

Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • This was a great feature. CBM BASIC gobbled up most of zero page for its own functions, but if you knew it well (Mapping the Vic and Mapping the C64 were a terrific help), you could make use of certain bytes when BASIC wasn't looking. They left you a couple or three user defined bytes. But of course if you were writing assembly, you could use nearly all of it. – Cliff Hall Jun 30 '19 at 23:22
  • 2
    More importantly, pairs of consecutive zero-page addresses could be used to hold memory addresses for use with (zp),y addressing mode, accomplishing an insane amount of work in a five-cycle instruction. A music player I did for the Atari 2600 required 46 cycles of every 76-cycle scan line to generate four-voice music, and within each group of four scan lines it used twenty different pointers all held in zero page (so 25 cycles out of each 46 were five-cycle instructions using (zp),y addressing). – supercat Feb 18 '22 at 22:50
  • 1
    The Motorola 6800 also had a zero page (which they called the "direct page"), and many instructions that saved a byte and a cycle by using it. As supercat mentions, the innovation the 6502 brought to this was indirection through the zero page, modified by the Y register, which consumed slightly fewer cycles and significantly less code than modifying the 6800's (16-bit) X register when you needed to alternate between using two or more pointers in a routine. (Unless you needed to work with more than 256 byte areas.) – cjs May 14 '23 at 02:30
9

An advantage of the 6502 which favors its usage in the Apple II series and Commodore VIC-20 and 64 (though not the Atari 400/800) is that it accesses memory on a very regular cycle--once every full clock cycle. This makes it very easy to split each clock cycle into two parts--one of which is given to the CPU and the other of which is given to video (and--for the Apple--DRAM refresh) circuitry. This makes it very easy for the CPU and video to use the same memory system, and also makes it possible for code to access memory that holds display data as quickly as it can access any other memory.

The Atari 400/800 use shared memory for CPU and video, but don't subdivide cycles. The CPU runs at 1.79Mhz [chroma/2] (vs. 1.022MHz [2*chroma/7] for the Apple II, VIC-20, and C64) but it has to stall the CPU every time it fetches data for the video subsystem. On the other hand, the earlier Atari 2600 used a 28-pin version of the 6502 (called the 6507) running at 1.19MHz [chroma/3] which benefited enormously from the zero-page addressing mode, and inertia would have encouraged use of the 6502 on the later 400/800. Since a memory bus speed of 1.19MHz would have been insufficient, it was boosted to 1.79Mhz.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • 2
    The Motorola 6800 also could be run in the same "split cycle" mode, using the first half of the cycle for video and the second for the CPU. The MC6800 also included a VMA (Valid Memory Address) pin that could allow cycles to be suppressed if not needed. At the time, the 6502 was much cheaper (at least to me) than the 6800. Was it also true that Bill's Tiny Basic ran on the 6502 but not the 6800? I remember modifying my 6800 home-brew to use a 6502 for a night to try it out. – cmm Apr 01 '19 at 22:35
  • Not only could the Motorola be run in the same alternating ϕ2/ϕ1 mode, but IIRC Motorola themselves suggested designs that did this in their application notes. In general, one must be careful to check that features of the 6502 aren't taken from the 6800, since, being designed to work with 6800 peripherals (and even replace a 6800!) it shares a lot of the 6800's bus and timing characteristics. – cjs May 14 '23 at 02:33
  • From what I understand, the 6800 would have been cost-prohibitive for personal computers at the time the 6502 came out, but if designs using the 6800 for interleaved-phase video were physically produced those would be interesting to see. One thing I've sometimes thought would have been a nice design feature for a CPU would be a couple of inputs that would force the CPU to process instructions normally, or "jam" an opcode to NOP, branch not taken, or branch taken. If one wanted e.g. a 60-column display, one could have a couple ranges of addresses which shadowed RAM, one of which would... – supercat May 15 '23 at 15:40
  • ...jam the opcode when bit 6 of the address was clear, and the other of which would jam it when it was set. Jumps to $8004, $9044, $8084, $90C4, etc. would clock out 60 characters and then start executing code again. – supercat May 15 '23 at 15:45
  • 1
    Oh and to make things more interesting on the Atari, besides video memory access, the ANTIC chip was also running a display list, running a simple program to control the graphics hardware. Usually just a simple one to keep the same graphics mode for the whole screen, but it (like the Amiga and Atari ST) could change graphics modes and get a new color pallete every couple of scan lines. – hwertz Nov 27 '23 at 07:41
  • @hwertz: Indeed. The display list is a very powerful concept, which lives on in the form of DMA lists in some microcontrollers' DMA controllers. – supercat Nov 27 '23 at 16:21
0

So as others have said, cost of the 6502 was a major factor. Why was it so inexpensive?

(Per Wikipedia) the CPU has 3,510 transistors. It's quite a RISC design, the actual instruction set is quite small. For instance, for math, you have (8-bit) add and subtract, 8-bit data (with an overflow flag so you know when you needed to "carry the one" as it were). The instruction set was spartan but instructions per clock was quite good for the time -- many instructions took 1 cycle whereas (for example) on the Z80 they typically took 4.

One noteable feature on the 6502, it has an 8-bit addressing mode so "page 0" (the first 256 bytes) can be accessed much faster than the rest of the system memory (64K, requiring a 16 bit address.)

Also, since humans use base-10, on the 6502 you set a decimal mode flag before you add or subtract, and it's using BCD (Binary Coded Decimal -- each byte holds 2 digits from 0-9 for a range of 0-99 rather than 2 hex digits for a range of 0-255.) (...Intel x86 also has BCD instructions, although x86-64 doesn't.)

hwertz
  • 219
  • 2
  • 2
  • 2
    No instruction in the 6502 takes 1 cycle. 2 cycles is the minimum. It's always at least fetch+execute. 65816 was the first in the family to have 1 cycle instructions. – Patrick Schlüter Nov 27 '23 at 10:51
  • … and for those single-byte instructions it fetches two, then throws one away. Even though it’ll always then be immediately reread as the next instruction. It’s not efficient so much as simple. Not that the single-byte instructions tend to crop up that much proportionally. – Tommy Nov 27 '23 at 12:53
  • Oh man that's funny. (Fetching two bytes and throwing one away.) I guess sacrifices must be made to keep the transistor count that low! It's amazing that a functional CPU, let alone one with (for the time) reasonable performance could be made with just 3510 transistors. I suppose it'd be hard to keep enough threads going to keep going, but it'd be kind of amusing to make a 6502 variant with 64-bit addressing, and throw like 10000 of them onto a CPU die. – hwertz Nov 28 '23 at 17:28