Written by Harry Fairhead   
Friday, 15 January 2021
Article Index
Without Counting
Hex For Data

Without counting

Being able to count in hex is a great way to understand the how the system works but it isn't much use when you are confronted with a message such as




To really feel at home with hex you have to be able to understand it in a slightly different way. You certainly have to be able to convert hex to decimal and vice versa but there is something deeper.

First, though, how do you convert hex to decimal?

There are a number of standard algorithms that can be used to convert between different number bases but I have to admit that I prefer a more primitive approach. The place values used in hex are:


Hex 1000 100 10 1
Decimal 16*16*16 16*16 16 1
4096 256 16 1


and you can use these to work out the equivalent decimal value quite easily.

For example, AD45 is simply:

A*4096 + D*256 + 4*16 + 5*1

to express it in a mix of hex and decimal, or moving entirely to decimal:

10*4096 + 13*256 + 4*16 + 5*1

which works out to:

40960 + 3328 + 64 + 5



To convert from decimal to hex is just a little more complicated in that you have to discover how many lots of 4096, 256 and 16 there are in a number. For example, 44357 contains 10 lots of 4096 because:

44357/4096 = 10.83

The remainder, i.e.


is 3397 and this contains 13 lots of 256 because:

3397/256 = 13.27

and so on to discover that the remainder contains 4 lots of 16 and 5 units. Writing 10 lots of 4096, 13 lots of 256, 4 lots of 16 and 5 units in standard hex gives AD45.

Fortunately it isn't often that you have to convert decimal to hex!



Why is hex useful?

So far, using hex for a number looks as if it might be some sort of intellectual game or something that examiners can use to set a good question. Programmers are, as a group, fairly lazy and you can bet that they wouldn't make use of something if it didn't make life easy.

There are two ways in which hex makes life easier.

The first is that it can be used to write down very large integers in a compact form.

For example, AD45 is shorter than its decimal equivalent 44357 and as values increase the difference in length becomes even more pronounced.

This `short form' is really only a minor benefit compared with the second reason why we use hex.

Hex values are closely related to binary values and powers of two.

For example, 1KByte of memory is 1024 bytes in decimal. If you address each memory location in decimal the address range is 0 to 1023. In hex 1KByte is 400 bytes and the address range is 0 to 3FF.

This is quite interesting but you begin to see the pay off when you look at the problem of addressing say 64KBytes which in decimal is 65536 but in hex is simply 10000 bytes. The equivalent addressing ranges are 0 to 65535 in decimal and 0 to FFFF in hex.

The following table shows how much simpler these commonly used values and ranges look in hex: 

Memory sizes

Bytes Hex Address range
16 10 0 - F
256 100 0 - FF
1K 400 0 - 3FF
4K 1000 0 - FFF
64K 10000 0 - FFFF
1M 100000 0 - FFFFF
16M 1000000 0 - FFFFFF


If you look at this table you will notice that 1KByte stands out like a sore thumb as not being a nice hex number. The reason is that 1KByte is a strange unit of memory that has received attention just because it is close to 1000 decimal, i.e. 1024 bytes . It is more natural for the size of memory to double at each step because adding an additional hardware addressing line allows you to work with twice as much memory. This is the reason that the numbers that keep on occurring are always powers of two and hex is particularly good at representing powers of two in a nice neat format.

Practical hex

Now you can begin to see why hex is used so much to report addresses and data. In the case of an address the hex form tells you immediately what area of memory is concerned.

For example, if an error message talks about location EF10 then you should be able to figure out that it is an address in the first 64K, somewhere close to the top.

To really make use of such information however you need to be able to use a debugger to look at that area of memory and step through it a chunk at a time.

Of course being able to do this sometimes means being able to perform hex arithmetic. Not many people are any good at adding and subtracting hex numbers so most debuggers will do this for you and Windows calculator has a hex mode. In the old days programmers, usually assembly language programmers, often had pocket hex calculators - yes a real calculator that worked in hex. Assembly language programmers thought in hex. 

And yes I knew things had gone too far when I realized I'd just written a check for $FB.

Last Updated ( Friday, 15 January 2021 )