levellength+1 is 4... so cameraposition would have to be big enough to reach 768... my logic doesn't work well right now.

Where is levellength+1 even coming from? You've used it in both your posts, and I'm not seeing it. Also 4 (in the examples I gave) would mean your level is only 4 pixels wide. If you're saying that's the number of screens across your level is, your levellength (following my example) is really 4*256 (1024) pixels, and your cameraposition/ladyposition have to be two bytes to hold that large a number.

Quote:

...I remember that cmp would work because it acts just like subtraction only it discards the answer... and that would be fine... the carry would still be cleared.

No, you cannot use cmp for 16bit numbers (which you'll need for scrolling past more than one screen) because cmp also ignores the state of the carry before the operation.

Edit: (Disclaimer: You can totally use cmp for 16 bit numbers with branches and such, but it's more work for probably no gain in this case.)

Code:

lda #$00clcsbc #$00;Carry is clear

Code:

lda #$00clccmp #$00;Carry is set.

This will affect the higher bytes of all subtractions greater than 8 bits, so you must use sbc.

levellength+1 is 4... so cameraposition would have to be big enough to reach 768... my logic doesn't work well right now.

Where is levellength+1 even coming from? You've used it in both your posts, and I'm not seeing it. Also 4 (in the examples I gave) would mean your level is only 4 pixels wide. If you're saying that's the number of screens across your level is, your levellength (following my example) is really 4*256 (1024) pixels, and your cameraposition/ladyposition have to be two bytes to hold that large a number.

When I added the +1 at the end... that +1 means levellength is a two byte variable. I don't know if I also knew that cameraposition/ladyposition would have to be two bytes to hold that large a number. You should know that levellength+1 could be used for your subtract 256... decrement levellength+1 by 1.

I appreciate your helpfullness ...and I'm sorry for using +1 to mean my variable is the high byte.

I was just interpreting it as an addition to a value rather than address. No need to be sorry. I just always only see things one way.

tepples wrote:

To compare large numbers, try using cmp for the first and sbc for the rest.

YO!!!! That made my evening, I can use that in quite a few places! I concede, it's not more work to do that at all.Edit2: I really can't thank you enough. Off topic, but you caught me in the middle of rewriting some object collision/interaction stuff and I can now save a small amount of time in subroutines that will be run many times per frame.

Quote:

Why does the state of the carry before the operation matter?

Because the sbc/adc (but not cmp) take the carry before the operation into account.

Code:

lda #$00secsbc #$00;Result is #$00 with set carry.

Code:

lda #$00clcsbc #$00;Result is #$FF, with clear carry.

And then the second subtraction of the 16 bit number needs to take the result of the carry from the first into account. (which cmp doesn't do.)

Quote:

No I do not understand.

Edit: Because I don't think things through sometimes. It should be this:

Which will make infinitely more sense, because what I posted before will not work at all. My logic here was sound, but what I wrote in 6502 wasn't that logic... Not thinking, not debugging, etc... I'm sorry. I kind of look forward to these posts, but then, sometimes... I hurt more than help.

Also, this does not include the "If cameraposition > levellength -256, cameraposition = levellength-256."

To compare large numbers, try using cmp for the first and sbc for the rest.

YO!!!! That made my evening, I can use that in quite a few places! I concede, it's not more work to do that at all.Edit2: I really can't thank you enough. Off topic, but you caught me in the middle of rewriting some object collision/interaction stuff and I can now save a small amount of time in subroutines that will be run many times per frame.

sbc is the same as cmp in cycles use... so after looking at tepples post again I'm guessing you save (don't require) an sec. Is that correct?

I'm still confuzzled about:

Kasumi wrote:

Quote:

Why does the state of the carry before the operation matter?

Because the sbc/adc (but not cmp) take the carry before the operation into account.

Code:

lda #$00secsbc #$00;Result is #$00 with set carry.

Code:

lda #$00clcsbc #$00;Result is #$FF, with clear carry.

And then the second subtraction of the 16 bit number needs to take the result of the carry from the first into account. (which cmp doesn't do.)

I can see what happens but my brain is missing the why. Lunch... (I'm going to come back to this... and honestly I am excited about learning about the carry and math. )

Which will make infinitely more sense, because what I posted before will not work at all. My logic here was sound, but what I wrote in 6502 wasn't that logic... Not thinking, not debugging, etc... I'm sorry. I kind of look forward to these posts, but then, sometimes... I hurt more than help.

Aw... you are very kind! Look forward to these posts. I appreciate your honesty and apology and I don't think you hurt more than help. : )

Kasumi wrote:

Also, this does not include the "If cameraposition > levellength -256, cameraposition = levellength-256."

sbc is the same as cmp in cycles use... so after looking at tepples post again I'm guessing you save (don't require) an sec. Is that correct?

This is correct. Although, sometimes you can avoid the sec anyway, even when using sbc. What matters is not that sec is used, just that the carry is set.

Code:

bcc somewhere;If we're here, we didn't branch, so the carry is set.lda variable;sec;Not needed right here, because we can guarantee the carry is already setsbc variable2;somewhere:

Stuff like this is why it takes forever for me to write code. I think I like optimizing more than getting things working. *shrug*

Quote:

I can see what happens but my brain is missing the why

I'm not sure I can explain that stuff better than the guides, but apparently I'm giving it a shot. Check the 6+5 = 11 on this poster: http://www.abcteach.com/documents/poste ... elem-24639 (It's kiddy, but it actually shows what I want to show)The orange 1 is basically like the carry bit. For the tens place, it's adding 0+0. PLUS CARRY (1 in this case)! If you were adding 4+5, the tens place would add 0+0. PLUS CARRY (0, in that case! Because 4+5 doesn't carry to the tens place.)

So when you add on the 6502 with adc, you are always adding the two numbers. PLUS CARRY! It just carries over to the next byte when it overflows, instead of the next place when you run out of digits.

This is why you clear the carry before most additions. If you don't, you will add an extra one if the carry was set!

Code:

00|FF (the | separates the two bytes into "places" like the one and tens place in the decimal addition example)+00|01------ 01|00

You'll notice for the high bytes, you're doing 00+00, just like for the tens place in that example poster. But, like in the example poster, the addition of the lower place causes an overflow. FF+01 is greater than 255, so the carry ends up set. 5+6 is greater than 9, so you end up carrying one.

Anytime you add a number and result would have been greater than the byte can hold, the carry is set. Otherwise it is cleared.

For clarity: ADC will always set/clear the carry based on the result of the addition. See this code:

Code:

seclda #$00adc #$00;Carry is cleared.

The carry is not "left alone" (In this case, it does not stay set) if there was no carryover. If there was no carryover, it is clear. If there was, it is set. Nothing else.

This ensures that when you add the higher bytes (places) of the number, they get the correct result. This is why you DO NOT change the carry between operations that are part of the same multi byte add or subtract. The previous operations will make the carry right (whether there was a carry or not) and you don't have to worry about it to get the right result.

Now... subtraction is a bit different. It subtracts the two numbers and the OPPOSITE of the carry. So when the carry is set (1), it will just subtract one number from the other. When the carry is clear (0), it will subtract one number from the other, AND an additional one.

The way I used to remember it... If the carry is opposite what you would normally set it to before that operation, that's when you get the extra one. (You clear the carry before addition, so when it's set it adds one more. You set the carry before subtraction, so when it's clear, it subtracts one more.)

Three things to take away:1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction)2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to.3. If the carry is the opposite of what you would normally initialize it to, one extra will be used in the operation. (One extra will be subtracted for sbc, or one extra will be added for adc.)

That's really all there is to it. The rest is the "why" behind it. With the knowledge, you can do fun stuff like this:

Code:

bcc somewhere;The carry is set because we didn't branch;We want to add eight to the accumulator;clc;We could clear the carry;adc #$08;And add 8.adc #$07;Or... we could add 7. Because we know the carry is set, and 7+1 is eight.

But... don't do stuff like that in your game until you're really sure about it. If you understand it why it works, though, you've got a handle on the carry.

I really do look forward to these posts. This is my favorite section of the forum, and I always feel bad when I mislead people.

sbc is the same as cmp in cycles use... so after looking at tepples post again I'm guessing you save (don't require) an sec. Is that correct?

This is correct. Although, sometimes you can avoid the sec anyway, even when using sbc. What matters is not that sec is used, just that the carry is set.

Code:

bcc somewhere;If we're here, we didn't branch, so the carry is set.lda variable;sec;Not needed right here, because we can guarantee the carry is already setsbc variable2;somewhere:

Stuff like this is why it takes forever for me to write code. I think I like optimizing more than getting things working. *shrug*

Quote:

I can see what happens but my brain is missing the why

I'm not sure I can explain that stuff better than the guides, but apparently I'm giving it a shot. Check the 6+5 = 11 on this poster: http://www.abcteach.com/documents/poste ... elem-24639 (It's kiddy, but it actually shows what I want to show)The orange 1 is basically like the carry bit. For the tens place, it's adding 0+0. PLUS CARRY (1 in this case)! If you were adding 4+5, the tens place would add 0+0. PLUS CARRY (0, in that case! Because 4+5 doesn't carry to the tens place.)

So when you add on the 6502 with adc, you are always adding the two numbers. PLUS CARRY! It just carries over to the next byte when it overflows, instead of the next place when you run out of digits.

This is why you clear the carry before most additions. If you don't, you will add an extra one if the carry was set!

Code:

00|FF (the | separates the two bytes into "places" like the one and tens place in the decimal addition example)+00|01------ 01|00

You'll notice for the high bytes, you're doing 00+00, just like for the tens place in that example poster. But, like in the example poster, the addition of the lower place causes an overflow. FF+01 is greater than 255, so the carry ends up set. 5+6 is greater than 9, so you end up carrying one.

Anytime you add a number and result would have been greater than the byte can hold, the carry is set. Otherwise it is cleared.

For clarity: ADC will always set/clear the carry based on the result of the addition. See this code:

Code:

seclda #$00adc #$00;Carry is cleared.

The carry is not "left alone" (In this case, it does not stay set) if there was no carryover. If there was no carryover, it is clear. If there was, it is set. Nothing else.

This ensures that when you add the higher bytes (places) of the number, they get the correct result. This is why you DO NOT change the carry between operations that are part of the same multi byte add or subtract. The previous operations will make the carry right (whether there was a carry or not) and you don't have to worry about it to get the right result.

Now... subtraction is a bit different. It subtracts the two numbers and the OPPOSITE of the carry. So when the carry is set (1), it will just subtract one number from the other. When the carry is clear (0), it will subtract one number from the other, AND an additional one.

The way I used to remember it... If the carry is opposite what you would normally set it to before that operation, that's when you get the extra one. (You clear the carry before addition, so when it's set it adds one more. You set the carry before subtraction, so when it's clear, it subtracts one more.)

Three things to take away:1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction)2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to.3. If the carry is the opposite of what you would normally initialize it to, one extra will be used in the operation. (One extra will be subtracted for sbc, or one extra will be added for adc.)

