Emulation and Testing of Overflow Conditions

Topics pertaining to the emulation or simulation of the 65xx microprocessors and their peripheral chips.
Post Reply
gmcastil
Posts: 25
Joined: 19 Mar 2017

Emulation and Testing of Overflow Conditions

Post by gmcastil »

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:

Code: Select all

for A in range(0, 256):
    for B in range(0, 256):
        carry_in = 1
        # Add with carry
        C, carry_out, overflow = add(A, B, carry_in)
        if not A[7] and not B[7] and carry_in:
            assert C[7] == 1
            assert overflow == 1
            assert carry_out == 0
        else if A[7] and B[7] and not carry_in:
            assert C[7] == 0
            assert overflow == 1
            assert carry_out == 1
        else:
            assert overflow == 0
    
        assert C == A + B
        if C > 255:
            assert carry_out == 1
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.
User avatar
barrym95838
Posts: 2056
Joined: 30 Jun 2013
Location: Sacramento, CA, USA

Re: Emulation and Testing of Overflow Conditions

Post by barrym95838 »

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.
Last edited by barrym95838 on Sun Nov 05, 2017 7:59 pm, edited 1 time in total.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Emulation and Testing of Overflow Conditions

Post by BigEd »

(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.)
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Emulation and Testing of Overflow Conditions

Post by BigEd »

(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
gmcastil
Posts: 25
Joined: 19 Mar 2017

Re: Emulation and Testing of Overflow Conditions

Post by gmcastil »

Thanks Ed.
Quote:
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
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.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Emulation and Testing of Overflow Conditions

Post by BigEd »

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.
gmcastil
Posts: 25
Joined: 19 Mar 2017

Re: Emulation and Testing of Overflow Conditions

Post by gmcastil »

Quote:
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).
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Emulation and Testing of Overflow Conditions

Post by BigEd »

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.
Post Reply