Since we're on a binary kick...
An 8-bit data field can contain 2
8 = 256 possible values. What these values actually
represent depends on your system.
Using that byte as an unsigned integer, you have the possible values [0, 2
8 - 1] == [0, 255]. In this system, the value 0 is represented by the bit pattern 00000000, and the value 255 is represented by 11111111.
Life gets more complicated with
signed integers, or values that could be negative as well as positive. The simplest version is to use the highest bit as a 'sign bit' - anything of the form 0xxxxxxx is positive, while 1xxxxxxx represents a negative number. The problem is, the byte "00000000" and "10000000" mean "0" and "-0", which means you're wasting space.
There's also the issue of overflow and addition errors. The number 01111111 represents +127 in this system. Add 1 to it, and you get 10000000, which represents -0. Add 1 to this, and you get 10000001, representing -1. As a result, you need a separate handler for adding/subtracting from a negative number.
The solution? The
Two's Complement representation. There's a bunch of marginally-complex math behind it, but basically, +127 is represented as 01111111, while 10000000 represents -128. This increases to 11111111 representing -1, and good old 00000000 representing 0. As a result, two's complement supports values in the range [-2
7, 2
7 -1] given 8 bits of data.
Long story short, this is why some old games have values that go up to 255, while others cap out at 127. The guys using 127 are using signed integers, meaning they have potential support for negative values too.