Why write about the Motorola 6800 (pronounced ‘sixty-eight hundred’)? For the generation that grew up with home computers in the late 1970s, the 6800 was the 6502’s slightly boring uncle. It was used in ‘grown-up’ devices, like cash machines, but it was slower, more expensive and generally less interesting than the 6502.
In reality, the 6800 was a highly innovative design that, just as much as competing products from Intel, represented a major step forward in making computing widely accessible to all.
Intel would eventually ‘win’ in microprocessors with the x86 architecture, and winners write the history, but Motorola deserves just as much respect as an early pioneer. This is probably why the 6800 came top of our poll of which 8-bit design to write about.
The story of the 6800 is also a story of how a corporation can develop innovative technology with enormous potential, only to self-sabotage and hand the advantage to a competitor. We’ll see how this happened in Part 2 of the story of the 6800. We’ll also discover that, remarkably, almost 50 years after its launch you can still buy the 6800 today!
I vote for the 6809 as the top 8 bit cpu vs the z80,6502,1802. Those four chip designs are mature products not requiring multi-voltages or wierd clocks as the early cpu’s required and had
full 64kb addressing.
There was a few 16 bit cpu’s also in the same time frame 1975-1977 but they never had the marketing
as well as the 8 bitters.
Great Microprocessors of the Past and Present
I thought I recognised the image - it’s from visual6800! As noted in the article:
The layout of the 6800, with ROM at the top, registers and the arithmetic and logic unit at the bottom and control logic between the two can be seen in die shots and in the the ‘Visual 6800’ simulation, that shows how signals in the 6800 change as the 6800 runs
(I had something to do with the visual6800, which is one of the follow-ons to visual6502)
One paragraph of the article caught my eye, the part about the 6800 falling short of, loosely speaking, “DMA engine functionality” because it didn’t have two 16 bit index registers (1 for src, 1 for dest). I’m curious how much bigger a second index register and incrementer would have made the chip. Is there a 6800 die map somewhere to be found?
It is interesting that the 68000 moved to a “many uniform registers” architecture after the 6800’s “two accumulators plus index register” approach. The PDP-11 was certainly influential, whereas the 6800 was more of a minimum viable product. (oh so tempting to “throw in the kitchen sink,” but then you have more to design and test)
Oh, another patent. But no dimensions as such.
A 6809 gets you a few more registers, but the cost is you no longer have a a 8 bit opcode.
The 6800 suffered from production problems, 90% defective chips at the time so even having
a slighly bigger die would have made the cpu un produceable. The 6502 having a smaller
die had a better yeld, but still had to wait for new manufacturing process like 6800 to get low
cost chips.
The single index register was annoying for a few things (like memcpy) but you could and many people did use the stack pointer for the other one in performance critical code.
It was obviously not considered a huge issue because neither the 6803 nor 6303 added the second index register. It was only the last of the 6800 line proper - the 68HC11 - that finally introduced Y.
Instead the 6803 fixed the missing push and pop of X (strictly speaking you could pop X on a 6800 with TSX LDX ,X INS INS), added an 8bit unsigned add to X and a load of 16bit maths ops. The 8bit add to X fixes a load of high level language problems with 6800.
The 6303 did add XGDX (swap D (ie A:B) and X) but that is as much useful for maths on pointers and as you need A or B to hold data didn’t address the dual pointer weakness.
I actually prefer the 6303 to the 6809. The 09 code density is a bit better and it has all sorts of clever operations but the 6303 and 68HC11 get fairly close with a much simpler and cleaner instruction set.
That’s easily the best 6800 PULX I’ve seen … very suitable for in-lining. The ones with which I’m familiar turned it into a sluggish subroutine, with all the awkwardness of dancing around the return address. Do you have an equally clever PSHX?
Alas not. Fortunately I was able to build my C compiler to only ever pop x and never need to push a value as X.
Indeed, a very elegant solution to the missing POP X instruction on the 6800.
Tektronix solved similar issues when they introduced their 4051 Graphics Systems, it was BASIC based and ran on the Motorola MC6800.
Looking at the firmware, it turns out that the BASIC interpreter used the stack a lot for its operations, and the software engineers at Tektronix added six self-modifying routines that relied on the X Register to accomplish the following:
JMPX : JUMP INDIRECT TO THE ADDRESS POINTED TO BY [A+X]
*LDXX : LDX FROM ADDRESS [A,X]
*LDAX : LDAA FROM ADDRESS [A,X]
*LDBX : LDAB FROM ADDRESS [A,X]
*STAX : STAB AT ADDRESS [A,X]
*JMPAX : JUMP TO ADDRESS [A,X]
Each routine is prefixed by STAA *+4, which saves ACC A right after the indexed instruction, for example:
LDAX EQU *
STAA LDAX+4 *BDDF: B7 04 4F * LDAX : SELF MODIFYING CODE, LDAA FROM ADDRESS [A,X]
LDAA 00 ,X *BDE2: A6 00 * REPLACE '00' WITH OFFSET FROM ACC A
RTS *BDE4: 39
While this is a sample size of one, it would be interesting to compare how well these added "instructions" cover stack based operations that might benefit other languages like C and PASCAL.
For the 6800 C compiler I avoided self modifying code because that makes stuff like threading, exception handling or interrupts rather painful to do.
I don’t know how it tallies with other languages but C on 8/16bit generally wants to be able to
- get a fixed offset from the stack (usually word sized)
- get the address of an object at a fixed position on the stack
- get objects at a fixed position from an address in a register (usually a small value, often 0)
- put ditto.
(and ditto for fixed addresses but those usually are easy anyway)
The problems I hit with 6800 are thus mostly about code density and adjusting the stack frame rather than dynamic offsets from an object.
Density because it’s more expensive to do things byte wide, because you can’t ldx #n pshx to load a constant, pulx to dec sp by 2 in one byte and because the lack of stuff like abx makes moving the stack pointer more painful by far. Taking several bytes to pop x also has some effect because the compiler often needs to store D into the n,X
The store to a calculated address ends up messy because you have to
- calculate the address (in D)
- put the address somewhere (in practice the stack)
- calculate where it is going
- retrieve the stacked address without harming D
6800 is a bit worse for C than 8080 but not much. 8080 has better code density but almost everything stack related on the list that C compilers want is something the 8080 sucks at.
6803 fixed it with 16bit ops and ABX (and 6303 added xgdx which Motorola put into 68HC11). 8085 fixed it but in a register/register oriented manner with LDSI LHLX and friends. Z80 didn’t address it but Z280 sort of did, Rabbit sort of did but differently, and ez80 did sort of a bit like the rabbit but not quite.
There are things my current 6800 compiler (and 8080 one) don’t do that would help - in particular identifying stuff that could avoid 16bit operations. C promotes all char operations to integer (because PDP-11) but it does allow a compiler to do things entirely in 8bit if the result of the expression is the same that way for all cases
eg char n;char x = n + 12; could be done bytesized