Signature byte: Difference between revisions
Rainwarrior (talk | contribs) (revising: trying not to privilege "two-byte instruction" as many (not some) assemblers do make BRK 1 byte, make it clear that COP as "co-processor" is not SNES-relevant, explain more about how BRK/COP interrupts may be handled) |
Rainwarrior (talk | contribs) (organize into sections, provide some practical specific information about interrupt/stack/etc.) |
||
| Line 8: | Line 8: | ||
For this reason, these instructions have been treated both as one-byte<ref>Eyes & Lichty</ref> and two-byte instructions in various reference documents and assemblers. | For this reason, these instructions have been treated both as one-byte<ref>Eyes & Lichty</ref> and two-byte instructions in various reference documents and assemblers. | ||
== BRK and COP == | |||
Both of these instructions generate a software interrupt that will be handled by a routine designated in the [[CPU vectors|CPU vector table]]. | |||
* <tt>COP</tt> has a vector at $FFF4. | |||
* <tt>BRK</tt> has a vector at $FFF6. | |||
Stack contents for handler: | |||
$00, S - (empty, current stack pointer) | |||
$01, S - P status byte | |||
$02, S - return address low (BRK/COP PC + 2) | |||
$03, S - return address high | |||
$04, S - return bank K | |||
There is no standard for how assemblers treat BRK or COP. If BRK emits only 1 byte, a signature byte can be added manually with a data byte following. | |||
* ca65 in .p816 mode has an optional signature for BRK, allowing either 1 or 2 bytes. COP and WDM always require the signature byte. | |||
The <tt>COP</tt> instruction was originally intended for use with a co-processor, for which the signature byte could indicate a command to send to the co-processor. However, there is no hardware to support this usage on the SNES, and it is simply a second software interrupt, equivalent to BRK. | |||
=== Without Signature === | |||
If the signature byte is not needed, a BRK or COP handler may wish to decrement the return address on the stack before <tt>RTI</tt>, returning as if it were a one-byte instruction. | |||
=== With Signature === | |||
A software response to <tt>BRK</tt> or <tt>COP</tt> may use the return address on the stack to deduce the location of the operand byte and inspect it. | A software response to <tt>BRK</tt> or <tt>COP</tt> may use the return address on the stack to deduce the location of the operand byte and inspect it. | ||
This might be used for error codes, or as a compact system call dispatch. | |||
== WDM == | |||
The <tt> | The <tt>WDM</tt> instruction was reserved for future use, but was ultimately left unused. It is simply a 2-byte alternative to <tt>NOP</tt>. | ||
Mesen's debugger provides a break-on-WDM instruction which can make it convenient as an emulator-only breakpoint. | |||
== Notes == | |||
Though the 65C816 has no unused opcodes, on the 6502 many were left open with unspecified behaviour. This allowed the use of "unofficial" illegal opcodes, including several <tt>NOP</tt> variants with an unused signature byte. See: [//www.nesdev.org/wiki/CPU_unofficial_opcodes NESDev: CPU unofficial opcodes] | * Though the 65C816 has no unused opcodes, on the 6502 many were left open with unspecified behaviour. This allowed the use of "unofficial" illegal opcodes, including several <tt>NOP</tt> variants with an unused signature byte. See: [//www.nesdev.org/wiki/CPU_unofficial_opcodes NESDev: CPU unofficial opcodes] | ||
== References == | == References == | ||
<References/> | <References/> | ||
Revision as of 22:02, 24 February 2023
In 65x parlance, a signature byte is the second byte that follows certain instructions, including:
- BRK
- COP
- WDM
Each of these instructions will normally advance the PC by two bytes, even though the hardware does not make any direct use of the second "operand" byte.
For this reason, these instructions have been treated both as one-byte[1] and two-byte instructions in various reference documents and assemblers.
BRK and COP
Both of these instructions generate a software interrupt that will be handled by a routine designated in the CPU vector table.
- COP has a vector at $FFF4.
- BRK has a vector at $FFF6.
Stack contents for handler:
$00, S - (empty, current stack pointer) $01, S - P status byte $02, S - return address low (BRK/COP PC + 2) $03, S - return address high $04, S - return bank K
There is no standard for how assemblers treat BRK or COP. If BRK emits only 1 byte, a signature byte can be added manually with a data byte following.
- ca65 in .p816 mode has an optional signature for BRK, allowing either 1 or 2 bytes. COP and WDM always require the signature byte.
The COP instruction was originally intended for use with a co-processor, for which the signature byte could indicate a command to send to the co-processor. However, there is no hardware to support this usage on the SNES, and it is simply a second software interrupt, equivalent to BRK.
Without Signature
If the signature byte is not needed, a BRK or COP handler may wish to decrement the return address on the stack before RTI, returning as if it were a one-byte instruction.
With Signature
A software response to BRK or COP may use the return address on the stack to deduce the location of the operand byte and inspect it.
This might be used for error codes, or as a compact system call dispatch.
WDM
The WDM instruction was reserved for future use, but was ultimately left unused. It is simply a 2-byte alternative to NOP.
Mesen's debugger provides a break-on-WDM instruction which can make it convenient as an emulator-only breakpoint.
Notes
- Though the 65C816 has no unused opcodes, on the 6502 many were left open with unspecified behaviour. This allowed the use of "unofficial" illegal opcodes, including several NOP variants with an unused signature byte. See: NESDev: CPU unofficial opcodes
References
- ↑ Eyes & Lichty