That's really all there is to it. The rest is the "why" behind it. With the knowledge, you can do fun stuff like this:

Code:

bcc somewhere;The carry is set because we didn't branch;We want to add eight to the accumulator;clc;We could clear the carry;adc #$08;And add 8.adc #$07;Or... we could add 7. Because we know the carry is set, and 7+1 is eight.

But... don't do stuff like that in your game until you're really sure about it. If you understand it why it works, though, you've got a handle on the carry.

Yes, I understand everything well; it is written very well. Great job Kasumi! Even your last code example... I was suprized you quoted your code... but suddenly I was happy to see those comments... it was a really cool experience! (:THANK YOU KASUMI!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Kasumi wrote:

I really do look forward to these posts. This is my favorite section of the forum, and I always feel bad when I mislead people.

Also, this does not include the "If cameraposition > levellength -256, cameraposition = levellength-256."

Ok well I copied your code and wrote my questions:

Code:

lda ladypositionlowsecsbc #128;#$80sta camerapositionlow

lda ladypositionhigh ;why do you load ladypositionhigh here?sbc #$00;High byte of $0080 ;<-- what does this comment mean?sta camerapositionhighbcs abovezero ;I understand this... it is going to a place where cameraposition > 0lda #$00 ;I also understand these... cameraposition = 0sta camerapositionhighsta camperapositionlow

abovezero:;Can be optimized in cute ways... ^_^

edit: Well... I looked at this some more and want to say that I notice you aren't using sec before my first question line... so that 128 would be the low... and 00 would be the high... I still don't understand, I'm thinking... but Yes I dont understand.

Because ladyposition is one number stored in two bytes. If you want to subtract a number from it, you have to subtract both bytes of that number from both bytes of ladyposition. If you don't also subtract from the high byte, it's going to end up wrong when the low byte wraps. This is 16 bit subtraction.

Quote:

sbc #$00;High byte of $0080 ;<-- what does this comment mean?

We're subtracting 128. 128 is $80 if you use one byte. 128 is $0080 if you use two bytes. So the high byte for 128 is $00.

Let's pretend ladyposition is $00FF or 255 (so ladypositionlow is #$FF and ladypositionhigh is #$00) in the above add one example.Use what you've learned about the carry to see how ladyposition gets to $0100 or 256. (so ladypositionlow is #$00 and ladypositionhigh is #$01). Does it make sense? Then see how it goes to $0101. The carry is what allows one byte to overflow into the next without branching.

That's how you do 16bit math. I'm not prepared to write a huge post on it at the moment, though.

Because ladyposition is one number stored in two bytes. If you want to subtract a number from it, you have to subtract both bytes of that number from both bytes of ladyposition. If you don't also subtract from the high byte, it's going to end up wrong when the low byte wraps. This is 16 bit subtraction.

Quote:

sbc #$00;High byte of $0080 ;<-- what does this comment mean?

We're subtracting 128. 128 is $80 if you use one byte. 128 is $0080 if you use two bytes. So the high byte for 128 is $00.

Let's pretend ladyposition is $00FF or 255 (so ladypositionlow is #$FF and ladypositionhigh is #$00) in the above add one example.Use what you've learned about the carry to see how ladyposition gets to $0100 or 256. (so ladypositionlow is #$00 and ladypositionhigh is #$01). Does it make sense? Then see how it goes to $0101. The carry is what allows one byte to overflow into the next without branching.

That's how you do 16bit math. I'm not prepared to write a huge post on it at the moment, though.

I am going to understand 16bit math; thank you for answering me.

edit: Yes that makes sense. Now I must apply what I've learned. Give me a while to do this. It is 1:56pm n0ow.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum