Maybe this is obvious, but I'll ask in case I missed something.

I'm writing a chip8 emu to learn how emus work, and I've noticed a weird behavior on one of the games I'm trying (the TETRIS rom).

It sets an 8-bit register to 1F, and then later adds FF to the same register.

V[1] = 1F
...
V[1] += FF

Now I'm not sure how I should handle the overflow. Initially I had this:
1. add number to register
2. if register > 255, set to 255 and set the Carry Flag.

But this is cearly wrong since I get into an infinite loop (the rom tests for V[1] being equal to 0, but with the alg. above it will always stay at FF).

So what should I do? I would think that bits are added 1 by 1, and resets to 00 after reaching FF, but then my register would go back to 1F at the end.

Should I add the two values as integers, convert to binary, and then only keep the leftmost 8 bits? Or should I keep the rightmost?




[download a life]

This algorithm is used to decrease the counter by 1... I keep the rightmost values (the least significant bits), which, if I ignore the carry, results in the register decreasing by 1 at each iteration...

Amazing what a small piece of paper and the Windows calculator (in scientific mode) can do for you. :-)

Here's the breakdown:

1F  =   0001 1111 = 1F
FF  =   1111 1111
----------------- <- sum
11E = 1 0000 1110
 1E =   0000 1110 <- keep 8 least significant bits
 FF =   1111 1111
----------------- <- sum
11D = 1 0000 1101
 1D =   0000 1101
... etc ...




[download a life]

> Now I'm not sure how I should handle the overflow. Initially I had this:
> 1. add number to register
> 2. if register > 255, set to 255 and set the Carry Flag.

What you're describing is saturation: When a value overflows/underflows and is "clipped" to the maximum/minimum representable number. Saturated arithmetic is only present on some specialized hardware and instruction sets (MMX and other SIMD ISAs have support for it, for example.)

Normal arithmetic, as you discovered, is more useful and it also happens that when implementing ALUs in hardware, it is the natural way things occur (bits carried out of the register are simply lost -- or an extra bit is used to calculate status flags.)

> This algorithm is used to decrease the counter by 1... I keep the rightmost
> values (the least significant bits), which, if I ignore the carry, results in
> the register decreasing by 1 at each iteration...
>
> Amazing what a small piece of paper and the Windows calculator (in scientific
> mode) can do for you. :-)
>
> Here's the breakdown:
>
> 1F = 0001 1111 = 1F
> FF = 1111 1111
> -----------------
> [download a life]
>

Not sure if this helps but since ARM is very bad as handling words and bytes, for Cyclone I went for the strategy of pushing up everything to the TOP 8 bits of the 32 bit registers and doing the sum.

e.g. to calculate 0x12 + 0x34 I would calculate 0x12000000+0x34000000

Works fine and sets all the right bits (NZVC), except when you get to SBC and ADC...


Newsdee's Love, Glory, and Discussion Boards

BartT:
Heh, so I wasn't SO far off after all with my first idea. Interesting that some processors handle it like that.

Dave:
Good to know, that's an interesting way to make a fast addition, using the host's own overflow handling...




[download a life]

> BartT:
> Heh, so I wasn't SO far off after all with my first idea. Interesting that some
> processors handle it like that.

Well, actually, you _were_ pretty far off ;) No processor handles standard arithmetic that way but some modern ISAs have support for saturated arithmetic as it happens to be useful for multimedia processing.