6809 Instruction Set – Overview

Introduction

The Motorola MC6809 (1978) is the 8-bit processor of the Tandy Color Computer and the Dragon 32 and 64, the Vectrex, the Thomson MO5 and TO7, the Fujitsu FM-7 and many arcade boards (Williams, Konami, Namco). The Hitachi HD6309 is a pin-compatible CMOS version with a second register file, a 32-bit register Q, block moves, bit instructions and hardware multiply and divide that Hitachi never documented in its data sheets (see HD6309 additions). The 6809 is big-endian: a 16-bit operand or address is stored high byte first. The older 6800, 6801 and 6303 have their own page: the 6809 is source-compatible with them, not binary-compatible.

The explorer’s disassembler for these processors is explorer/cpu/m6809/ (our own code). Where it meets this code (a Color Computer machine-language file) every instruction carries one of these statuses, drawn in its own colour and also written as text:

• documented: in the MC6809 data sheet (or, with the HD6309 chosen, an HD6309 instruction that Hitachi’s documents list);
• illegal: an opcode, or an indexed postbyte, that the chip does not define. The MC6809 data sheet says nothing about what the chip does; the HD6309 traps through the vector at $FFF0. Shown as .byte, one byte long (or up to the postbyte for an undefined indexed form);
• reserved: a TFR or EXG with a register code the data sheet does not define, or with registers of different sizes.

Several opcodes that the 6809 leaves undefined do something on real chips (they were used by copy-protection and a few demos). They are shown as illegal here because none of them was found in a source we could read; this is one of the reasons the reference is rated partial.

Registers

Condition codes

The viewer lists the flags an instruction changes and the ones it reads. A flag the data sheet calls undefined after an instruction (H after NEG, ASL, SUB, SBC, CMP in 8 bits, V after DAA) is not listed as changed.

Addressing modes

Syntax choices in the explorer: Motorola writes a direct operand as $12 and an extended one as $1234; lwasm (LWTOOLS) writes <$12 and >$1234, which cannot be misread. PC-relative operands are written $2010,pcr in both. Flex and OS-9 assemblers use the Motorola mnemonics: they were not separately sourced. asl and lsl are the same opcode; the viewer writes asl.

The indexed postbyte

The byte after an indexed opcode. RR picks the register: 00 X, 01 Y, 10 U, 11 S. Bit 7 clear is a 5-bit signed offset; bit 7 set selects one of the forms below, and bit 4 set makes the form indirect (the computed address holds the 16-bit address to use). “Extra cycles” are added to the instruction’s base count; the second figure is for the indirect form.

xx means “any”: the register field is ignored by the PC-relative forms and, on the MC6809, by the extended indirect form ($9F $BF $DF $FF all mean the same). The explorer shows the PC-relative operand as the address it names, followed by ,pcr; the offset is measured from the end of the whole instruction. Every other postbyte of the MC6809 is undefined: the unused low nibbles 0111, 1010 and 1110, an indirect single increment or decrement ([,R+], [,-R]) and the extended form with bit 4 clear. They are shown as illegal, as many bytes long as the opcode and the postbyte.

On the HD6309 the unused low nibbles define extra forms, and the single increment and decrement indirect forms and the extended form with a register field become the W forms:

On the HD6309 the postbytes $92 $B2 $BF $D2 $DF $F2 $FF are undefined and trap. The cycle counts of the E, F, W and W-based forms are not given here (no source).

TFR and EXG register codes

The source is the high nibble, the destination the low nibble: tfr a,b is $1F $89. The 8-bit registers are A B CC DP (and E F); the others are 16-bit. The data sheet does not define a transfer between registers of different sizes, nor a code it leaves out: both are shown as reserved. On the HD6309 the codes C and D are a zero register: it reads as 0 and a write is discarded. EXG with PC as one side jumps; so does TFR to PC.

PSHS, PULS, PSHU and PULU masks

Registers are pushed from bit 7 down to bit 0 (PC first, at the highest address) and pulled in the opposite order. Cycles: 5 plus one for each byte moved. A PULS with bit 7 set returns, so the viewer marks it as a return.

The three opcode pages

An opcode is one byte. Two of the bytes, $10 and $11, are prefixes: the byte after them is an opcode of page 2 or page 3, which hold the long branches (LBHI…), CMPD, CMPY, LDY, STY, LDS, STS, CMPU, CMPS, SWI2, SWI3, and all the HD6309 additions. A prefix makes the length depend on the byte before it, so the explorer decodes an instruction at every byte and lays the results in columns (the way it does for x86 and 6502). A prefix not followed by a defined opcode is shown as one illegal byte, so the next byte is decoded as an instruction of its own. See the opcode maps.

Interrupt vectors

Timing

Cycle counts are the MC6809 data sheet’s (the number of E-clock cycles): the base count of the opcode plus the extra cycles of the indexed form, shown for the exact postbyte decoded. SYNC and CWAI wait for an interrupt (4+ and 20+). RTI takes 6, or 15 when the pulled E flag is set. A long conditional branch takes 5, or 6 when taken. The HD6309 in native mode is faster for many instructions; those counts are not tabulated here, and the HD6309’s own instructions have no cycle count in the viewer.

How this was checked

• Two published opcode tables written out separately and compared byte by byte with the decoder: the list of sbprojects.net’s 6309 opcode page (every MC6809 and HD6309 opcode, 436 opcodes, with the addressing mode and, by the rule of the data sheet, the length) and the Motorola opcode grid of the three pages. The decoder also has exactly 330 undefined opcodes on the HD6309, the figure given on the 6809Decoder wiki, with the seven undefined indexed postbytes it lists.
• Executing cores: every MC6809 opcode (pages 1 to 3) and every indexed postbyte it defines is run on two different cores (a core by Martin Maly and the JSVecX core) from random register and memory states, and the instruction length, the registers and flags that changed, whether data memory was read and written, the branch target and the cycle count are compared. The details and the places where a core is wrong are in the test notes.
• The debugger’s own decoder (emulators.org/debugger/src/cpus/m6809.js) gives the same length and mnemonic for every opcode and postbyte both define; it accepts a few postbytes the data sheet leaves undefined.

Sources

• MC6809-MC6809E Microprocessor Programming Manual, Appendix F (opcode map) – Motorola
• Hitachi 6309 opcodes and mnemonics – sbprojects.net
• Undocumented 6309 Behaviours – David Banks’ 6809Decoder

Not described

• What the MC6809 does with its undefined opcodes and postbytes (no source was read); the HD6309’s illegal-opcode trap sequence and the MD register’s bits.
• Which register receives the results of the HD6309 DIVD, DIVQ and MULD beyond the one-line summary, and the flags of the HD6309 register instructions, bit instructions and multiply and divide.
• The HD6309’s native-mode cycle counts, and the cycle counts of the HD6309 additions.
• Bus timing, interrupt sequencing, and the MC6809E’s differences (LIC, AVMA, BUSY pins).