Jenny's Hobby Farm

Jenny's Hobby Farm Home Page

I (Jenny ) used to be an assembler language programmer back in the days of the dinosaurs, nearly 50 years ago. I have written these pages for anyone who is now trying to learn the hex system of numbers that I used to have to interpret on a regular basis in the old days.



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:


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 single 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=1 byte -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. Then 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 2-digit hex code for all the decimal numbers, (0 - 9), all the small letters, all the capital letters, commas, periods and many other characters. The F is in front of the 3 (F3) to represent the decimal number 3 because they wanted to have a 2-digit hex number to represent each character and decimal 3 is only one digit.

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, firstly into hex and then into binary. Take for example a line of code:

AP    store1,store2

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 an aggravating problem in one of my programs.


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.