Question on Opcode behaviour

Hardware Hacking, Programming and Game Solutions/Cheats
User avatar
tlindner
Posts: 7
Joined: Tue Jun 01, 2021 6:59 pm

Re: Question on Opcode behaviour

Post by tlindner »

robcfg wrote: Thu May 01, 2025 10:26 am I'm going through your table and noticed that postbyte $8A (F,X) is marked as having another byte following it, while $AA (F,Y) does not.
Is that an actual useless byte that only affects the ,X form or is it a typo in the table?
Yes. A typo.
User avatar
tlindner
Posts: 7
Joined: Tue Jun 01, 2021 6:59 pm

Re: Question on Opcode behaviour

Post by tlindner »

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:

Code: Select all

31f0: cd              XHCF
Could it be that XHCF is used if its prefixed by $10 or $11?
$CD on a 6809 is XHCF. $CD on a 6309 is a LDQ Immediate. Mame has seperate debuggers for 6809 and 6309.
User avatar
tlindner
Posts: 7
Joined: Tue Jun 01, 2021 6:59 pm

Re: Question on Opcode behaviour

Post by tlindner »

robcfg wrote: Fri May 02, 2025 12:03 am I may have found another error in MAME's disassembler.

Code: Select all

0f5b: 10 4a           DECA
0x4A is DECA, but 0x104A is DECD instead.
On a 6809 $104a is a nonstandard version of DECA. $4a is officially undefined on opcode page 2.
On a 6309 $104a is DECD

Mame's debugger will show the correct disassembly depending on which CPU is active.
User avatar
robcfg
Posts: 1633
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Question on Opcode behaviour

Post by robcfg »

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!
sixxie
Posts: 1425
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Question on Opcode behaviour

Post by sixxie »

All instructions work in all modes. Native mode saves some cycles and pushes more registers during IRQ handling.
User avatar
robcfg
Posts: 1633
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Question on Opcode behaviour

Post by robcfg »

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...
sixxie
Posts: 1425
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Question on Opcode behaviour

Post by sixxie »

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 :)
User avatar
robcfg
Posts: 1633
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Question on Opcode behaviour

Post by robcfg »

Sooooo.... Imagine I were to add a disassembly view to my already feature packed DragonDOS tool :P

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!
pser1
Posts: 1783
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Question on Opcode behaviour

Post by pser1 »

robcfg wrote: Fri May 02, 2025 7:06 pm Sooooo.... Imagine I were to add a disassembly view to my already feature packed DragonDOS tool :P
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!
Hi, Robert
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!
User avatar
robcfg
Posts: 1633
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Question on Opcode behaviour

Post by robcfg »

That is some good info, thank you very much Pere!
Post Reply