This post is a bit long by my standards. The TL;DR version of my questions are:

1. Is my understanding of how the 6502 handles inequalities correct?
2. Am I correct in understanding there is no bitwise NOT instruction? If so, what's the best way to simulate ~ .A?
3. How does the V flag fit into the inequality matrix? I get that it's out-of-range for 2's compliment in a single byte.
4. How does BCD mode affect any of this?

So, I'm still tying to understand a few basic things about how the 6502 checks for inequality and one logic question. In the abstract I "get" that from the Negative, Zero, and Cary flags — 2^3=8 possible combinations of bits — logical inequalities emerge. What is less clear is what combination of flags constitute which specific inequalities. I had to consult 2-3 different documents in order to pull together this chart.

Even then, I may well have made mistakes. This is part of a journey on my part to better grasp the Processor Status Register's effects on the system as a whole. I was encouraged to dig along these lines due to a comment on another thread of mine.

It seems six possibilities should exist and that .P NZC drive the show:

Binary Inequality Chart


Given 8 possible permutations of 3-bits, I thought that might suggest there are two combinations of the above three flags that don't fall neatly into symbolic logic. Of course, if someone casually suggested my ALU was "missing a few symbols" they might just be right.

Bruce Clark's article Compare Instructions an Branching helped. The Compare and Beyond article was instrumental. Without it, would not have the 3-bit logical pattern worked out the way that I did.

Jump Instructions: Unsigned Bytes

• BCC (Branch on Cary Clear) IF unsigned .A is < M .PC will branch to target.
• BCC (Branch on Cary Clear) IF unsigned .A is ≤ M .PC will branch to target.
• BCS (Branch on Cary Set) IF unsigned .A is > M .PC will branch to target.
• BCS (Branch on Cary Set) IF unsigned .A is ≥ M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF unsigned .A is ≤ M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF unsigned .A is = M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF unsigned .A is > M .PC will NOT branch to target.
• BVC (BVCBranch if oVerflow Clear) IF unsigned .A is ? .PC will do what?

Jump Instructions: Signed Bytes

• BMI (Branch if Minus [negative] flag Set) IF signed .A is < M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF signed .A is = M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF signed .A is > M .PC will NOT branch to target.
• BPL (Branch if Minus [negative] flag clear) IF signed .A is > M .PC will branch to target.
• BMI (Branch if Minus [negative] flag set) IF signed .A is ≤ M .PC will branch to target.
• BEQ (Branch if Equal to Zero Flag Set) IF signed .A is ≤ M .PC will branch to target.
• BPL (Branch if Minus [negative] flag clear) IF signed .A is ≥ M .PC will branch to target.
• BVC (BVCBranch if oVerflow Clear) IF signed .A is ? .PC will do what?

Some assemblers, such as 64tass, aliases BCC as BLT (Branch Less Than) and BCS as BGE (Branch Greater Equal). Are these the most flexible greater than / less than instructions?

Bitwise Logic
From the 6502 instruction set, I see most of what I expect for bitwise operations:

• The and instruction is bitwise AND (&) .A which interacts with .P: N+, Z+.
• The ora instruction is bitwise OR (|) .A which interacts with .P: N+, Z+.
• The eor instruction is bitwise XOR (^) .A which interacts with .P: N+, Z+.
• I'm not sure, but it seems bitwise NOT (~) .A does not exist?!
• The asl instruction is arithmetic shift left (<<) .A which interacts with .P: N+, Z+, C+.
• The lsr instruction is arithmetic shift right (>>) .A which interacts with .P: N-, Z+.

Am I missing something about the existence of bitwise NOT? Assuming there is no instruction to that effect, what combination of instructions would simulate bitwise NOT by flipping all 8 bits? I think it's a precise combination of OR with AND but I haven't quite got it. This seems like glaring omission.

eor #$FF

For bitwise NOT, use EOR #$FF. Two bytes, two cycles.

There's actually a reasonably fresh thread about the 6502's status flags in the Programming section. In there, there's a link to a tutorial about how comparisons work on the 6502. Hint: it works differently for signed and unsigned values, and there are also subtleties with multi-byte values.

But I do see some misconceptions that I can clear up immediately.

Z and N are never set at the same time, unless you force it by restoring a crafted status byte; Z indicates whether the ALU result was zero, N whether the most significant bit was set. So after executing CMP, you will not have 8 possible combinations of Z, N, and C.

Broadly speaking, V indicates signed overflow, ie. a notional carry from bit 6 to 7. It is not updated by CMP, only ADC and SBC.

All of the shift and rotate instructions push the "exiting" bit into the Carry flag. The rotate instructions take the old value of the Carry flag into the other end. The shift instructions just clear that bit instead.

This thread here? The 6502 Status Register: a Guide to Black Magic? I'll look it over.

Also, thanks for the tip to you and the other poster who shared eor #$ff as a solution to the missing bitwise NOT instruction. That's wonderfully efficent.

I can't say that I've tried it, but is it possible to do this with a BIT instruction too? E.G. $7F in A and $80 in memory?

(I know ... even if I'm correct, the technique would probably have rather eccentric value ...)

Slightly off-topic, I based this table on the 68xx behavior, but inverted the C flag to more closely mimic the 65xx behavior for my "work-in-progress" CPU design, which draws heavy inspiration from both families:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I think that is one case where it can occur, yes. But aside from BIT, it does not. The combination is invalid for a numeric comparison.