I was notified you viewed the topic. Did you see the questions?
Hi Maël. Apologies, I’ve just had some personal distractions lately.
So roughly you could say processors from the MOS/WDC 65xx and Motorola 6800 family.
As a description for the plug-in itself, this is not really a description that is functionally all encompassing.
Yes, the 6502 / 65816 / 6809 could all trace their design ancestry back to the original Motorola 6800 design. However, the 6500, 6502, 6809 are all unique CPU architectures.
To put it another way, the disassembly plug-in is not limited to: “MC6800, MC6809, 6502 and related CPUs.” Therefore, this description of the plug-in does not encompass it’s generalised implementation that allows support for numerous CPU’s, simply with the addition of appropriate CPU definition text files (which can be contributed by anyone, without requiring any plug-in code changes).
As noted in my earlier post, I believe the disassembly plug-in is more accurately described as supporting: “
Retro 8 or 16-bit CPU architectures, that utilise no more than 2 Operands in any instruction.”
Although, I’d also note that in some cases
more than 2 Operands is actually supported. For example, Operands that reference a CPU register are defined as multiple individual instruction definitions (as with the 6809’s Indexed Addressing mode instruction definitions).
So the current 2 Operand restriction is in reality in reference to the Operand types that specify data, address, or offsets etc.
Regarding hexadecimal number formatting and naming of the styles
Yes, there are multiple hex formatting. The 4 you listed would appear to cover those that I’m familiar with.
Likewise you will see Assembly (and hex) presented in uppercase and lowercase.
I’m not aware of any case sensitivity in this area (unless a specific application's author has chosen to recognise only upper or lower case).
I think you will find that upper / lower case representation will typically align with the age of the CPU / code being published (or is simply the personal preference of the author).
Older systems, around the time of 6800 etc, were in some cases only interfaced with terminals that supported uppercase only. Or, certainly in the earlier days of bitmapped fonts and non-descender 5x7 (or 7x9) pixel based fonts, lowercase was not very legible, so uppercase Assembly code was the obvious choice!
So perhaps, as a subjective observation, you might find
old-school enthusiasts prefer uppercase Assembly, and those that weren't around in the early days might prefer lowercase?
For the disassembly plug-in’s current implementation, the upper / lower case, and the hex representation, is simply defined by the strings in the CPU definition file.
ie. If lowercase is someone’s preference, they could simply lowercase convert the CPU definition file! Also, the hex representation style (of the CPU being defined) is represented in the definition string.
how many leading zeros
Depending on the CPU, the number of leading zeros represented in the disassembly should be aligned with the instruction variant.
For example, an instruction may have alternate Opcodes for different Operand lengths.
eg. With the CPU’s I’ve produced definition files for so far, there can be different Opcode’s (for the same instruction), where the Operand may be 5-bits, 8-bits, 16-bits, or even 24-bits.
In each case it is appropriate to Disassemble the Operand to the specific number of bytes that aligns with the specific Opcode's Operand length (in this example: 1, 2, or 3 bytes).
Noting also, that an Assembler would typically be coded to be smart enough to assemble the appropriate instruction Opcode using the smallest required Operand size Opcode.
eg. If I assembly coded a Branch instruction with a specified offset of $0001 (in my source). When assembled, if a 5-bit offset Opcode was available, then that Opcode should be assembled (even though a 2 byte $0001 offset was specified), as using the 16-bit offset Operand instruction variant would be wasteful when a shorter and faster 5-bit offset Opcode was available for the instruction!
I’m not sure if the above observations cover what you intended to raise, but hopefully it is of some assistance?