Hi,

I'm hoping to get some advise on the 6502 BIT instruction, as I can't seem to get it to do what I need.

So I understand that the instruction can be used to check if some bits are set (or not set) and it sets the zero flag accordingly.

I would like to check if bits 6 and 7 of a value stored in the Accumulator are set, I'm not interested in if the other bits are set or not.

So I've tried:

LDA #255 (Example value with bits 6 and 7 set)
BIT $C0 ($C0 = %11000000 - this indicates the two bits I want to check).
BEQ bitsareset
<some code to indicate bits 6 and 7 are not set>
.bitsareset
<some code to indicate bits 6 and 7 are set>

So the above code would indicate that 6 and 7 are set, is this correct? (Obviously not as I can't get it to work!).

I'd appreciate some advice - Thanks!

The BIT instruction performs an AND between the Accumulator and the content of a location in memory. So, in your example, it will take the content of the location $C0 and will perform an AND with the accumulator. It will transfer bits 7 and 6 of the content of the location $C0 to the flags Z and V. It will not transfer the bits of the value $C0, nor will AND the $C0 value with the accumulator: the argument of BIT is a location in memory, and will fetch the content of that location to do the work.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

sorry: it will transfer bit 7 and 6 to N and V.

For that particular example I would use CMP #$C0 ... if carry is set then bits 6 and 7 are both set, if carry is clear then one or both bits are clear. Woz used the negative flag after a CMP #$C0 in his 1976 floating point package's normalization routine to check if bits 6 and 7 were the same or not, a tidy hack that wouldn't have occurred in the minds of most mortals.

So, we have:This untested example doesn't disturb any registers or memory, only the flags ... if that's not a concern then smaller versions are available.

_________________
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 I will put my 2 cents in here as well. Depending on you want to do after you have checked the bits in the Accumulator, but your branching instructions already have the hi-bit covered. If bit #7 is set, then you can branch using BMI/BPL without checking what is specifically in the hi-bit. I usually like to use bits 0 & 1, and 6 & 7 for flag indicators. They can then easily be checked like so.

LDA BYTE
BMI - branch if bit#7 set
ASL
BMI - branch if bit#6 set

or

LDA BYTE
LSR
BCS - branch if bit #0 set
ROR - preserve bit #0
BCS - branch if bit #1 set

some advantages of this method is that the you retain the original value in BYTE, if it is an address and not an immediate value. But also the Accumulator can be restored to its original value with a simple ROR for the first method and a ROL ROL for the second.

Also instead of using BIT on an immediate value, you can use BIT on a zero-page location, then it is just a matter of doing this:
Note: This method does not affect what is in the Accumulator.

BIT ZP_BYTE
BMI *+2 - branch on bit #7 set
BVS - branch on bit #6 set
BVS - branch if both bits #6 and #7 are set
... - code falls through if neither bit #6 or #7 are set

Brilliant - thanks for the responses and help - lots to consider.

Note that while CMP is often best if you need ALL target bits set, "BIT addr" does let individually testing bits 5-7 with a single test and then a sequence of branches based on the sign, overflow and zero flags.



I tried something along those lines in a recent effort to "crunch" an implementation of a Sweet16 VM ... https://github.com/BruceMcF/Sweeter16 ... but the space saved wasn't worth the trouble. Still, maybe someday it'll come in handy.

I think only the 65c02 and 65816 support BEQ/BNE with BIT that way. The 6502 does not, or at least one of the 6502's chips do not.

AFAIU, that's the 6502 BIT I knew on the C64: https://www.masswerk.at/6502/6502_instruction_set.html#BIT


The BIT address modes that the 65C02 adds are "BIT zp,X", "BIT addr,X" and "BIT #n" ... "BIT #n" is especially handy. However loading bit 7 and bit 6 of the operand doesn't do much good with "BIT #n", because it comes from the "n", so you already know whether it has bits 6 and 7 set.

IOW, in the original opcodes, the mask is normally loaded into the accumulator before the BIT instruction, and the target is the operand, so pulling bit 7 and bit 6 into the sign and overflow flag is extra information "for free". But with "BIT #n" addressing, the mask is normally the operand and the target is normally in the accumulator, so reading in bits 7 and 6 of the constant "n" is not as useful.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Boy! do I look silly.

I have had this bit of code fail on me many times as a test, and assumed it wasn't supported.
It should have crashed and it didn't.

this is how I test If I want to know something specific about an instruction.

I don't know your assembler, but wouldn't *+1 as an operand be the first address after the address of the operand? That would be the address of the RTS instruction. So it could be taking the branch and returning, where you are concluding it failed to take the branch and returned.

Try *+2.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!