How did the 6809 achieve source-code compatibility with the 6800?

Question

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.)

Answer 1

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 +
CLC      ANDCC #$FE
CLI      ANDCC #$EF
CLV      ANDCC #$FD
CPX      CMPX P
DES      LEAS -1,5
DEX      LEAX -1 ,X
INS      LEAS 1.-S
INX      LEAX 1.X
LDAA     LDA
LDAB     LDB
ORAA     ORA
ORAB     ORB
PSHA     PSHS A
PSHB     PSHS B
PULA     PULS A
PULB     PULS B
SBA      PSHS B; SUBA ,S+
SEC      ORCC #$01
SEI      ORCC #$10
SEV      ORCC #$02
STAA     STA
STAB     STB
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

Answer 2

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.