I need to convert the following hexadecimal representation of 2’s complement binary numbers to decimal numbers I am unsure if I am doing it correctly or am I missing a step?
a. xF0
b. x7FF
c. x16
d. x8000
My Attempt at first converting it to a Decimal then Binary:
a. xF0 = 240 = 11110000
b. x7FF = 2047 = 11111111111
c. x16 = 22 = 10110
d. x8000 = 32768 = 1000000000000000
If you put "two's complement" in the search box, you can find a great many questions and answers describing two's complement.
But I'll try to give a quick overview of hexadecimal vs. binary notation and two's complement.
Hexadecimal vs. binary
Converting between hexadecimal and binary numbers is actually extremely easy. You can do it by hand without any intermediate calculations. The key fact to remember is that one hexadecimal digit equals exactly four binary digits.
For example, $\mathrm d_{16} = 1101_2.$ (Subscript $16$ indicates a hexadecimal number, subscript $2$ indicates binary.) Similarly, $8_{16} = 1000_2,$ $7_{16} = 0111_2,$ and $1_{16} = 0001_2.$ (Notice that for the purpose of this conversion algorithm we always write four digits of the binary number.)
For multiple hexadecimal digits, we can convert to binary just by concatenating the four-bit equivalents: $$178\mathrm d_{16} = 0001\ 0111\ 1000\ 1101_2.$$ I've shown the binary number with spaces between the four-bit groups. Of course when writing the number normally you would probably close up those spaces, and you might omit the leading zeros. Just remember you can only omit leading zeros after concatenating the four-bit groups together.
Converting from binary to hexadecimal is just the reverse process. Group the bits of your binary number in four-bit groups, starting from the rightmost bit. Each group of four bits is replaced by the equal hexadecimal bit. So if we are given the binary number $1011110001101_2,$ we can write $$1\ 0111\ 1000\ 1101_2 = 178\mathrm d_{16}.$$
Two's complement
Mathematically, you can speak of a generic "unsigned" binary representation of non-negative numbers; you can use as many bits as you need to represent any non-negative integer you want. But there is no generic two's complement representation. There are only $n$-bit two's complement representations.
In the vast majority of current-day applications, $n$ is $16$ or $32,$ but it is sometimes $64$ or even $8.$ But $n$ does not have to be a power of $2,$ in principle, and in the past there were computers that stored integers using $n$ bits where $n$ was not a power of $2.$
The least number that can be written in an $n$-bit two's complement representation is $-2^{n-1}.$ The greatest is $2^{n-1} - 1.$ It is also possible to write any integer between those two values.
To write a non-negative integer in $n$-bit two's complement notation, provided the number is no larger than $2^{n-1} - 1,$ you simply write the number in binary and "pad" it on the left with $0$ digits until there are $n$ digits altogether. The number you start with cannot have more than $n - 1$ bits before the "padding," so the leftmost bit will always be $0.$
To write a negative integer, provided that it is no less than $-2^{n-1},$ the procedure that is usually recommended is to write the absolute value of the number as an ordinary binary number, "flip" all the bits (every $0$ becomes a $1$ and every $1$ becomes a $0$), and then add one. The leftmost bit of the result will always be $1.$
Mathematically, the $n$-bit two's complement representation of an integer $x$ for $-2^{n-1} \le x < 0$ is the same as the ordinary (unsigned) binary number equal to $2^n + x.$ In other words, compute $2^n + x$ using ordinary (unlimited bits) binary notation, and after you have written the result, declare it to be $n$-bit two's complement. This is an alternative to the "flip bits and add one" algorithm, and always produces the same result provided that your number is within the range that can be represented. It is clear that when the result is viewed as an unsigned number, is in the range $2^{n-1}$ to $2^n - 1,$ therefore it is always an $n$-bit binary number whose leftmost bit is $1.$
You're doing it correctly, but you're missing a step. You know how to obtain the unsigned value, but you're missing the next step that gives you the signed value.
Let's call $c$ the unsigned value, $\mathcal{L}$ the bit length and $n$ the signed value. Like Tony, I'm going to assume that a. and c. are supposed to be 8-bit, and b. and d. are supposed to be 16-bit. This means then that $\mathcal{L} = 8$ or 16. To get $n$ from $c$, you XOR $c$ with $2^\mathcal{L} - 1$, add 1 and then multiply by $-1$. Or much easier, $n = c - 2^\mathcal{L}$.
a. xF0 as an unsigned byte would indeed mean 240. But what does it mean as a signed byte? It's a very well chosen example for educational purposes, since, as Dave explains, each hexadecimal digit corresponds to four bits, and since xF is four bits on and x0 is four bits off, they "toggle" to each other (which is the same as what Tony called XORing with xFF), that is, xF0 toggles to x0F, and that means 15 in decimal. Now you add x01 to obtain x10, which is 16. So xF0 as a signed byte means $-16$. You can doublecheck by seeing that $240 - 256 = -16$.
b. If this is supposed to be a 16-bit word, e.g., x07FF, the sign bit is 0, so you're done. It's 2047, just like you said.
c. Whether this is a byte or a word, the sign bit is also 0 and you're done.
d. This one can be very confusing if you're the slightest bit dyslexic, so you have to take it step-by-step. Do x8000 XOR xFFFF to obtain x7FFF, which means 32767. Add 1 to obtain 32768 and multiply by $-1$ to obtain $-32768$. Verify this with the subtraction method: we have $c = 32768$ and $\mathcal{L} = 16$, so then $2^\mathcal{L} = 65536$, and therefore $n = 32768 - 65536 = -32768$.
Did d. feel circuitous and confusing, and make you question why we use two's complement at all and not some simpler method (such as just a sign bit without two's complement)? The answer is that we don't use two's complement, computers do. And for computers, two's complement solves two important problems: it ensures a unique representation for 0 and preserves the least significant bit as the parity bit. But I might be stepping on your teacher's toes with that, so I won't say anything more about it.
Lastly, I promised I would mention Programmer Mode in the Windows Calculator. I'm using Windows 8. In the Desktop app, I press Windows-R and type calc to invoke the Windows 8.0 Calculator 6.2. Then I switch from Scientific Mode to Programmer Mode by pressing Alt-3. (Or you can use the menu: View -> Programmer). You can set it to byte, word, double word ($\mathcal{L} = 32$) or quadruple word ($\mathcal{L} = 64$). Notice also the Xor button. To work through exercises a. through d. with the Xor button, use either the Dword or Qword setting. And then just to be extra sure, set it to Word and compute $-2 * 2$. Then repeatedly press Enter until you reach $-32768$. Take a look just a little bit below where it says $-32768$. Look familiar? And lastly, set it to Byte and compute $0 - 16$.
By the way, the Mac OS X Calculator also has Programmer Mode.
For my answer, I'm going to assume that a. and c. are supposed to be 8-bit, and b. and d. are supposed to be 16-bit.
There are just two steps. First, you XOR the number with FF or FFFF, and then you add 1. That's it.
So, with F0, you XOR with FF to get 15, and then you add 1 to get 16, so F0 means $-16$.
If you're still unsure, you can check with either your computer's calculator in Programmer Mode, or with an online calculator like http://planetcalc.com/747/ I'm sure there's a way to use WolframAlpha for this purpose, too.