BIT op refresher please (Kwik Copy)

by **Christian Lott** » Fri, 30 Jul 2004 13:23:36 GMT

ould someone please explain how the BIT op is working in these two
routines? I've verified the branch and jump instructions lead to valid
routines. This is from Kwik Copy, extracted form a freeze file. I have
100% of the routines seperated from it's text. Is it that the program is
entering these routines from multiple angles?

17df:17df:1 8a txa
17e0:17e0:1 18 clc
17e1:17e1:1 69 01 adc #$01
17e3:17e3:1 d0 ea bne $17cf
17e5:17e5:1 24 1f bit $1f
17e7:17e7:1 19 12 0c ora $0c12,y
17ea:17ea:1 0c ???
17eb:17eb:1 0d 0e a6 ora $a60e
17ee:17ee:1 40 rti
17ef:17ef:1 48 pha
17f0:17f0:1 4a lsr a
17f1:17f1:1 4a lsr a
17f2:17f2:1 4a lsr a
17f3:17f3:1 85 29 sta $29
17f5:17f5:1 8a txa
17f6:17f6:1 0a asl a
17f7:17f7:1 0a asl a
17f8:17f8:1 05 29 ora $29
17fa:17fa:1 a8 tay
17fb:17fb:1 68 pla
17fc:17fc:1 29 07 and #$07
17fe:17fe:1 aa tax
17ff:17ff:1 b9 01 2d lda $2d01,y
1802:1802:1 3d 06 18 and $1806,x
1805:1805:1 60 rts

1806:1806:1 01 02 ora ($02,x)
1808:1808:1 04 ???
1809:1809:1 08 php
180a:180a:1 10 20 bpl $182c
180c:180c:1 40 rti
180d:180d:1 80 ???
180e:180e:1 a9 12 lda #$12
1810:1810:1 85 40 sta $40
1812:1812:1 a9 00 lda #$00
1814:1814:1 85 41 sta $41
1816:1816:1 4c 7b 23 jmp $237b

This is the same routines auto labled, where you can see seperate
routines entering at different points (not all of the labels are valid I
suspect).

17df:17df:1 8a skip17df txa
17e0:17e0:1 18 clc
17e1:17e1:1 69 01 adc #$01
17e3:17e3:1 d0 ???
17e4:17e4:1 ea lbl_17e4 nop
17e5:17e5:1 24 1f bit zp_1f
17e7:17e7:1 19 ???
17e8:17e8:1 12 ???
17e9:17e9:1 0c lbl_17e9 ???
17ea:17ea:1 0c ???
17eb:17eb:1 0d ???
17ec:17ec:1 0e ???
17ed:17ed:1 a6 40 sub_17ed ldx zp_40
17ef:17ef:1 48 sub_17ef pha
17f0:17f0:1 4a lsr a
17f1:17f1:1 4a lsr a
17f2:17f2:1 4a lsr a
17f3:17f3:1 85 29 sta zp_29
17f5:17f5:1 8a txa
17f6:17f6:1 0a asl a
17f7:17f7:1 0a asl a
17f8:17f8:1 05 29 ora zp_29
17fa:17fa:1 a8 tay
17fb:17fb:1 68 pla
17fc:17fc:1 29 07 and #$07
17fe:17fe:1 aa tax
17ff:17ff:1 b9 ???
1800:1800:1 01 2d lbl_1800 ora (zp_2d,x)
1802:1802:1 3d 06 18 and lbl_1806,x
1805:1805:1 60 rts

1806:1806:1 01 02 lbl_1806 ora (zp_02,x)
1808:1808:1 04 ???
1809:1809:1 08 php
180a:180a:1 10 20 bpl skip182c
180c:180c:1 40 rti
180d:180d:1 80 ???
180e:180e:1 a9 12 sub_180e lda #$12
1810:1810:1 85 40 sta zp_40
1812:1812:1 a9 00 lda #$00
1814:1814:1 85 41 sta zp_41
1816:1816:1 4c 7b 23 jmp sub_237b

by **iAN CooG** » Sun, 01 Aug 2004 05:36:21 GMT



Without the full source it's like a guessing game, but anyway let's try
it.


Hopefully X never gets a value of #$FF so ADC never returns 0 and the
BNE always branches to $17cf. It's a 2-byte JMP, but only to be used
when one knowns exactly the value of Z flag won't be ever set...


...so these other bytes never execute, and have to be considered as
data, char '$' is #$24 so maybe is this the meaning of that byte. I
tried looking from variuos angles but I don't see valid code in these
bytes ;)


But here starts another piece of code, as 64copy labels it as a sub_, so
it means it is cross-referenced by a JSR somewhere.



64copy saw that the address' low byte of the valid instruction at $17ff
is going to be modified (self-modifying code) and made some mess ^_^;


These bytes are a "precalculated" array of powers of 2

-- 
-=[]=---iAN CooG/HokutoForce+TWT---=[]=-

by **spirro** » Sun, 01 Aug 2004 12:12:42 GMT



From "Programming the 6502":

     "The logical AND of A and M is performed, but not stored.  The
result of the comparison is indicated by Z.  Z = 1 if the comparison
fails; 0 otherwise.  In addition, bits 6 and 7 of the memory data are
transferred into V and N of the status register.  It does not modify
the contents of A."

You can basically say that BIT behaves like the CMP instruction
WITHOUT changing the contents of the .Accumulator or memory address
being referenced.  It's got the added bonus of copying bits 6 and 7 to
the status register, oVerflow and sigN registers respectively, for ,
what I use it as, quick and easy conditional branching based off those
two registers.

However, a common use of the BIT instruction, seen extensively in the
kernel roms, is to "mask" instructions so they may be skipped over. 
When used correctly this can save execution time and memory, but tends
to be confusing when going back over the code unless you know the
correct entry points for it so it can be decifered.


This code looks like a possible debug point.  If the condition isn't
meet it falls through to the code in question and a crash is going to
happen.  Doing a disassembly of $17e6 onward shows more gibberish code
so this BIT command is probably just a coincidence or marker of some
kind.



This area is most likely a data area that wasn't cleared when the
overall program was saved or left for future patching.

For examples of using BIT as a "mask" you can find one of the many
kernel disassemblies on the net.  When you see a BIT command in the
disassembly, try disassembling the code at the location of the BIT
command plus one.  It should be clear then why it is used as a "mask".
 Since none of the registers, .A .X .Y, are affected it behaves as a
do nothing command, but it can be very useful.

by **Christian Lott** » Wed, 04 Aug 2004 14:44:06 GMT

Just wanted to thank you Ian and Greg for the answers!

Christian

BIT op refresher please (Kwik Copy)

BIT op refresher please (Kwik Copy)

Jump to:

Next

BIT op refresher please (Kwik Copy)

Re: BIT op refresher please (Kwik Copy)

Re: BIT op refresher please (Kwik Copy)

Re: BIT op refresher please (Kwik Copy)

Who is online