65002 Opcode Prefixes

• Prefix Overview
• Addressing Mode
• Offset prefix
• Register Size prefix
• Load Extensions prefix
• User Mode selector
• No Flags prefix
• Opcode Tables

In the opcode map there are 32 codes designated as "prefix1" and 16 codes designated as "prefix2". These opcodes are no operations in themselves, but modify the following operation. The prefix has these values:

I.e. in prefix1 the lowest two bits are always one and bit 2 (value 4) is always zero, but all of the other five bits have a special meaning.

For prefix2 the low four bit are fixed, the other bits are used as prefix.

The following table explains the prefix bits.

These prefix opcodes modify the following opcodes in various aspects. The following opcodes are taken from the original 8  bit opcodes. I.e. there could be a new opcode

        LDA.L #$12345678
        

to load the accumulator with a long (32  bit) value, that is implemented as

        23 A9 78 56 34 12
        

Here 23 is the prefix with RS=%10, i.e. 32  bit registers, and A9 is the original LDA immediate opcode - only the parameter is now 4 byte (32  bit) not 1 byte anymore.

Please note that when all variable prefix bits are zero, the original 6502 operation is executed - with the notable exception on LD* opcodes as described in the section about Load Extension.

Please also note that the order of the prefix bytes is well defined. prefix1 must be before prefix2, which is before the actual opcode. This way the prefix1 codes can be reused in the actual prefixed opcode. This would not be the case if prefix2 was before prefix1, because then it would not be distinguishable of the byte following prefix2 is a prefix1 or a reused opcode. This is done to be able to reuse the prefix1 values for extended opcodes, when a prefix1 byte has already occured. With AM=1 a prefix1 byte must be set, so there can be additional opcodes in the prefix1 space that use extended addressing modes.

The table below gives an overview on which prefix applies to which opcode.

The LE flags only apply to opcodes that read an operand from memory, but not to read-modify-write opcodes. It does not apply to store operations (which could have been done switching memory and register sides). However, as the processor is available in different native register widths, the store would happen in different widths depending on the processor - effectively binding the software to a fixed processor width.

The NF flag does not apply to compare opcodes - their only purpose is to set the flags...

Note that the Register size option for the RTS and JSR opcodes determine the size of the return address as put on the stack. The RS=00 (8  bit register size option) however is mapped to the natural address width of the processor (mode).

The Register size option for the branch opcodes determines the size of the relative address offset. For the BSR opcode this is in conflict with the size options for the address on the stack. Therefore BSR is handled similar to JSR, in that RS determines the size of the return address on the stack, and AM modifies the relative offset from "rel" to "rellong" resp. from "relwide" to "relquad".

Note that the TRAP opcode is marked as using no prefix bits, but still written down in that table. This is for future extensions, when RS may be used to allow more than 256 trap codes.

The green cells are duplicate opcodes. These take the place of prefix1 and require at least one prefix bit set (AM in the current cases). These duplicate opcodes allow to extend an indirect opcode, more specifically to have more options for the size of the address stored at the indirect location.

Normally not all addressing modes would be supported with direct addressing mode replacements. The quad (longlong) indirect addressing modes are not reached. Thus the indirect opcodes are mirrored, and extended from long to quad (longlong) indirect addressing modes. Row LSB 1 is mirrored thus to row LSB 3, as well as row LSB 2 is mirrored to LSB 7. These values are marked with a green background in the table. The LSB 3 and 7 rows then change from (normal = word) indirect addressing modes to quad (longlong) indirect addressing modes.

Also note that there a are no indirect addressing modes that take a long or quad (longlong) value as indirect address.

The AM prefix allows to select an alternative addressing mode compared to the original 6502 addressing mode. For example the "zeropage" addressing mode is converted to the "long" alternative addressing mode.

For more details on this please see the addressing modes page.

The offset prefix bits allows to add an address offset to the effective address of the operand. Four options are available:

For (non-indirect) zeropage/absolute and indexed addressing modes to compute the effective address the standard addressing mode effective address is computed, then the register value is added to get the final effective address.

For the indirect addressing mode that situation is more complex. The offset register value is added to the zeropage or absolute address given in the opcode, to compute the indirect address. For indexed with XR addressing modes XR is added to this address to get the real indirect address. Then the effective address is read from the computed indirect address, for indexed with YR then the value of YR is added to the address read, to get the real effective address. Here the offset is not added again.

