Yes. A typo.
Question on Opcode behaviour
Re: Question on Opcode behaviour
$CD on a 6809 is XHCF. $CD on a 6309 is a LDQ Immediate. Mame has seperate debuggers for 6809 and 6309.robcfg wrote: ↑Thu May 01, 2025 11:29 am I've also noticed (by comparing my disassembly with MAME's) that I'm showing opcode 0xCD as LDQ Immediate (according to the instruction set) while MAME shows:Could it be that XHCF is used if its prefixed by $10 or $11?Code: Select all
31f0: cd XHCF
Re: Question on Opcode behaviour
On a 6809 $104a is a nonstandard version of DECA. $4a is officially undefined on opcode page 2.robcfg wrote: ↑Fri May 02, 2025 12:03 am I may have found another error in MAME's disassembler.
0x4A is DECA, but 0x104A is DECD instead.Code: Select all
0f5b: 10 4a DECA
On a 6309 $104a is DECD
Mame's debugger will show the correct disassembly depending on which CPU is active.
Re: Question on Opcode behaviour
I see, and now I understand better.
As the 6309 traps invalid opcodes/postbytes, those are only valid for the 6809. So, for example opcode $01 would be a variant of NEGA on the 6809, but on the 6309 that would be OIM.
How does the 6309 behave in 6809 emulation mode? Does it still trap the invalid opcodes or does it emulate them?
And I guess that code that starts in 6809 mode and can contain 6309 code if the processor is detected is basically impossible to disassemble correctly unless you could specify regions belonging to each processor, right?
Thanks for your kind help!
As the 6309 traps invalid opcodes/postbytes, those are only valid for the 6809. So, for example opcode $01 would be a variant of NEGA on the 6809, but on the 6309 that would be OIM.
How does the 6309 behave in 6809 emulation mode? Does it still trap the invalid opcodes or does it emulate them?
And I guess that code that starts in 6809 mode and can contain 6309 code if the processor is detected is basically impossible to disassemble correctly unless you could specify regions belonging to each processor, right?
Thanks for your kind help!
Re: Question on Opcode behaviour
All instructions work in all modes. Native mode saves some cycles and pushes more registers during IRQ handling.
Re: Question on Opcode behaviour
Yes, but opcode $01 means different things for 6809 and 6309, for example.
It's undefined on the 6809 and usually taken as NEGA but it's defined on the 6309 as OIM.
Not only we would need to show the different names of the Opcodes, but NEGA is Inherent (1 byte long) while OIM can be Direct, Indexed or Extended and taking at least 3 bytes, so the disassembly results could potentially vary wildly depending on which processor characteristics we're using.
Now that I think of it, if the 6309 uses $01 as OIM always, then many 6809-only programs would crash or malfunction, that's why I'd like to know what does the 6309 do in emulation mode. Not that I think many programs would abuse the undefined opcodes, but who knows...
It's undefined on the 6809 and usually taken as NEGA but it's defined on the 6309 as OIM.
Not only we would need to show the different names of the Opcodes, but NEGA is Inherent (1 byte long) while OIM can be Direct, Indexed or Extended and taking at least 3 bytes, so the disassembly results could potentially vary wildly depending on which processor characteristics we're using.
Now that I think of it, if the 6309 uses $01 as OIM always, then many 6809-only programs would crash or malfunction, that's why I'd like to know what does the 6309 do in emulation mode. Not that I think many programs would abuse the undefined opcodes, but who knows...
Re: Question on Opcode behaviour
Yeah, on a 6309 it would be OIM direct - whatever the mode. Plenty of stuff fails on 6309 despite what certain proselytisers might have you believe. Whether you consider the software at fault or the hardware for not implementing undocumented features is an ecumenical matter 

Re: Question on Opcode behaviour
Sooooo.... Imagine I were to add a disassembly view to my already feature packed DragonDOS tool
I guess I should go the 6809 route as that's the machine default processor, right?
The reason I ask also is because the MPAGD games our dear friend Pere is porting, do actually check for a 6309 processor and enter the native mode if found, but I don't know if beyond that, they use 6309 specific routines or not.
I think this thread has turned really interesting! Thank you for your insights!

I guess I should go the 6809 route as that's the machine default processor, right?
The reason I ask also is because the MPAGD games our dear friend Pere is porting, do actually check for a 6309 processor and enter the native mode if found, but I don't know if beyond that, they use 6309 specific routines or not.
I think this thread has turned really interesting! Thank you for your insights!
Re: Question on Opcode behaviour
Hi, Robertrobcfg wrote: ↑Fri May 02, 2025 7:06 pm Sooooo.... Imagine I were to add a disassembly view to my already feature packed DragonDOS tool![]()
I guess I should go the 6809 route as that's the machine default processor, right?
The reason I ask also is because the MPAGD games our dear friend Pere is porting, do actually check for a 6309 processor and enter the native mode if found, but I don't know if beyond that, they use 6309 specific routines or not.
I think this thread has turned really interesting! Thank you for your insights!
I could ask that question ...
If we are talking about the games for the MC6847, so Black and White, the engine checks for the presence of an HD6309 and if it exists it simply
will enter native mode but along the engine there is nothing 'special' for the 6309, I mean the new registers are not used nor are the new opcodes for that CPU.
But if we were talking about the AGD games for the Supersprite-FM+ module, then the engine checks for the presence of the HD6309 and if it is not
found, the game ends! These coloured games do require the HD6309 to be active in native mode because a lot of the new registers/opcodes have been used when needed.
cheers!
Re: Question on Opcode behaviour
That is some good info, thank you very much Pere!