.PRG File Format – Machine code and entry

Commodore 64 program

The program

After the BASIC program (or from the first data byte, in a file that has none) the file holds the machine code and its data, byte for byte as they go in memory from the load address. The file does not say which bytes are code, which are data, or where the code starts. The explorer decodes an instruction at every byte of this block, laid out in columns: the first column is the plain disassembly from the start of the block, and the others hold the instructions that start inside it, so code reached by a jump into the middle of an instruction can be read. Data shows up as instructions that make no sense, often with undocumented opcodes in them.

The entry point

How the program is started depends on how the file is run:

  • With a BASIC stub, RUN runs the stub, and the stub’s SYS starts the code. The explorer takes the first SYS with a plain decimal number as the entry point, labels that address entry in the disassembly, and starts the block’s “entry” there.
  • With no stub, the file loads with ,8,1 and something else (a loader, a cartridge, the user typing SYS) starts it. The file does not say where, so the explorer shows the whole block from the load address and gives no entry point.

If the SYS address is outside the file, the code it calls is in ROM or comes from somewhere else; the explorer says so and gives no entry label. A SYS into the KERNAL (SYS 64738, the reset) is common.

Names in the disassembly

An operand that is the address of a KERNAL routine, a register of the VIC-II, SID or CIA chips, or one of the common zero-page and system locations is written with its name, and the instruction detail says what it is. The tables are on C64 named addresses.

The processor and unusual opcodes

The disassembly is of 6510 code by default. The C64’s processor is an NMOS 6502 with a built-in port, so it decodes every one of the 256 opcodes, including the undocumented ones. Demos and games often use them (LAX, SAX, DCP, ISC and SLO most often), so the viewer does not treat them as errors; it highlights them, with the status written out:

  • documented opcodes have a plain box;
  • undocumented ones, which do the same on every chip, are tinted;
  • unstable ones, whose result varies between chips, are tinted red;
  • jam opcodes, which stop the processor, are red with a dashed border.

A block of data decoded as code is full of the last two. The options bar can change the processor to the NMOS 6502 (the same decode) or the 65C02, for which every opcode is documented and some bytes are different instructions.

The 6510’s port and banking

The 6510 has an 8-bit I/O port at addresses $00 (the direction register, CPU_DDR) and $01 (the port, CPU_PORT). Its low three bits select whether the BASIC ROM, the KERNAL ROM and the I/O chips or the RAM beneath them are visible, so lda #$35 / sta $01 switches both ROMs out, leaving RAM at $A000–$BFFF and $E000–$FFFF, and keeps the I/O area. The disassembly does not follow this: it shows the file’s bytes at the addresses they load to, whatever is banked in.