BMI/BPL Issue...

[CareerOfEvil]

I seem to be having an issue with the BMI and BPL commands. For some reason, it is calculating incorrectly...

My routine is:

Code: Select all

LDA BadGuy1X,x
	CMP HeroX 
	BEQ SecondDirectionCheck ;; If he is at hero's X position, don't move, the hero will bounce back anyway...
	BMI SetHimRight

	DEC BadGuy1X,x
	JMP SecondDirectionCheck ;; Check HeroY and BadGuyY
SetHimRight:
	INC BadGuy1X,x

Despite this, if on the second screen (There are 2) The hero moves toward the right, and is clearly to the right of the bad guy, the bad guy will still move to the left! The hero's X value was marked at $F0 as the threshold of this, and I'm not sure what the bad guy's is, but I think its anywhere from $2F and below he will start moving left.

[Kasumi]

Not 100% clear on what you're doing, but it seems like you want to be using bcs and bcc, not bmi and bpl.

Badguy is at $F0
Hero is at 0.

The bad guy is to the right of the hero.

$F0 - $00 = $F0, so the minus flag would be set.

Bad guy is at $F0
Hero is at $EF

The bad guy is still to the right of the hero, but...

$F0-$EF = $01, so the minus flag is not set.

Therefore, you can't use bmi and bpl to determine who's on the right.

BCS/BCC check for a wrap around zero. Let's see how that works for the above two examples.

Badguy is at $F0
Hero is at 0.

The bad guy is to the right of the hero.

$F0 - $00 >= 0, so the carry flag is set.

Bad guy is at $F0
Hero is at $EF

The bad guy is still to the right of the hero.

$F0-$EF >= 0, so the carry flag is set.

How about if hero is to the left of bad guy?

Bad guy is at $EF
Hero is at $F0

Hero is to the right of the bad guy.

Ignoring wrap around, $EF-$F0 < 0, so the carry would be clear.

So you can use bcc to determine if the hero is to the right,
bcs if the bad guy is to the right.

I hope that answers your question.

[CareerOfEvil]

Thanks a lot Kasumi. That did the trick! Looks like I need to go over a beginners tutorial in 6502... yet again...

[tokumaru]

My analysis is not as detailed as Kasumi's, but think about it this way: The N flag, which is used by BMI and BPL, is just a copy of the 8th bit of the 8-bit values the 6502 can work with. If this bit is treated as a sign (0 = positive, 1 = negative), the range of a byte become -128 to +127. However, the screen is 256 pixels wide, and 240 pixels tall, meaning that signed values are not big enough to represent coordinates in this space. Hence why you are getting invalid results.

So, for this particular operation, you need to use unsigned numbers, which range from 0 to 255, enough to cover the whole screen. BMI and BPL were designed for comparing signed numbers, and since your sprites do not move to negative coordinates you shouldn't be treating the results of the comparisons as if they were signed numbers. For unsigned numbers, BCC and BCS are used instead.

[Bregalad]

The N flag after a CMP/CPX/CPY instruction is like a huge mystery on the 6502.
It's result is the same as after a SBC instruction, but it doesn't have any useful value really. I've read on 6502 that the result of a comparison of signed numbers is the N flag XOR-ed with the V flag (can only done with SBC, because CMP/CPX/CPY doesn't touch the V flag). I'm not too sure though.

[tokumaru]

Uh... what are you talking about? The N flag indicates if the result of the comparison/subtraction is negative or positive, in case the compared values are also signed numbers (if they aren't, then yeah, the N flag is meaningless).

[Bregalad]

I was talking about this : viewtopic.php?f=2&t=8905&hilit=N+flag+CMP