Assembler (Motorola 6809)

Assembler (Motorola 6809) is the assembly language of the MC6809, the last and most elaborate of Motorola’s 8-bit microprocessors, introduced in 1978. It is an unusual entry in this encyclopedia because its designers wrote down, at length and in public, exactly what they were trying to do. Terry Ritter and Joel Boney published a three-part account of the design in BYTE across January, February and March 1979 under the title “A Microprocessor for the Revolution: The 6809”, opening with the claim that they were describing “the best 8 bit machine so far made by human.” The language that resulted is the most orthogonal and the most programmer-oriented 8-bit assembly language of its generation — and the processor sold badly, for reasons that had nothing to do with the instruction set.

History and Origins

An interim part, deliberately chosen

By the mid-1970s Motorola’s 6800 was losing ground. Chuck Peddle and others had left to build the far cheaper MOS 6502, and Motorola’s own forward-looking effort was MACSS, the project that emerged as the 16/32-bit 68000. When Motorola polled its existing 6800 customers, the answer came back that many were not willing to pay 16-bit prices for 8-bit jobs. That produced a decision to build one more 8-bit part — a substantially improved 6800 rather than a new architecture.

Ritter and Boney describe taking a specification to roughly thirty customers, including some “known to be hostile to the 6800”, with two questions. Should the new part be 8-bit or 16-bit? And did compatibility with the 6800 have to hold at the object-code level or only at the source level? The answers shaped the language directly. Customers accepted 8 bits provided the common 16-bit operations — add, subtract, load, store, compare, multiply — were present. And “virtually every customer indicated that source compatibility was sufficient”, because nobody intended to plug 6800 ROMs into 6809 systems.

That is why the 6809 is a source-compatible successor and not a binary-compatible one. A 6800 program is moved forward by reassembling it, not by running it. Motorola’s own programming manual is careful about how strong that guarantee is: 6800 assembly source “may be assembled using the Motorola MC6809 Macro Assembler”, and the resulting code, “while not as compact as native M6809 code, is, in most cases, 100% functional.”

Measured, not guessed

The design was driven by static analysis of existing 6800 code — Table 1 of the BYTE series reports a count over 25,000 lines of 6800 source. Loads and stores together came to 38.7% of the instructions counted, while adds and subtracts were only 2.8% — but a large fraction of those loads and stores were paired with adds and subtracts, which is to say they were 16-bit arithmetic done by hand. The 6809 therefore got genuine 16-bit load, store, add, subtract and compare. Increments and decrements were 6.1% of the same count, but they clustered inside loops, so the answer was not more INC/DEC instructions but autoincrement and autodecrement addressing modes that make the pointer update disappear into the memory reference.

The building-block plan that did not happen

The other governing goal was position independence. Motorola’s market was embedded systems assembled from pre-written routines, and combining hand-written assembly modules normally meant editing addresses. The plan was a market in licensable ROM building blocks — floating point, graphics, compression — that a system integrator would simply combine and burn. Almost every distinctive feature of 6809 assembly exists to serve that plan.

The market never appeared. Motorola’s only released example was the MC6839 floating-point ROM, and the industry solved the problem instead with relocating linkers and loaders. But the features survived the plan that motivated them, and the multitasking operating systems they enabled — OS-9, TSC’s UniFlex — are what the 6809 is actually remembered for.

The Language

Programming model

The 6809’s programmer-visible state is five 16-bit registers and four 8-bit ones:

The two-stack arrangement is the feature the operating systems were built on. A routine in ROM can be entered with its caller’s data on U, do its own work on S, and return without the caller’s stack having been disturbed. Ritter and Boney were explicit that the goal was reentrancy and recursion, and that both mattered for “easy implementation of block structured high level languages”.

DP supplies the high byte of every direct-mode address, so the fast 8-bit addressing form can be pointed anywhere in the 64 KB map rather than being stuck in page zero as it is on the 6502 and the 6800. It is fast and compact — and it is also the classic 6809 bug, because a routine that assumes a DP value someone else changed will read and write the wrong page silently.

Orthogonality as an explicit goal

