12

When reading about the history of the 6502 CPU, it is regularly pointed out that Chuck Peddle had previously worked on the MC6800 CPU at Motorola. As well, it is stated that the goal when creating the chip was to produce a cheaper alternative to the 6800, and that was achieved when you compare that the 6800 cost $300 versus the 6502's $20 introductory price. On further reading, there are also mentions of the rare 6501 chip which was actually pin compatible with the 6800 and thus presumably could be a drop-in replacement, though not binary compatible.

So the question is how similar were the two competing microprocessors? Was the performance the same? How [dis]similar were the instruction sets? As well, could a 6501 be dropped into a 6800 socket and work with an existing motherboard despite not being binary compatible?

8
  • 3
    Well, wasn't the whole point of the 6500 to build a broadly comparable CPU as the 6800 at a lower price point due to using a simplified structure?
    – Raffzahn
    Commented Sep 25 at 17:11
  • 3
    In early 1978 I built an 8 track mag tape reader using a 1 MHz (4 MHz clock) MC6802. To get the read loop fast enough it had to be pulled out of the loop by timer interrupt after "more time than a block read would take" had elapsed. I pushed the data onto the stack. (Loop on no flag | If flag read data, push, loop). It worked superbly. Just. If anything had added anything to that read loop it could not have been done. (Others in our organisation had tried and failed :-) ). If a 6502 had as much as blinked it could not have done it (assuming equal basic cycle time in each case). Commented Sep 26 at 14:16
  • @RussellMcMahon: IMHO, the 6502 could have been made much more suitable for many I/O tasks if it had been designed so that all opcodes where the bottom two bits were 11 would behave as "branch if a 'branch enable' input is asserted at the midpoint of the next cycle, or alternatively if the function could be chosen by two wires among (1) single-byte NOP, (2) two-byte NOP; (3) two-byte branch taken; (3) perform effective address fetch but ignore result. External hardware could then add up to 64 new instructions to perform greatly accelerated I/O.
    – supercat
    Commented Sep 26 at 16:58
  • @Russell If speed was such a problem, I would have put slightly different versions of the same loop into the ROM and used an address input of the ROM to switch between routines directly with the I/O signal.
    – Janka
    Commented Sep 26 at 17:29
  • 1
    @supercat ... The billing tapes were sent to a mainframe about 400 miles away for processing but results were not available for some days so any customer queries soon after calls could not be answered. There were enough of these to make it worthwhile. || NZ Post Office (now Telecom NZ) Commented Sep 28 at 10:14

6 Answers 6

18

The 6500 is based on 6800 but cut down on everywhere when possible.

They both are 8-bit micros and they tend to be pretty similar. 8-bit data bus, mostly 16-bit address bus for addressing 64 kilobytes, and no separate IO space, everything is memory mapped.

The 6800 has two 8-bit accumulator registers A and B, sometimes used together as a 16-bit register D. It also has a single 16-bit index register IX or X and a 16-bit stack pointer.

The 6500 has only one 8-bit accumulator, two index registers X and Y but they are both 8-bit registers, and a 8-bit stack pointer.

Both CPUs have addressing mode to access the first 256 bytes (zero page) of RAM directly with a single address byte, faster than when providing two bytes for full 16-bit addressing.

As the 6500 has no 16-bit index registers, there needs to be an addressing mode which points into first 256 bytes from where to fetch a two-byte 16-bit address.

So that typically means that operations on 6500 take more opcodes and memory accesses to perform same as the 6800 and are thus slower, even if the opcodes to load or store or manipulate data are rather similar like on any 8-bit CPU.

So the use of zero page is mandatory on 6500, and on 6500 the stack must exist on the next 256 bytes, i.e. page 1, as the stack pointer high byte is always fixed to 0x01.

