A LITTLE BIT OF HISTORY
When computers were first designed, a numbering system had to be found that only employed two digits. Binary was the logical choice, being made up of only 1's and 0's.
See
Learn to count in hex and binary
It was easy to represent two states physically, but more than two was difficult.
They could use:
- A small flat magnetic disc could have either a North Pole (1) or a South Pole (0)
- A Charge could be either positive (1) or negative (0)
- A Switch could either be On (1) or Off (0)
The invention of bits and bytes
The memory in the original computers was sequential, and if you got a print-out (there were no monitors in those days) of the memory in binary it was a very long string of 1's and 0's all over the page. It did not mean too much to anyone.
Someone came up with the idea of calling a sinlge binary digit a 'bit' and grouping 8 of them together and calling them a 'byte'. If you take 8 binary digits together, the largest number that you can make out of them is 255.
| 8 bits=1byte
|
Hex Equivalent
|
Decimal Equivalent
|
| 1111 1111
|
FF
|
255
|
Conveniently, each half byte is equal to F in hex, and a whole byte is equal to FF in Hex. Now when you got a print out of the memory, (called a core dump) it was relatively easy to read, because it was a string of hex numbers from 0 to F instead of just 1's and 0's.
For example:
Hex F3 = decimal 3
Hex F5 = decimal 5
Hex C3 = the letter 'c'
Hex C4 = the letter 'd'
Since one byte could contain up to 256 hex numbers (remember 0 is also a number) you were able to have a hex code for all the decimal numbers,(0 - 9), all the small letters, all the capital letters, commas, periods and many other characters.
You are probably asking why anyone would want to read the memory anyway.
I used to program in IBM Assembler language in the early 1970's. This language is so close to binary, that it was possible to translate what you had written into first hex and then binary. Take for example a line of code:
AP means "add"
When the compiler translated this instruction so that the computer could read it, the translation would look like the following:
"E5" = AP (I can't remember the code, it probably wasn't E5 but some other hex number)
"CA35E8" = the address of the location in memory of store1
"C35BB7" = the address of the location in memory of store2
This intruction says "add whatever is in storage location 2 to whatever is in storage location 1 and put the answer in storage location 1"
If you were having a problem with your program, you could request a core dump (print-out of memory). Then you could look up the addresses of the storage locations of 'store1' and 'store2', and see what was in them. Suppose they both contained nothing but zeroes when they should have had someone's pay. That told you that your problem was before this instruction.
I have had to resort to reading a core dump many times to find a problem in one of my programs.
A little bit of Trivia
When I was working on the old dinosaurs in the early 1970's, the total memory was 64K bytes per computer. We wrote all the data processing software, (payroll, accounts, sales etc.) for a division of the largest company in England on just 2 of these computers! We used punched cards, tape and disc for input and output, and you could also get printed output. There were no monitors in those days. The tape looked like a large spool of film, and the discs were a stack of 8 discs about 12 or 15 inches in diameter, and about 8 to 12 inches high, enclosed in a plastic case like a cake display case. They still use a stack of 8 discs today for your hard drive, but it is much smaller in physical size than the original ones, and holds millions of times more memory