Note that the size of the address read from the indirect address is defined by the addressing mode alone (which is also determined by the AM prefix bit).

The maximum register size depends on the used processor option. Each operation has a possibly smaller width. The Register size prefix defines the operation width. I.e. this determines the number of bytes to read from memory (from the effective address), the number of bytes to store to memory, or the number bytes to use from resp. store in a register.

The different width prefixes are written as postfixes to the opcode:

Please note that 8  bit width has no postfix.

TODO: rename to "OS" = "Operation size" or "OW" = "Operation width"?

The registers have a defined width - depending on processor option - of 16, 32 or 64  bit. Operations can be from 8 to 64  bit. There are some use cases where some adaption of a value to the register size is practical. For example if an 8-bit value is used on a 32-bit operation - like adding #8 to an address register.

For this purpose the LE bits define how a value loaded from memory (or from another register in the case of the Txy opcodes) is extended to full register size. Four options are available:

When the result of an operation is written to a memory location or register, the data is written in the same width as the operation.

Using this extension - i.e. having a value of not 00 - modifies the meaning of the RS prefix. RS then actually defines the width of the memory location to be read. The actual operation happens after loading the value, and it happens at full width. For operations other than loads, the flags are set appropriately from the full width operation result value. For loads (LDA, LDX, LDY) and transfers (TAX, ...), however, the flags are set from the RS-width value that is read from memory (note: if you need flags from the full width value, use BIT A, but in general you should know the outcome of the extension of a load opcode).

There is another difference between loads/transfers and other operations. Loads and transfers do a zero-extension by default, while other opcodes do not extend. To change the load/transfer default behaviour, use an explicit LE prefix of 00. The assembler should take care to create the correct prefix when using another prefix bit in prefix2. For example doing a LDA.U should automatically be set to LDA.U0.

This somewhat inconsistent behaviour between loads/stores and others implements a "least surprise" strategy for loads. X and Y are always used full-width in address calculation. Doing an LDY #0 would not clear all bits and depending what previously executed code left in those bits this leads to unexpected behaviour. Even with the extension, however, the flags need to be set from the width that has been read - in general 8 bits, to be compatible with 6502 code.

So when loading a register, the upper bits are filled with zero by default - but flags are set from the original width (as defined by RS). To load AC with the lower bits only, explicitely set the prefix with LE0=LE1=0 (using the postfix .E). This would normally denote the original 6502 behaviour and could thus be left out, but not in this case as the default - for loads/transfers - is not the 6502 behaviour, yet compatible.

Normally the opcode uses the current processor mode - user or hypervisor - to compute the correct address. For the supervisor mode there is an option, however, to use an address from user mode as operand. This is what the User Mode selector bit (UM) is for.

When the User Mode selector is set, the operand following the opcode is read from the current (hypervisor mode) memory environment (as defined by the matchcode). Then the processor temporarily switches to user mode, using the user mode matchcode and usermode stack pointer. For non-indirect addressing modes then the operand is written to or read from the computed address. For indirect addressing modes the indirect address is read from user mode, then the actual operand is read from or written to user mode as well.

The main purpose of this bit is to enable the following situation:

1. user mode prepares stack with trap parameters
2. user mode executes a TRP, jumping to hypervisor trap handler. Note that the return address is stored on the hypervisor stack, so the user mode stack pointer still points to the parameters.
3. hypervisor mode trap handler then does for example LDA.U S,$00 to read the first parameter byte from the user mode stack

Note that this bit is a privileged operation - unavailable if no hypervisor mode option is present, and trapping into an abort if executed in user mode.

With the user mode selector such operations as PHA or PLX etc can be easily redirected to the user space stack.

If it is needed to also compute the address in hypervisor mode - relevant only for the indirect addresses - use LEA with the indirect addressing mode. This computes the address in hypervisor mode and stores it in E. Then use the E-indirect addressing mode on the actual operation for example with LDA.U (E).

The NF bit, when set, prevents the status register bits from being changed. For example you can do index register increments for example without losing the contents of the Z and N status register flags.

The following tables describe which prefixes apply to which opcode.

This table describes the standard opcode page:

This table describes the EXT opcode page:

The grey fields note opcodes that are not used in the 65002.