Making a Weapon Deal 2x Damage to a New Monster Type

The code for dealing 2x damage to Human:

Code:

C2/38F2: B9 95 3C     LDA $3C95,Y

Loads the specialy byte into the Y register, which will be compared by whatever is put into the A register via BIT below

That's not quite right. The Y register is unaffected; this is actually loading the value into A, indexed by Y at $3C95. You can basically read this as:

Load value at ($3C95 + Y) into A.

So if Y = 0, it loads the value at $3C95. If Y = 7, then it loads the value at $3C9C. If Y = B4 (180), then it loads the value at $3D50.

Code:

C2/38F5: 89 10        BIT #$10

This is checking to see if the 5th bit, the human flag is set, because 10h (10 in hexidecimal) is 16 in decimal and in bit form, this is literally and physically 00010000.  But wait!  Doesn't it look like it's checking for a 1 in the 4th bit?  No, we're just noobs, because the order is REVERSED for all 8 bits based on how hexadecimal progresses (01h = 00000001, 02h = 00000010, etc.  If the byte at $3C95 was 10000001, then the 5th bit isn't set, the 1st and 8th are, so nothing is loaded into the A register for comparison or calculation.  Checking for both 10000001 would be done via BIT #$81.  Technically, any matches of bits from the compared byte versus the BIT operation in the A register results in a "1" bit in the byte of the A register.  So all 1s that match go into the A register byte.

The only quibble I have here (aside from what Madsiur mentioned - that BIT doesn't actually alter the A register at all) is that most of the time, you will see people start at 0 instead of 1 when talking about individual bits in a byte. So, while BIT #$10 does check the fifth bit, most documentation or commentary will call it bit 4. Likewise, in your second example (BIT #$81), a potential hacker is more likely to see those bits listed as bit 0 and bit 7, rather than 1 and 8.

Otherwise, this is a pretty good jumping point for anyone that wants to start writing new weapon effects.