Ghidra: There is no way to select the Motorola 6809 from the Import/Language dialog, but there is 6809 support in the code for the 6805

[hippietrail]

Describe the bug
The "Select Language and Compiler Specification" dialog lists the 6805 but not the 6809, but the source code directory for the 6805 support includes 6809 support.

To Reproduce
Steps to reproduce the behavior:

1. Go to the 'File' menu
2. Click on 'Import File...'
3. Select any random binary file, one with 6909 code if you have one
4. Make sure "Format" is set to "Raw Binary"
5. Click on "Language/..."
6. "6809" is not listed
7. Look in the Ghidra source on GitHub at the folder ghidra/Ghidra/Processors/6805/data/languages/
8. Note the existence of these files:

6809.cspec | Support Motorola M6809 | 7 months ago
6809.pspec | Support Motorola M6809 | 7 months ago
6809.slaspec | GT-3483: fixed sleigh error in 6x09 language spec. | 5 months ago

1. Note that these files have been present since November 2019

 
Expected behavior
"6809" should be listed as an option right after "6805"

Screenshots

Attachments
If applicable, please attach any files that caused problems or log files generated by the software.

Environment (please complete the following information):

• OS: Windows 10 Pro Education, version 1903
• Java Version: 12.0.2
• Ghidra Version: 9.1.2

Additional context
I also tried using the 6809 in Loader module code, which resulted in this stack trace:

Error importing file: Donkey King (1982)(Microdeal)[!][Black].cas
ghidra.program.model.lang.LanguageNotFoundException: Language not found for '6809:BE:16:default'
at ghidra.program.util.DefaultLanguageService.getLanguage(DefaultLanguageService.java:109)
at ghidra.app.util.opinion.AbstractLibrarySupportLoader.doLoad(AbstractLibrarySupportLoader.java:332)
at ghidra.app.util.opinion.AbstractLibrarySupportLoader.loadProgram(AbstractLibrarySupportLoader.java:83)
at ghidra.app.util.opinion.AbstractProgramLoader.load(AbstractProgramLoader.java:112)
at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:401)
at ghidra.plugin.importer.ImporterDialog.lambda$okCallback$7(ImporterDialog.java:351)
at ghidra.util.task.TaskLauncher$1.run(TaskLauncher.java:90)
at ghidra.util.task.Task.monitoredRun(Task.java:126)
at ghidra.util.task.TaskRunner.lambda$startTaskThread$1(TaskRunner.java:94)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)

---

Build Date: 2020-Feb-12 1149 EST
Ghidra Version: 9.1.2
Java Home: C:\Users\User\tools\jdk\jdk-12.0.2
JVM Version: Oracle Corporation 12.0.2
OS: Windows 10 10.0 amd64
Workstation: HP-ProBook-430-G2

[mumbel]

6809 is not in 9.1.2. You should be fine copying the 6805 directory out of master into your install, or building from master.

[hippietrail]

@mumbel Ah yes that worked. I see the 6809 support isn't complete. For instance I'm seeing STD ,X++ when it should be std $81,x for ED 81 etc (according to another 6809 disassembler at least). I'm assuming this is known and doesn't require reporting issues?

[copsNroppers]

Hi, I'd be curious to know what other disassembler you were using to disassemble that. The Motorola 6809 datasheet I have shows that 0xED is the opcode for an indexed STD, and that a postbyte of 0x81 (being 0b10000001 in binary for reference) does indicate a non-indirect double increment of register 00, which is X. As far as I can tell, STD ,X++ should be correct.

[hippietrail]

Ah that's good to hear. I did try to verify but found that I'm not great at reading CPU datasheets and I'm too unfamiliar with 6809. It's a little Python disassembler called "udis": https://github.com/jefftranter/udis

[copsNroppers]

I took a look, and it looks like they haven't finished their indexed addressing modes, so they're using that output as a placeholder. I think Ghidra's output is right (at least in that case).