I am trying to really nail down how overflow works. If you add 2 signed numbers and the result should be >127 or <-128 this will cause an overflow (kinda like carry for an unsigned number more than 256).

I have been reading this: http://www.righto.com/2012/12/the-6502- ... ained.html In it, there is an example where -48+-112=96.
So, we have 10010000 + 11010000 = 01100000 = 96, something is carried from 7th to 8th bit so C is set. The bit carried into 7 is different from whats carried out, so V is set.

Then, there is an example where 80 + 80 =-96.
So, we have 01010000 + 01010000 = 10100000 = 96, nothing is carried from 7th to 8th bit so C is not set. The bit carried into 7 is different from whats carried out, so V is set.

My question is how do we go from these wrong answers to the correct ones? For example one if we put the overflow bit in front ( like 1 01100000 ) we get the correct answer: -160. If we do that for the 2nd example ( 1 10100000 ) it is still incorrect. Can anyone please help?

Thanks

EDIT: got my carry flags mixed up

Without specifically answering your question, allow me to direct you to the following excellent tutorials by 6502.org's own Bruce Clark.

The Overflow (V) Flag Explained

Beyond 8-bit Unsigned Comparisons


-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Also, see here.

Cheers,
Dieter.

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

Thanks for the response!
I've been reading through these just now and I am still quite confused sadly. I think I understand that it's telling you how the result is outside of -127 and 127, it's just how you can do something practical with that information I am unsure of. It seems that If I did a calculation that set V=1, is it simply trying to tell me to go back and redo it with a 16-bit number instead? There isn't a way to recover the 'real' answer?

It's an interesting question -although an odd one, because you end up with a signed 9 bit number, not something you'd usually see.

I think I'd try to answer it by drawing up a table - there are only so many ways that two 8 bit numbers can combine with overflow set.

I would very much recommend working in hex though - using binary and decimal adds to the mental burden, I think.

I think maybe I've got myself confused over something that maybe doesn't matter to much then haha I have been thinking of the Overflow flag as a way to "fix" the error - is that maybe not the best way to think of it? Is it just rather a way to tell you there has been an overflow, and it is not offering any particular solution? It's then up to you to decide what to do



Can you maybe expand on this a little? Do you mean it reduces the burden just because its a more human-readable format, or because we are using them as unsigned numbers, and therefore we cannot overflow?

Thanks!

_________________
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 haven't tested my idea thoroughly, but what the heck, I'll share it anyway and let you guys shoot holes in it if it turns out to not be bullet-proof. When the V flag sets as the result of a signed add or subtract, this is an indication that the twos complement result cannot fit properly in the 8-bit accumulator. However, the correct result will always still fit properly in nine bits, and this 9-bit twos complement result can be utilized by simply appending the C flag to the high end of the accumulator as the "ninth bit".

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I think that idea ought to be tested, Mike! The difficulty in my mind is that you didn't start with two signed 9 bit numbers, so bit 7 (the eighth bit) carries a different meaning. It still might be that you're right.

For test cases I'd suggest numbers like $00, $01, $02, $7E, $7F, $80, $81, $FE, $FF. And I'd look separately at addition and subtraction. ($80 is a difficult case because it can't be negated.)

But indeed Andrew, using hex one can readily see what's happening with bits 6 and 7, and whether the numbers are large or small. Well, with a bit of practice, but it's worth getting to that stage.

I think, in most cases, if you have signed 8 bit numbers and you see unexpected overflow, you have an exception, so your calculation should fail and you should revisit your program. Perhaps sometimes you could detect overflow and produce a saturated result - but I expect you'd need to check the signs of your inputs to figure out what that result should be. And, again, treat addition and subtraction separately.

Signed overflow occurs when the sign bits of the addend and augend are the same, but the sign bit of the result is different. This is what the V status bit indicates.

I took a very quick look at it, and it looks like it does come out as a 9-bit signed number if an 8-bit operation overflows, but I only looked at one test case:
This seems to indicate that it does come out as a 9-bit signed number if it overflows the 8 bits of the accumulator(which would make the term "overflow" very appropriate).
But even if this holds for all overflows, I don't think that treating it as a valid signed number is all that useful in practice. It would require a whole extra byte to store, which is rather wasteful, and you'd have to handle that extra byte, so at that point, it's probably easier just to use 16-bit 2s-complement.

I'll admit I'm intrigued by the question, and it would be nice if Mike's simple suggestion is the whole truth.

But I do agree that the ninth bit would seem to be of limited use. Perhaps it makes it much easier to implement saturating arithmetic?

I just looked up saturating arithmetic(Wikipedia page for if anyone else hasn't heard the term before). Seems like it could be very useful in some situations.
Almost trivial to implement, too. V indicates whether you clamp the value or not, and C tells you whether you clamp it to the positive or negative limit.
Assuming it holds, of course...

Hey, even a blind old dog might sniff out a bone once in a while. If true, it should allow an easy run-time "promotion" from 9-bit to 16-bit as well (no time for a code example ... gotta get to work).

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

For instance, when implementing a PID controller with your computer, and you are adding the partial sums with, let's say, 32 Bit fixed point math:
before writing the result into a 16 Bit D\A converter with a +10V\-10V output range, you need to limit/clip the result to +32767 (+10V) and -32768 (-10V).

Else, if your 32 Bit result would be, for instance, +32768 (+10.0003V), that's hexadecimal $00008000.
For the 16 Bit D\A converter, it would be just $8000, that's -32768 decimal, so it would give out -10V (a big negative voltage instead of a big positive voltage),
and your servo loop would have a tendency to sometimes go "off track" for no appearent reason.