Which means that to replace the 6800 with the plug-in compatible 6501 version, the hardware must have some amount of RAM implemented on first 512 bytes for zero page variables and stack, or it has no way of working. For example, Atari 2600 puts 128 bytes of RAM and it can be accessed both from as zero page at addresses 0x0080 to 0x00ff and as stack page addesses 0x0180 to 0x01ff.

The 6800 system can have RAM anywhere as the variables can be stored anywhere and the stack too, so use of zero page and RAM at beginning is not mandatory. Many systems however do start RAM at 0x0000.

They both boot from the end of memory space so in both systems there would be ROM at 0xfff0..0xffff area for reset and interrupt vectors.

5
  • 2
    Given that the Atari 2600, one of the most successful 6502 based machines, has only 128 bytes of RAM (conveniently mapped into both page 0 and page 1), I'd challenge the notion that any 6502 based design has to have 512 bytes of RAM in pages 0 and 1.
    – TeaRex
    Commented Sep 25 at 22:21
  • 3
    @TeaRex Please note I never said there must be 512 bytes of RAM, just that there must be some RAM implemented within the first 512 bytes in a way that allows the system to work. The Atari 2600 method of mapping 128 bytes so that the 6507 can use it both as stack and zero page variables is sufficient. I will rephrase it better.
    – Justme
    Commented Sep 25 at 22:30
  • 1
    Since we fell into opinionated discussions anyway, I'd like to note that "6500 take more opcodes and memory accesses to perform same" is not necessarily true. 6502 has two index registers thus is able to work with two different indexed objects in memory simultaneously, while 6800 would have to constantly swap X register in and out between pointers. More, using (ZP),Y addressing mode and with "structure of arrays" approach, it is possible to work simultaneously with many fields of the object indexed by Y.
    – lvd
    Commented Sep 26 at 10:52
  • @TeaRex, the Atari 2600 uses partial decoding so that the same physical 128 bytes of RAM show up simultaneously at addresses 0x0080-0x00ff and 0x0180-0x01ff
    – Mark
    Commented Sep 26 at 23:17
  • @lvd: My BTP2 ("Beter Than Pitfall II") music driver uses (ZP),y addressing with 20 different zero-page pointers every four scan lines (during which music driver code will execute for 184 cycles and other code can execute for 120 cycles). During each scan line, pointers will have four different offset values added to them.
    – supercat
    Commented Sep 27 at 16:44
13

Its a matter of opinion, but in mine, from a programmer's perspective they're actually quite different. They're both 8-bit "accumulator" microprocessors, but that's about the entire overlap.

  • 6800 has two 8-bit accumulators (so more like registers), while 6502 has one (true accumulator)
  • 6800 has one 16 bit index register, while 6502 has 2 8-bit index registers
  • 6800 is big-endian, while 6502 is little endian
  • 6800 has a 16-bit stack pointer, while 6502 has an 8-bit one.
  • 6502 has these double-indirect zero-page addressing modes (so the instruction has an address in zero page, which is fetched to get the address to fetch the actual operand from)

The last in particular makes programming the 6502 very different from programming the 6800

3
  • Also Isn't that the CMP operands are backwards? For instance carry is inverted when comparing both registers. There's also this borrow SBC instruction which uses inverted carry. Commented Sep 28 at 17:50
  • If 6502 only has 8 bit registers then how can it have endianess? We only say that 6800 and the like have big endian due to the order it forms 16 bit index registers out of 2 accumulators. The amount of actual 16 bit instructions are limited to dealing with addresses.
    – Lundin
    Commented Oct 14 at 13:13
  • 1
    @Lundin: On the 6502, 16-bit values (addresses) are pushed on the stack for JSR/RET, embedded in instructions, and held in a pair of addresses for the zero-page indirect instructions. In all those cases, they are little-endian.
    – Chris Dodd
    Commented Oct 14 at 20:35
10

I would think any answer to this question will be, as lvd already noted, quite tied to the use case looked upon if not highly opinionated anyway. So I would like to underline the questions made with some general facts(*1), anyone can use to check the opinionated parts.


