68000 module parses sign extended addresses incorrectly for move instructions

Describe the bug

Ghidra incorrectly disassembles certain move* 68000 instructions, specifically instructions where the addresses are sign extended.

For example, Ghidra disassembles the instruction below (from IDA output):

ROM:00001A56 11D8 FE80                                               move.b  (a0)+,(word_FFFE80).w

as

00001a56 11 d8 fe 80     move.b     (A0)+,(DAT_fffffe80).w

“The 68000 has a 24‑bit address space, allowing access to up to 16 MB of memory.” This differs from later 6800* variants that have 32-bit address buses

To Reproduce Steps to reproduce the behavior:

1. In a hex editor, create a binary with 11 d8 fe 80 and save it
2. Throw it into a ghidra project and select M6800 default for the processor
3. Go to byte zero and hit ‘D’

Expected behavior

Ghidra to display the instruction as:

00001a56 11 d8 fe 80     move.b     (A0)+,(DAT_fffe80).w

(24-bit addressing)

[zznop]

Thanks, but I’ll just keep using Binary Ninja. I just wanted to bring this to the attention of the devs. You are 100% correct in that move.b (%a0)+, (0xfffffe80), and move.b (%a0)+, (0xfffe80) assemble to the same opcode. But because Ghidra is more than just a disassembler (unlike capstone or objdump), it has to take in account processor behavior for things like xref’s, decompilation, type propagation, and more. I recommend one of two things:

1. Sleigh interface for MC68000 (this would be ideal, and probably wouldn’t be too much work considering the instruction set is already supported)
2. Remove 68000:BE:32:default from the processor list and add a MC68040 (in other words, don’t advertise native 68000 support)

I found this related issue: https://github.com/NationalSecurityAgency/ghidra/issues/230

[ggnkua]

Right, I see your point. As a workaround how about creating another ram segment from $ffff0000 to $ffffffff? If the code accesses the hardware registers consistantly (i.e. either $ffxxxx or $xxxx.w) then it won’t matter which bucket of RAM it ends up. Worst case you have to check in both memory areas for xrefs.