So far as I can see, the 6809 lacks instructions that the 6800 has, such as aba, eorb
PSHS B; ADDA ,S+ - a nifty use of the autoincrement feature.
It shows as well were the temporary byte location comes from. After all, 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 beeing 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
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
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 addes E/F flag to the lag 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