Programming an emulator: How does the emulator understand opcodes from addresses?

Question

I'm having difficulty understanding how a SNES understands what are opcodes and what are addresses/parameters. I know that each opcode is encoded by a unique hex byte. Are they paremeters the bytes immediately following? If so, how does it know to take in one byte or two bytes (for absolute or direct addresses).

If this is the case, does that mean that the first byte of the file (after the header) is an opcode?

Answer 1

The processor has a PC (Program Counter) register containing the address of the next instruction to be executed. On reset, the PC is set to a fixed value where execution begins.

The first byte of every instruction is the op-code byte; its coding determines what the instruction will do and how many operand bytes are required. The processor fetches the op-code byte from the address in the PC and increments the PC. The op-code is examined and any necessary operand bytes are fetched, always from memory pointed to by PC which is incremented for each one. Once a complete instruction is fetched the PC will be pointing at the op-code for the next instruction.

The CPU then performs the operations determined by the op-code byte and its operands, this is called instruction execution. Execution may change the PC in the case of a jump for example but at the end of execution, the PC will be pointing at the op-code byte of the next instruction to execute and the cycle, called the fetch-execute cycle, continues.

Bugs in programs are quite often due to the fact that the PC is changed to a value which is not the the start of an instruction written by the programmer/compiler. The CPU has no way of knowing that and proceeds regardless, executing memory content which was never meant to executed and performing essentially random operations.

An excellent resource for understanding how this is all put together is The Elements of Computing Systems which is a book but most of the content are available from that web site.

Hope that helps.

Answer 2

If this is the case, does that mean that the first byte of the file (after the header) is an opcode?

The SNES's CPU is based on the 65C816, which is sort of an evolution of the 6502. For backwards compatibility, the 65C816 includes an emulation mode that is binary compatible with the 6502 (actually the 65C02). There's also the native mode, where you've got 16-bit registers and all that jazz.

Each mode has its own vector table:

Native mode:

$FFE4: COP (co-processor interrupt)
$FFE6: BRK
$FFE8: ABORT
$FFEA: NMI (vertical blank)
$FFEC: - (no RESET in native mode)
$FFEE: IRQ

Emulation mode:

$FFF4: COP
$FFF6: -
$FFF8: ABORT
$FFFA: NMI (vertical blank)
$FFFC: RESET
$FFFE: IRQ or BRK

When the CPU is reset it starts up in emulation mode and expects to find the RESET vector at logical address $FFFC (which physical offset within the ROM that corresponds to depends on the memory mapping mode).

The address stored at the RESET vector should point to the first piece of code that you want to execute following a reset / power cycle. Typically it would start with disabling interrupts, switching the CPU to native mode, and the continue to initialize the rest of the system (graphics processor, sound processor..):

sei    ; Disable interrupts
clc    ; Clear the carry flag 
xce    ; Swap the carry and emulation flag (i.e. clear the emulation flag)
...    ; Awesomeness follows..