Different status flags are updated by different instructions, and any decent listing of 6502 assembler opcodes will indicate which status flags will be affected by each instruction. I like to use the opcodes listing at the 6502.org web site (
http://www.6502.org/...502opcodes.html), just because www.6502.org is an easy URL for me to remember.
For example, it says
ADC (ADd with Carry)
Affects Flags: S V Z C
Thus, when you use an ADC instruction, it will either set or clear the S, V, Z, and C flags. (S is just another name for N-- S for Sign, N for Negative.) Most instructions will affect at least one or two flags, but there are a few instructions that don't affect any flags. For example, the branch instructions don't affect any flags (although they are affected *by* the flags); JMP and JSR don't affect any flags; NOP doesn't affect any flags; RTS doesn't affect any flags; and the store instructions don't affect any flags.
You don't necessarily have to do a branch right after a compare instruction, addition, subtraction, etc., as long as the other instructions that come between the comparison and the branch don't change the flag you're interested in. For example, consider the following bits of code from my "bitmap" program:
LDX field ; 03 ; 73 ; 219 ; 151
STY WSYNC ; 03 ; 00 ; 000 ; -68
STY VBLANK ; 03 ; 03 ; 009 ; -59
BNE active_lines_1 ; 02++ ; 05 ; 015 ; -53
Here, the BNE branch is taken (or not) based on the results of the LDX instruction. It would have been easier to understand the code if the LDX and BNE had been coded one after the other, but I needed the BNE to end at cycle 5, so that's why the two STY instructions were placed between the LDX and the BNE. Fortunately, the STY instruction doesn't change any flags. If field is not equal to 0, branch to active_lines_1, else (if field *is* equal to 0) fall through to the next statement.
CPY #192 ; 02 ; 67 ; 201 ; 133
STY WSYNC ; 03 ; 00 ; 000 ; -68
STY HMOVE ; 03 ; 03 ; 009 ; -59
BNE active_lines_1 ; 02++ ; 05 ; 015 ; -53
This is similar to the preceding example, and is coded in this order for the same reason-- so the BNE will end at cycle 5. If the Y register is not equal to 192, branch to active_lines_1; else (if Y *is* equal to 192) fall through to the next statement.
CPY #64 ; 02 ; 08 ; 024 ; -44
LDA (column_01),Y ; 05+* ; 13 ; 039 ; -29
STA GRP0 ; 03 ; 16 ; 048 ; -20
LDA (column_03),Y ; 05+ ; 21 ; 063 ; -05
STA GRP1 ; 03 ; 24 ; 072 ; 004
LDA (column_09),Y ; 05+* ; 29 ; 087 ; 019
TAX ; 02 ; 31 ; 093 ; 025
LDA (column_05),Y ; 05+* ; 36 ; 108 ; 040
STA GRP0 ; 03 ; 39 ; 117 ; 049
LDA (column_07),Y ; 05+ ; 44 ; 132 ; 064
STA GRP1 ; 03 ; 47 ; 141 ; 073
STX GRP0 ; 03 ; 50 ; 150 ; 082
LDA (column_11),Y ; 05+ ; 55 ; 165 ; 097
STA GRP1 ; 03 ; 58 ; 174 ; 106
BCS load_data ; 02++ ; 60 ; 180 ; 112
This one is a little more interesting. The BCS branch is taken (or not) depending on the results of the CPY instruction. The CPY instruction affects the N, Z, and C flags-- Negative, Zero, and Carry. The STA and STX instructions don't affect any of the flags, but the LDA and TAX instructions affect the N and Z flags. As it happens, I didn't care about those flags, just the C flag, so this worked out perfect for me. If Y is greater than or equal to 64, branch to load_data; else (if Y is less than 64) fall through to the next statement. The stores to the player graphics registers had to be timed just right, but it turned out I had 2 cycles free on the line, so I could have replaced the CPY with a NOP instruction, and then put the CPY right before the BCS. However, at the time I was writing the code, I didn't know I was going to end up with 2 cycles free, so that's why I arranged the code in the order I did.
Michael
0
6502.txt 53.19K
69 downloads 