The 6800’s instruction count went down, from 72 opcodes to 59, while the number of distinct instruction/addressing-mode combinations rose from 197 to 1464 — figures Motorola prints in the MC6809 datasheet. Operations that had been separate instructions became addressing modes on other instructions.

The designers defended this directly:

We do not feel a processor with 500 different assembler mnemonics for instructions is better than one with 59 powerful instructions that operate on different data in the same manner.

Their example is TFR R1,R2, one transfer instruction with 42 valid register pairings, replacing a family of TAB, TBA, TAP mnemonics; EXG uses identical syntax and has 21 valid forms. As they put it: “In the time it took to read three sentences you just learned 63 new 6809 instructions!” The same instinct produced ANDCC and ORCC in place of individual set/clear-flag instructions, and PSHS/PULS/PSHU/PULU, which take a register list and push or pull any subset of the machine state in one instruction.

The designers’ summary of the aim was blunter than most architecture documents get: “It is easier to write good programs on the 6809 than bad ones!”

Addressing modes

The addressing modes are where the language really differs from its contemporaries. Motorola’s datasheet lists ten, and the indexed family alone covers:

• constant offsets of 0, 5, 8 or 16 bits from X, Y, U, S or PC
• accumulator offsets — A, B or D used as a signed index, computed at run time
• autoincrement/autodecrement by 1 or 2, pre-decrement or post-increment, which is exactly the stack discipline generalised to any pointer register
• indirection layered on top of most of the above, plus extended indirect
• program-counter relative, for data as well as branches

That last one is the position-independence mechanism. LDA MSG,PCR assembles the difference between the label and the instruction, so the reference survives relocation. Combined with long relative branches (LBRA, LBSR, and 16-bit conditional branches reaching the whole ±32 KB span), it means a well-written 6809 module can be loaded anywhere without a linker touching it. Motorola’s manual states the property plainly: position-independent code “means that the same machine language code can be placed anywhere in memory and still function correctly.”

New instructions

The 6809 did not add many instructions, and said so. The ones it did add are pointed:

Opcodes are organised in three pages: most instructions are a single byte, with a $10 prefix for the second page (CMPD immediate is $1083) and $11 for the third (CMPU immediate is $1183). LBRA and LBSR were deliberately kept on page one to save a byte each.

An assembler that knew about the old machine

One neat consequence of the source-compatibility decision landed in the assembler rather than the silicon. Some 6800 instructions were dropped in favour of two-instruction 6809 sequences — and, Ritter and Boney write, “these sequences are generated automatically by our assembler when the 6800 mnemonic is recognized.” The assembler, not the CPU, is where the last of the 6800 compatibility lives.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

* Position-independent string compare, 6809 style.
* Entry: X -> input string, Y -> buffer, A = input length.
* Uses U for the caller's data, S for our own linkage.

CMPSTR  PSHS    A,B,X,Y         save exactly what we touch, one instruction
        TFR     A,B             length into the loop counter
LOOP    LDA     ,X+             post-increment: fetch and advance in one mode
        CMPA    ,Y+
        BNE     NOMATCH
        DECB
        BNE     LOOP
        LEAX    MSG,PCR         PC-relative: survives relocation of this module
        ORCC    #$01            set carry to signal "found"
        PULS    A,B,X,Y,PC      restore and return in one instruction
NOMATCH ANDCC   #$FE            clear carry
        PULS    A,B,X,Y,PC

MSG     FCC     /MATCHED/
        FCB     $04

Note PULS ...,PC as the return: pulling the program counter off the hardware stack is the return instruction, which is the kind of thing the register-list design makes natural.

Market Reception

The 6809 was expensive to build and expensive to buy. It took roughly 9,000 transistors against about 4,100 for the 6800 and 3,500 for the 6502, and that showed up at the counter: Ancrona’s advertisement in the April 1981 Radio-Electronics (page 111) lists mail-order single-unit prices of $36.50 for an MC6809P, $8.95 for a Z-80 CPU and $6.40 for a P6502 — roughly six times the price of a 6502 for the Motorola part.

