The 6809 has 59 instructions, as compared with 78 on the 6800. So far as I can see, the 6809 lacks instructions that the 6800 has, such as aba, eorb and the transfer instructions (tba, tap and the like).

Still, Wikipedia claims:

The 6809 is assembler source-compatible with the 6800, though the 6800 has 78 instructions to the 6809's 59. Some instructions were replaced by more general ones which the assembler translated into equivalent operations and some were even replaced by addressing modes.

I can imagine that an assembler might have replaced the instructions I mentioned by a code-sequence that involved a temporary memory location. But this would have sacrificed some compatibility with programs that happen to use the same location.

How was source-compatibility with the 6800 achieved?

(An aside, that's not really part of the question, but if you feel like elaborating on this in your answer, if you know how useful this feature was For example, how compatible was it really? Were any software titles known to have been built for both processors? etc. etc.)

  • 1
    "an assembler might have replaced the instructions I mentioned by a code-sequence that involved a temporary memory location" I don't see any reason to think that that's the case. There are a lot of ways of changing the instruction set, and "assembling" for the new one that don't involve temporary memory locations. Commented Feb 28, 2020 at 14:06
  • 1
    it heavily depends on the assembler. If the assembler doesn't support the replacement, then it's not source-level compatible. I suppose that there weren't so many assemblers that could assemble 6809 code. Commented Feb 28, 2020 at 14:08
  • The 6809 has eorb, so that one is easy. aba (add b to a) is a good question as the only adds listed on the datasheet are both described as "add memory to accumulator" (with or without carry).
    – Tommy
    Commented Feb 28, 2020 at 15:09
  • You might also find useful my discussion of source code compatibility between 8080 and 8086, and how that might be used and/or useful, in this answer. While the details are of course entirely different, many of the concepts and reasoning for having only source code compatibility are the same.
    – cjs
    Commented Feb 29, 2020 at 4:23

2 Answers 2


So far as I can see, the 6809 lacks instructions that the 6800 has, such as aba, eorb

ABA becomes PSHS B; ADDA ,S+ - a nifty use of the autoincrement feature.

It shows as well were the temporary byte location comes from. Stack relative addressing, as well as indexing was one of the main features of the 6809. In fact, looking at his changes it got much in common with the 8086 as being developed with HLL constructs in mind (*1).

EORB is still the same on a '09.

the transfer instructions (tba, tap and the like).

The 6809 uses a unified instruction, 'TFR' so

`TBA` becomes `TFR B,A` (1F 98)
`TAP` becomes `TFR A,CC` (1F 8A)

and so on. Here's a full table taken from a Motorola manual:

6800     6809 Replacement
ABA      PSHS B; ADDA ,S +
CBA      PSHS B; CMPA ,S +
DES      LEAS -1,5
DEX      LEAX -1 ,X
INS      LEAS 1.-S
INX      LEAX 1.X
SEC      ORCC #$01
SEI      ORCC #$10
SEV      ORCC #$02
TAB      TFR  A,B; TST  A
TAP      TFR  A,CC
TBA      TFR  B,A; TST  A
TPA      TFR  CC,A
TSX      TFR  S,X
TXS      TFR  X,S
WAI      CWAI #$FF

(hope I didn't add any typo or screw replacements)

For example, how compatible was it really?

Even with this source code replacements, some incompatibilities exist:

The 6809 as designed is reasonably compatible with the 6800, but with the added features some inconsistencies must exist. Mostly around stack and flags:

  • Stack order for Interrupt/SWI differ (IIRC A and B is swapped)

  • 6809 SP point to the last entry, while 6800 points to the next

  • 6809 adds E/F flag to the flag register where 6800 has fixed values of 11

  • TST does not affect C

  • Shifts do not affect V

Like with any automatic translation, the result should be put thru the same test bed as the original was.

Were any software titles known to have been built for both processors?

Like with many questions, it is important that the view of some users/gamers/hackers greatly differ from what chip makers have in mind when doing them. (Home-) Computers are just a tiny little fraction of their market. Not really important to design CPUs for it. Embedded has always been king and might hold this at least for all foreseeable future.

Take for example the beloved 6502. The number of desktop machines is puny compared to embedded application. There may have been some 30-40 million units used in computers (*2) but they represent less than a percent of the 5-10 billion units claimed on the WDC website. The situation can be considered the same for basically all other microprocessors as well.

Chip manufacturers care for their important market, and "software titles" are not what embedded systems run. Here also CPU generations don't get swapped by chance and at random points, but only when a new or updated device is made. This almost always include a redesign of the software, as it's about new features. Usually such a redesign needs a more powerful CPU or other new feature and engineers will go shopping for the best chip to perform, only held back by their penny counting department. And that's where (semi) automatic source conversion comes into play - they are sales tools to convince buyers that they get the power of a new chip but may save great on software development as much of the old program can be reused. A wet dream for management always wanting to get a grip on those strange guys in engineering and development :))

*1 - If they only had added a way to address more memory - like due segmentation - today's PCs might be 6809 based ... well, somewhere way deep down beneath many layers of later extensions :))

*2 - ca. 12.5 M C64, 6.5 M Apple II and let all other come double this

  • The Flex OS was built for both and it doesn't appear the 6809 one was rewritten merely tweaked up from the 6800
    – Alan Cox
    Commented Mar 6, 2023 at 20:45

You answered your own question, the 6809 assembler would take the 6800 instructions and replace them with a code fragment that generates the same result. As for interfering with other programs, that would be somewhat unlikely. The computers I used in that era typically ran only one piece of user code at a time. In addition, the memory limits of the day would tend to require every program to start at the same memory address. Going beyond your question, it would generally not be good coding practice to hard code addresses into your software. You would use the label feature in the assembler so that code changes would adapt. This would resemble the use of line numbers in older BASIC interpreters, and the recommendation to number lines by 10's.

You must log in to answer this question.

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