Status flags

The flags register, also called processor status or just P, is one of the six architectural registers on the 6502 family CPU. It is composed of six one-bit registers (see Status flags); instructions modify one or more bits and leave others unchanged.

Instructions that save or restore the flags map them to bits in the architectural 'P' register as follows:

7  bit  0
---- ----
NVss DIZC
|||| ||||
|||| |||+- Carry
|||| ||+-- Zero
|||| |+--- Interrupt Disable
|||| +---- Decimal
||++------ No CPU effect, see: the B flag
|+-------- Overflow
+--------- Negative: Set to bit 7 of the last operation

• The PHP and PLP instructions can be used to retrieve or set this register directly via the stack.
• Interrupts returning with RTI will implicitly PLP the saved status register from the stack.

C: Carry

• After ADC this is the carry result of the addition.
• After SBC or CMP this flag will be set if no borrow was the result, or alternatively a "greater than or equal" result.
• After a shift instruction (ASL, LSR, ROL, ROR) this contains the bit that was shifted out.
• Increment instructions do not affect the carry flag.
• Can be set or cleared directly with SEC, CLC.

Z: Zero

• After most instructions that have a value result, if that value is zero this flag will be set.

I: Interrupt Disable

• When set, all interrupts except the NMI are inhibited.
• Can be set or cleared directly with SEI, CLI.
• Automatically set by the CPU when an IRQ is triggered, and restored to its previous state by RTI.
• If the /IRQ line is low (IRQ pending) when this flag is cleared, an interrupt will immediately be triggered.

D: Decimal

• On the NES this flag has no effect.
• On the original 6502 this flag causes some arithmetic instructions to use Binary Coded Decimal representation, to make base 10 calculations easier.
• Can be set or cleared directly with SED, CLD.

V: Overflow

• ADC, SBC, and CMP will set this flag if the signed result would be invalid, necessary for making signed comparisons.
• BIT will load bit 6 of the addressed value directly into the V flag.
• Can be cleared directly with CLV. There is no corresponding set instruction.

N: Negative

• After most instructions that have a value result, this flag will contain bit 7 of that result.
• BIT will load bit 7 of the addressed value directly into the N flag.

The B flag

While there are only six flags in the processor status register within the CPU, when transferred to the stack there are two additional bits. These do not represent a register that can hold a value, but examining the result pushed to the stack can be used to distinguish how they were pushed.

Some 6502 references call this the "B flag", though it does not represent an actual CPU register.

Two interrupts (/IRQ and /NMI) and two instructions (PHP and BRK) push the flags to the stack. In the byte pushed, bit 5 is always set to 1, and bit 4 is 1 if from an instruction (PHP or BRK) or 0 if from an interrupt line being pulled low (/IRQ or /NMI). This is the only time and place where the B flag actually exists: not in the status register itself, but in bit 4 of the copy that is written to the stack.

Instruction	Bits 5 and 4	Side effects after pushing
PHP	11	None
BRK	11	I is set to 1
/IRQ	10	I is set to 1
/NMI	10	I is set to 1

Two instructions (PLP and RTI) pull a byte from the stack and set all the flags. They ignore bits 5 and 4.

The only way for an IRQ handler to distinguish /IRQ from BRK is to read the flags byte from the stack and test bit 4. The slowness of this is one reason why BRK wasn't used as a syscall mechanism. Instead, it was more often used to trigger a patching mechanism that hung off the /IRQ vector: a single byte in PROM, UVEPROM, flash, etc. would be forced to 0, and the IRQ handler would pick something to do instead based on the program counter.

Unlike bits 5 and 4, bit 3 actually exists in P, even though it doesn't affect the ALU operation on the 2A03 or 2A07 CPU the way it does in MOS Technology's own chips.

External links

• koitsu's explanation

Old Article

(A merge is in process combining these two articles.)

The 6502 has 6 status flags: carry, decimal mode, interrupt disable, negative, overflow, and zero. Each of these can either be set or clear. The processor stores the current state of each at all times. There are 2^6 = 64 total states these flags can be in.

During certain events, a copy of the flags is written to a byte in memory. There are 8 bits in a byte, and when writing to memory, all 8 bits must be written. Since there are only 6 status flags, the unused 2 bits must be given values.

There are four events that cause the flags to be written to memory: NMI and IRQ vectoring, and the BRK and PHP instructions. Rather than set the unused bits in the copy in memory to the same values in all cases, the 6502 sets one of them based on whether the event was interrupt vectoring or an executed instruction.

The flags are copied to memory in this arrangement:

Bit 7: Negative
Bit 6: Overflow
Bit 5: Always set
Bit 4: Clear if interrupt vectoring, set if BRK or PHP
Bit 3: Decimal mode (exists for compatibility, does not function on the Famicom/NES's 2A03/2A07)
Bit 2: Interrupt disable
Bit 1: Zero
Bit 0: Carry

Note bits 4 and 5. This means that the following will put $30 into A, not 0:

LDA #$00
PHA      ; pushes $00 on stack
PLP      ; clears all 6 status flags
PHP      ; pushes $30 on stack
PLA      ; pops the $30 off the stack

Since bit 4 is set if the cause was a BRK instruction, and clear if it was an IRQ, this allows code to determine the cause of its IRQ handler being invoked, since BRK and IRQ both use the vector at $FFFE:

irq:
        STA temp
        PLA        ; get saved flags off stack
        PHA        ; save again
        AND #$10   ; check bit 4
        BNE caused_by_brk
caused_by_irq:
        ...
caused_by_brk:
        ....

The above is the only way to determine the cause of the irq handler invocation. One might think that the following would work, if one thought that there was a status flag that told when it was a BRK instruction that invoked the IRQ handler:

; wrong way to determine cause of IRQ handler invocation
irq:
        STA temp
        PHP        ; save current flags
        PLA        ; get saved flags off stack
        AND #$10   ; check bit 4
        BNE caused_by_brk
caused_by_irq:
        ...
caused_by_brk:
        ....

This fails because there are only 6 status flags, none of which tell the reason the IRQ handler was invoked. This misunderstanding exists because many descriptions of the 6502 incorrectly state that the processor has 7 status flags, the 7th one being the break flag.

There is no break flag; there are only 6 status flags. As covered above, there are 8 bits in a byte, so when saving a copy of the status flags in memory, these unused two bits must be set to something. On the 6502, bit 5 of the copy is always set, and bit 4 is set BRK or PHP, clear if an interrupt. When restoring the flags from memory, bits 4 and 5 are ignored, since again, there are only 6 status flags, and thus the extra 2 bits of the byte must be ignored.

See also

• CPU status flag behavior