Earlier today, I was writing the latest column in my Arduino Bootcamp series for Practical Electronics, which is the UK’s premier computer and electronics hobbyist magazine.
As part of this series, we’ve been building a clock that uses four 7-segment displays to present the time in hours and minutes (HH:MM). We are currently multiplexing our displays, which has led to many interesting concepts and discussions.
In my latest column, we’ve just moved to using a binary coded decimal (BCD) to 7-segment decoder in the form of an SN74LS48 device (we’re using the 7448 because it’s designed to drive our common cathode displays—the 7447 would be the lad had we opted for their common anode counterparts).

The 7447/7448 data sheet is rather interesting. Fighting one’s way through this document is an experience (and an article) in its own right. The interesting part pertaining to this blog is when we come to the segment identification, numerical designations, and resultant displays as shown in the image to the right.
As we see, the 7447/7448 devices display the decimal values 0 through 9 as we would expect. But what about the values 10 through 15 (or A through F in hexadecimal)?
Did the designers of these devices miss their chance to make them display hexadecimal values? Were they perhaps unaware that hexadecimal was a “thing”? This seems unlikely. As far as I know, 7447/7448 devices arrived on the scene in the early 1970s and—although many people in the computer industry continued to use octal (base-8) into the late 1970s and early 1980s—the use of hexadecimal (base-16) had been on the rise since the early 1960s.
The telling thing to me is the blank (all segments off) character associated with the number 15. This is of interest when it comes to blanking leading zeros in multi-digit values, which is a task at which the 7447/7448 devices excelled (they could do it on their own without the need for a processor).
Once you have this blank, then it’s pointless to worry about the other hex characters. I’m guessing that the display characters associated with values 10 through 14 just “fell out” of the logic used to implement everything else (but I’d be interested to hear if you know otherwise).
All of this got me interested in learning more about the history of hexadecimal, so I had a quick Google while no one was looking and ran across this very interesting webpage, which starts off as follows:
Hex, short for "hexadecimal base counting", was invented in France in the year 770 AD. In that time Mervin, a famous wizard, became a counselor to King Charlemagne because he had 8 fingers on each hand.
Mervin could count faster than the other counselors and treasurers, because within a base he could go farther, using more symbols in fewer positions. When other mathematicians in the king's court had risen to 100, Mervin would only be at 0x64. This meant Mervin could express larger numbers in a smaller space […]
There’s a lot more. Someone commented, “Ok...at risk of sounding very naive, I'm going to have to ask if this is a joke!” Someone else (possibly the original author) responded, “"Naive" isn't the word. Which part of it sounded plausible to you, and why?”
For myself, this really brightened my day. The only downer is that I wish I’d written it myself. Meanwhile, the Wikipedia provides a great starting point should you want to learn more about the real history of hexadecimal.













Per definition, the device is converting Decimals (BCD to 7-segment);
But you’re right, this looks like an unfortunate oversight;
With the same 4-pin input and 7-pin output the possibility to create a HEX to 7-segment for free seems obvious.
There are two reasons I can dream up for not doing this:
This is all speculation though, I don’t know the answer.
Hi Dirk — I think the designers made a decision that they wanted to use code 15 to display a blank (no segments lit) character, thereby allowing them to blank out leading zeros on things like frequency counter displays — and once they had done that, displaying hex was out of the question.