So the question is how similar were the two competing microprocessors?

Well, both are

  • Accumulator based designs (like most others of the time),
  • Offer a rich range of addressing modes (including indexing),
  • Use memory mapped I/O,
  • Use similar clock per instruction,
  • Operate on a similar bus design,
  • Using a similar memory access cycle,
  • Available in similar speed grades

Was the performance the same?

CPU's with the same basic design, similar memory access cycle and similar cycles per instruction usually end at the same over all speed range. No matter if 6500, 6800 or others like the 2650 (*2).

How [dis]similar were the instruction sets?

Usually an Assembly programmer of one would be able to get familiar with the other within hours, as they are both memory dependent accumulator machines. Including the same basic instruction set using the same or quite close mnemonics.

The only notable difference are complex addressing modes which are handled different - and a few 16 bit instructions the 6800 offered. Nothing really hard to come by.

Where the 6800 is more of a straight school book CPU, the 6500 shows traits of optimization toward embedded use. Thus being less great to code for more dynamic tasks. But again, not a major difference for real world usage.

As well, could a 6501 be dropped into a 6800 socket and work with an existing motherboard despite not being binary compatible?

That was what it was meant for: a 100% compatible drop in replacement due using the same bus interface - only different software.

This is further supported by both using the same basic memory layout of RAM (and IO) at bottom and ROM at top of the address space. So unless the 'motherboard' is was a very special (and very early) embedded design (*3), chances are good. Even more if we, as motherboard suggests, talk about a more generic, PC like design.


*1 - It does not make any sense at all to compare on an instruction base or instruction sequences, as any noted difference will depend on the task to be performed and the selection used. Like having a multiply instruction may be yield superior local performance but not really matter over all.

*2 - Not to mention that for most part CPU speed was (and still is) memory dependent, so any CPU using a certain speed grade of memory will yield broadly the same real world performance, including complete different architectures - that is unless a lot of additional logic is thrown at, allowing very complex instructions.

*3 - Something one would have used an 6801 or 6802 anyway. They use a different pinout/bus interface, with no direct replacement offered by MOS.

8

Every attempt to answer to "how similar" or "was the performance the same" would either be opinionated or (for the last one) depend on specific case.

However, the last question has definite answer: yes, it could, at is was built that way exactly. 6501 was designed to work in any existing 6800 installation, provided the ROM has new, 6502-compatible binary.

7
  • 2
    I would not be so sure about 6500 working in any existing 6800 installation, it will not work if there is no RAM at 0x0100..0x01ff for 6500 stack. And would be difficult if there is no RAM for zero page.
    – Justme
    Commented Sep 25 at 17:22
  • @Justme The same is true for the 6800, which called the area at $0000 direct page. And while it is possible to have only those 256 bytes populated, it's rather unlikely that a design with more than 256 bytes RAM would not offer such at $01xx, as continuous RAM is usually the lesser effort. Both CPU are made to have it's RAM starting at bottom and ROM at top.
    – Raffzahn
    Commented Sep 25 at 17:45
  • @Raffzahn: In a system with 512 or more bytes of RAM, mapping the entire address range from $0-$1FF to RAM would generally be easier than doing anything else, but that doesn't imply that it's more useful. For many tasks, having 128 bytes of zero-page RAM along with 128 bytes of I/O registers may be more useful than having 256 bytes of zero-page RAM.
    – supercat
    Commented Sep 25 at 19:45
  • 2
    @Justme "it will not work if there is no RAM at 0x0100..0x01ff for 6500 stack" Of course it WILL work, only some facilities as calling subroutines or returning from interrupts will be inaccessible. For no RAM in 0000..00FF there will be no sane indirect addr modes, but those could be emulated with self-modifying code in the accessble RAM.
    – lvd
    Commented Sep 26 at 10:40
  • In early 1978 I built an 8 track mag tape reader using a 1 MHz (4 MHz clock) MC6802. To get the read loop fast enough it had to be pulled out of the loop by timer interrupt after "more time than a block read would take" had elapsed. I pushed the data onto the stack. (Loop on no flag | If flag read data, push, loop). It worked superbly. Just. If anything had added anything to that read loop it could not have been done. (Others in our organisation had tried and failed :-) ). If a 6502 had as much as blinked it could not have done it (assuming equal basic cycle time in each case). Commented Sep 26 at 14:14
