Working on a 6502 ALU implementation and wanted to see if I could get another pair of eyeballs on my method of simulating overflow behaviour during an addition operation. In pseudocode, I was planning to use the following:



For brevity, I'm not showing the case with the carry value set to 0. Does it look like I've captured the right conditions? The value of C at the end doesn't look correct to me, but I'm not sure what it should be. Also, does the output of the ALU always contain the binary sum of A and B, regardless of what the programmer might have intended? In other words, is it always the programmer's responsibility to determine the results based on what they knew when they added or subtracted something?

Thanks.

The 6502 ALU is not able to handle 256 for either input. C is intended to indicate unsigned overflow, and V is intended to indicate signed overflow. The ALU doesn't know or care whether the programmer intended to perform signed or unsigned addition ... it just provides a useful (but not necessarily correct in an 8-bit-wide sense) result and tells the programmer whether or not the result is correct in a signed sense (with V==0) or an unsigned sense (with C==0 for ADC and C==1 for SBC).

I don't know Python (?), but I can provide some ADC (and SBC) pseudo-code:

Allocate six boolean flags (N, V, C, Z, J, K), each containing at least one bit
Allocate an (unsigned) output register R which contains at least 9 bits
Allocate two (unsigned) input registers A and Operand which contain exactly 8 bits
(R, J, and K can be "local")

# SBC
Let Operand = ~Operand

# ... fall through to our ADC code

# ADC
Let R = A + Operand
If C then let R += 1
Let J = (A > 127)
Let K = (Operand > 127)
Let A = R & 255
Let N = (A > 127)
Let V = (!J && !K && N) || (J && K && !N)
Let Z = (A == 0)
Let C = (R != A)

Mike B.

P.S. The above pseudo-code is completely ignorant of BCD mode.

(There's one small unexpected thing in Python, Mike, and that's range(0,n) giving you numbers from 0 to n-1. So the for-loops do actually run from 0 to 255 here.)

(I'm being lazy here by redirecting instead of thinking...)

Two great resources on the 6502 overflow flag:
http://www.6502.org/tutorials/vflag.html
http://www.righto.com/2012/12/the-6502- ... ained.html

I think it's worth having a look at the code in one or more 6502 emulators, to puzzle out what they do and how they do it, secure in the knowledge that they are doing what the 6502 does. For example:
https://github.com/davidgiven/cowgol/bl ... 502.c#L176
https://github.com/mnaberez/py65/blob/1 ... 02.py#L293

Thanks Ed.



Yep, I've read through both of those. In fact, I used the table from Ken Shirriff's blog to help construct the logic for the overflow flag that I've implemented in my ALU. What I think I'm a little confused about is trying to figure out what the result from the ALU will be when I add two numbers that trigger an overflow condition.

Another thing that really has me confused is on signed vs. unsigned addition. The ALU doesn't know anything about signed vs. unsigned addition right? I just adds the numbers and leaves it up to the programmer to know what they sent in. Is this correct?

Thanks.

That's right. It's the joy of two's complement: the bit patterns do exactly the same in both cases. Which might also answer your question about overflow: the adder doesn't need to know or do anything about overflow, it just adds. The overflow bit is purely an additional output.

Ok, that helps a lot. That's exactly how I'm treating the overflow bit, as an additional output (carry bit as well). So if I want to determine what the ALU should return as a result of an add, I can just add them and then ignore anything but the lower 8-bits then (assuming I understand you correctly).

Yes, I think that's right: the ALU output is exactly the lower 8 bits, and the carry output is exactly the next bit up. It's only the overflow which is a derivation of what happened in the addition.