Is there a good tutorial explaining how to do 2s compliment arithmetic on the 6502 when more than a single byte is needed?

Edit: for instance, how do I do 127+1 ?

_________________
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?

Let me do a worked example so you can tell me if bi have this correctwhat I want is:

127 -> 01111111 + 1->00000001 =
00000001 00000000

But the answer ADC will give me is 10000000, and the V flag will be set. Thus, it is up to me to interpret the V, C, and N flags after every addition/subtraction in order to "create" the bit pattern I want using software. Correct?

Your example is not correct, the result should be 128 which doesn't fit in a signed byte, so you need to decide what you want to do - either execute the addition at only 8 bits and accept that it overflowed to -128 (as the V flag indicates), or sign-extend the operands to signed 16 bits ($007F + $0001) and perform a 16-bit addition instead, which will give $0080 with V clear after the high byte addition. That's still 128 of course. Bit for bit, the arithmetic is the same as for unsigned numbers, except for the sign extension and use of the V flag instead of the C flag to detect overflow.

It's worth reading the pages Garth linked especially regarding the overflow flag.

_________________
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?

I've read the articles. While I'm sure the information is there, some things aren't clear to me. Sounds like it is indeed a 2s complement misunderstanding.

Let me ask this. As soon as I need to represent a number larger than 127, or smaller than -128, do I need to stop using "7 bit + sign bit" and turn my number into "15 bit + sign bit"?

My , apparently incorrect thinking had been that in order to represent numbers greater than 127 or less than -128, I would have multiple "7 bit plus sign bit" bytes. This of course would be quite a mess to deal with. Is the real method to just us the "word" length required?

If so, this makes the V flag more confusing to me. Tell me if this is correct. If I subtract a byte, and the result is less than 0x80, or I add and the result is greater than 0x7f, is that the criteria for V to be set? In other words, is the behavior dependent on whether I'm adding or subtracting?

Pseudo code demonstrating overflows in both directions would be super helpful.

_________________
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?

Going back to the worked example: The above code is intended to be educational, and as such is deliberately unoptimised.

With one caveat: ensure that the D (decimal) flag is clear when you execute this code... or you will be pulling your hair out.

Neil

Well, the 6502 doesn't support signed BCD anyway. In Decimal mode, all values are essentially unsigned, and you'll have to store an explicit sign flag if you want one.

Indeed. But it's not immediately obvious that that's the case. As you said, the difference between signed and unsigned is in the interpretation, not the representation.

Neil

Are you sure about that? With 10's complement, and values $50 and over being negative, we get sums like
33 + -48 -> $33 + $52 = $85 -> -15
The N flag is wrong, but otherwise it seems to work.

I'd say that if the N flag and V flag are wrong then it's not supported as such, as you need significant extra instructions to interpret the result.

In fact for BCD it might be better to use a whole extra byte for signed overflow detection. It is a bit clunky though.

Yes, if you want to be dealing with signed numbers

Indeed, that's a misapprehension - but useful to see you say it, because it tells us that there's something that needs to be explained.

FWIW: In a recent project I had to implement signed 16-bit arithmetic and decided to check for overflow because I think that's the right thing to do and for the first time in about 45 years of 6502 coding, I checked the overflow bit and used BVS:



there's no magic to multi-byte arithmetic and you only need to check for overflow on the highest bytes you add (or subtract - I use other means for multiply, divide and mod) but it adds a bit of completeness to it all and it sort of surprises me that it's taken so long for me to use that particular instruction.

Also interesting to note that this code (for a Basic interpreter) checks overflow when things like BCPL, C, etc. don't check at all and just wrap... I wasn't going to bother until I found some code producing odd results and it was overflowing that was the cause.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/