Quote:
Originally Posted by retroben
Bits are in the same byte of an address.
8bits=1byte with ten placements.
The bits are as follows.
bit0? 0=0 neutral
bit1 1=1
bit2 2=2
bit3 4=4
bit4 8=8
bit5 10=16
bit6 20=32
bit7 40=64
bit8 80=128
bit9? FF=255 maximum (256th number including zero)
It can use any and every mixture of bits.
Example:bits 6,5,and 3 20+10+4=34 (52 in decimal).

Actually bits 6, 5, and 3 is 64+32+8, which is 104.
You said 52 which is only half of 104 because you got the bit offsets wrong.
First, there are only 8 bits in a byte, not 10.
There's no "bit8" and "bit9".
It's just bits 0 to 7, numbered littleendian.
Second, bit 0 is NOT "neutral".
2 to the power of 0 is 1, not 0.
So bit 0 means you mask  1,
bit 1 means you mask  2,
bit 2 means you mask  4,
etc. all your values are off.
Quote:
Originally Posted by retroben
007F in hex are the positive numbers.
80FF in hex are the negative numbers.
Couning down from FF.
Examples:
FF= 1
FE= 2
80= 127 (maximum negative)
7F= +127 (maximum positive)

This is true only if you assume two things:
 The corresponding integer storage is signextended (a "signed" int), to 8bit precision.
 The CPU processor registering the numbers uses two's complement negation.
If it were a CPU besides MIPS/Intel it could be 1's complement negation, and negative numbers would not look exactly as you said.
More over, for our purposes, either in hacking or otherwise, a "byte" in a memory viewer should always default to an "unsigned char" perspective in C, so rather than signextending it, we're better off initially interpreting memory results as zeroextended bytes in the range 0:+255, not 128:+127.
Quote:
Originally Posted by retroben
To think,I learned hex all on my own,not in school.

Doesn't surprise me. It's at least what I did.
I had to begin with reading about it at first, though, initially, in an archive I downloaded. Otherwise, how do we know exactly which knowledge to pursue?