The performance advantage was real but not proportionate to the price. In the assembly-language Sieve of Eratosthenes results collected in BYTE by Jim Gilbreath (September 1981) and by Jim and Gary Gilbreath (January 1983) — ten iterations of the sieve over an 8,190-entry flag array, with the per-machine assembly versions contributed by readers rather than written by one author — a 2 MHz 6809 completed the run in about 5.1 seconds, against 13.9 seconds for a 1 MHz 6502 and 6.8 seconds for a 4 MHz Z80: better work per clock cycle than either. But an 8 MHz 8086 came in near 1.9 seconds and an 8 MHz 68000 near 0.49. These are single-benchmark figures from period magazine testing, on differing implementations, memory systems and hand-written code, and should be read as an indication of rough standing rather than a controlled comparison.

The timing was also bad. The 8086 arrived the same year, the 8088 the next, and Motorola’s own 68000 in 1979. Motorola soon signalled that its future 8-bit products would be cut-down 68000s rather than improved 6809s. A beautifully designed 8-bit assembly language arrived just as the industry stopped caring about 8-bit assembly languages.

The 6309 Dialect

Hitachi’s 6309, with preliminary data in its 1985 data book, was sold as a CMOS low-power 6809 and is fully 6809-compatible in its emulation mode. It also contained a native mode with extra registers (E and F, concatenating into a 16-bit W, which joins D to form the 32-bit Q; a V transfer register; a zero register; a mode register MD) and new instructions — hardware division, 32-bit arithmetic, block transfers, bit manipulation — none of which Hitachi documented.

The April 1988 issue of the Japanese magazine Oh! FM published the first description of these capabilities, and Hirotsugu Kakugawa’s memo to comp.sys.m6809 in early 1992 spread them to the English-speaking world. The result is a second, reverse-engineered dialect of the language. NitrOS-9 is the best-known project to exploit it, and modern assemblers including lwasm and asm6809 support 6309 mnemonics alongside 6809 ones.

Current Relevance

The language is listed as historical because no new commercial system is designed around it, but it remains unusually live for a 1978 8-bit assembly language:

• The toolchain is maintained. LWTOOLS reached 4.25 on 18 July 2026 and asm6809 2.17 on 15 June 2025 — both cross-assemblers actively released in the last two years, supporting macros, conditional assembly, linking and both 6809 and 6309 targets. Pierre Sarrazin’s CMOC compiles a large subset of C to 6809 assembly for the CoCo, Dragon, Vectrex, Thomson machines, OS-9 and FLEX.
• The community produces new code. The CoCo, Dragon and Vectrex scenes all still ship assembly-language software, and NitrOS-9 continues as a 6309-aware descendant of OS-9.
• The hardware has not entirely vanished. Rochester Electronics catalogues MC6809 devices as a continuing source for the original NMOS part, and FPGA implementations — John Kent’s HDL core among them — run 6809 code, reportedly at clock rates the 1978 silicon never reached, though published speed ratings for those cores are not well sourced.
• The documentation is complete and free. Motorola’s programming manual, the datasheets, and the Ritter and Boney BYTE series are all scanned and readable, which is why the 6809 remains a popular architecture for people learning assembly language from primary sources.

Why It Matters

The 6809’s assembly language is the strongest 8-bit answer to a question most 8-bit architectures never asked: what should an instruction set look like if the people using it are going to write large, modular, relocatable programs by hand?

Every characteristic feature follows from that question. Program-counter-relative addressing for data, so a module can be moved. A second stack, so a library routine can keep its own state without disturbing its caller’s. A movable direct page, so the fast addressing mode is not a scarce global resource. Register-list push and pull, so saving and restoring context is one instruction instead of six. Orthogonal TFR, EXG and LEA, so the programmer learns a rule rather than a table. Motorola even shipped the demonstration — the full source of the ASSIST09 monitor, printed in the programming manual as a model of how the style was supposed to work.

The business case behind all of it collapsed. The ROM building-block market never materialised, linkers solved the relocation problem in software, the part cost six times what a 6502 cost, and 16-bit processors arrived the same year. But the features found a different use than the one intended: they made it possible to run a genuinely multitasking, multi-user operating system in 64 KB without memory-management hardware, which is what OS-9 did and what nothing else in the 8-bit world managed as well. For an architecture designed to be interim, that is a reasonable legacy — and the assembly language it defined is still the one people reach for when they want to show what 8-bit assembly programming could have looked like if orthogonality had been affordable.