7

The MC6800 had a dual phase clock with tight requirements (both timing and voltage swing) that required a tricky design and decent test equipment to verify. They later came out with the MC6875 clock driver chip. The MCU was introduced at something like $395 USD, if memory serves. The clock driver chip was also not cheap. For example, a clock driver design from this source:

enter image description here

Kind of a wonky design that depends on gate delays for timing.

The 6502 was introduced at a (relative) bargain $25 USD and worked with a crystal or single phase clock. The main enhancement that I recall was the two index registers that made a lot of assembly language routines much more elegant.

My impression at the time, right or wrong, was that the 6502 architectural decisions were pragmatic based on actual programming patterns, and the MC6800 ones were more ideologically driven.

enter image description here

13
  • 1
    The clock part is not entirely true. the 6502 uses as well a two phase clock - but unlike the 6800 a clock generator was build in, so a single clock input was turned into two non overlapping clocks (Phi1/Phi2) - also outputted so peripherals needing either could be attached. But yeah, you're right about the school book like structure of the 6800 vs. a more specific, optimized of the 6500.
    – Raffzahn
    Commented Sep 26 at 14:57
  • 1
    Interesting it says the 6800 can access '65K bytes'. I'm assuming that was a marketing error?
    – bjb
    Commented Sep 26 at 15:52
  • 3
    @bjb 2^16 = 65,536. I don't think we widely used the K = 1024 k = 1000 convention in the seventies. Or am I missing something? Commented Sep 26 at 16:20
  • 2
    @bjb Well, 65K was a common - including the usual wrongful capitalisation of k in US material - after all, its sixtyfivethousandsomething. Beside that the craze of trying to invent K as 1024 hadn't cought on at the time, marketing was always more interested in being able to use the higher number of two available. Writing "65K Bytes" was rather the norm, no matter if Motorola, MOS, Intel (p.3.8) or others. Also, the issue only arises past ~32 Ki.
    – Raffzahn
    Commented Sep 27 at 12:33
  • 1
    @supercat As already mentioned (read again), that pseudo convention only emerged later on. Also, the above examples pretty clear show the use of upper case K for 1000. otherwise 65K wouldn't make any sense, or would it?
    – Raffzahn
    Commented Sep 27 at 17:22
5

While the 6800 and the 6502 are quite similar at a basic technology level, their different levels of commercial success suggest that the better-optimised ISA of the 6502 was an advantage.

The 6800 is history, as is the 6809. The 68000 survives in modified form as an embedded processor. That was always the 6502's target market, and it's still alive there. Western Design Center claim that hundreds of millions are still produced annually, embedded in SoCs as a simple and cheap CPU that's good enough for many jobs.

That success is a testament to the power of pricing, a much-neglected part of marketing a product, and the benefits of focussing on and developing a product as technology advances.

As well as that, its widespread use as a home computer CPU in the seventies and early eighties helped. That meant there were a lot of people who knew its assembly language. Its primary qualification for home computers was its low price, but its ease of interfacing, simple bus cycle and effectiveness at running interpreters definitely helped.

1
  • 6800 evolved into very similar ISA such as 68HC11 and 68HC08 which had very big market shares during the 1980s - 2000s and are still manufactured to this day as well. Motorola had close to monopoly on the whole car industry during the transition to microcontrollers in the 1990s, with Hitachi being pretty much the only considered competitor. So it is dubious to say that 6502 is more commercially successful.
    – Lundin
    Commented Oct 14 at 13:26

You must log in to answer this question.

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