For fun, I was trying to imagine how I might implement large values in 74 series logic (or any commonly available discrete logic from the 1970s). An example might be displaying prime numbers up to 100-bits, or displaying partial sums of a divergent series up to similar values, or working with computations in cosmological scale, etc. Really \$2^{100}\$ isn't very large, but computing using TTL and displaying the results in decimal on a bunch of 7-segment displays seems like an interesting challenge. It actually seems like it might be effectively impossible without a very large amount of work. I am curious if anyone has seen something like this done.

Clearly you can't simply program all the 7-seg values into memory and address the chip with the binary values since there are no memory chips with 100 bit address. Multiplexing is out of the question for so large a set is displays (at least across all 31 decimal digits). The logic for binary to BCD is not cheap, the chips that did that in the 74 series (74185) are rare and expensive, and to implement the same in gates would be herculean without first having some sort of program to generate the circuit for you (no human is going to sketch out that logic in simple gates for 100-bits in a single lifetime).

Maybe that is the way to handle it? Just brute force an algorithm to give you the circuit using a few hundred (? thousand?) gates? Or maybe build your arithmetic logic to use BCD to begin with somehow? (I don't think I've ever seen that...)


closed as too broad by Elliot Alderson, Eugene Sh., Edgar Brown, StainlessSteelRat, Finbarr Mar 7 at 18:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Electronics (and engineering in general) is all about abstraction. You don't build complex logic from the basics right away, but you do it in layers. What you are talking about - is to skip several abstraction layers. \$\endgroup\$ – Eugene Sh. Mar 4 at 17:38
  • 3
    \$\begingroup\$ Calculate in BCD. \$\endgroup\$ – Janka Mar 4 at 17:40
  • \$\begingroup\$ This website may help you. It's only 36 digits, but you can easily expand it. \$\endgroup\$ – StainlessSteelRat Mar 4 at 19:21
  • \$\begingroup\$ @EugeneSh. Yes, I am aware of this, but I was trying to imagine how one might have solved this problem in discrete logic in maybe the early 1970s. There are not many obvious layers of abstraction to build from when each step requires more addressable space than would have been available (still is) by an order of magnitude. Of course in real life if I wanted a solution to implement I would use FPGAs if it has to be in parallel, otherwise it is trivially easy with a microcontroller. \$\endgroup\$ – TrivialCase Mar 4 at 19:37
  • \$\begingroup\$ @TrivialCase I've read the answers and comments and I'm still not sure what you are about here. Are you just asking generally how someone might approach any given problem in 1972, say, with 74xx chips? If so, I wire-wrapped a small computer in 1974 using 74xx chips. (Nothing I'd ever try again.) But there are such projects on the web (Bem Eater's pages, for example.) But you don't go back far enough, perhaps. How did someone design a teletype that accepted binary data (ASCII, say) and convert that into typing? (KSR-35.) It was with cams, gears, motors. Imagine that as a design project! \$\endgroup\$ – jonk Mar 4 at 20:46

For questions like this it is often good to look at the architectures of early computers.

You (seem to) want two things:

  • calculations on values
  • display values (n decimal)

You can optimzie of either:

  • use binary for easier calculations
  • use BCD for easier displaying (in decimal)

Both routes have been taken. I think in retrospect in most cases the first is to be preferred.

If the amount of logic required for either calcualtions or conversion to digital format (which involves calculation, espceially division by 10), thing serially: a one-bit ALU requires only a small amount of logic (but it is , of course, slow). This route was also taken in some earlier computers.

  • \$\begingroup\$ Yes, the stipulation that it be a calculated value was to make it dynamic enough to be interesting. If you have to calculate, then you assume that the values in the results registers are in binary. I thought, "what would they have done to display values too large for the commonly available registers by an order of magnitude?" I had never seen a solution implemented in real life. Of course, doing the calculations in BCD to begin with is probably the simplest solution, but I've never seen that either. \$\endgroup\$ – TrivialCase Mar 4 at 19:32
  • \$\begingroup\$ Again, look at what (old, or also new) computers do: they serialize, in ancient times bit-wise, nowadays word-wise. No CPU can directly calulate on the large numbers required in cryptology, so they do it in smaller chunks (128, 64, or 32 bits, or 8maybe even 8 bit). \$\endgroup\$ – Wouter van Ooijen Mar 4 at 19:40

Break your number into individual digits and send them to MAX7219 chips, each one can drive 8 digits (common cathode for easiest programming, it has 0-9 and H-E-L-P decoding built in, but is not hard to make a look up array for other things: A, b, C or c, d, E, F, g, H or h, I, J, L, O, P, S, U, and others with some imagination.

Easy to send data to it using SPI, there is one register/digit, so updating a register just needs (in C++/Arduino):

digitaWrite (ssPin, LOW);
SPI.transfer (addressRegister);  // 1 to 8
SPI.transfer (dataArray[x]);  // looks up the segments to use to show 'x'
digitalWrite (ssPin, HIGH);
  • 2
    \$\begingroup\$ I think the OP is asking for a TTL solution, not an Arduino solution. \$\endgroup\$ – Elliot Alderson Mar 4 at 17:52
  • \$\begingroup\$ MAX7219 is TTL compatible. Code it however is desired. \$\endgroup\$ – CrossRoads Mar 4 at 18:09
  • 1
    \$\begingroup\$ TTL-compatible is not the same as "in 74 series logic" as the OP requested. \$\endgroup\$ – Elliot Alderson Mar 4 at 18:35
  • \$\begingroup\$ Something that needs to be loaded via SPI is not realistically compatible with a logic type implementation. It would require at least a state machine to drive it, and of a complexity where no one in their right mind would avoid software when the speed requirement is so human-scale slow. \$\endgroup\$ – Chris Stratton Mar 4 at 18:49
  • \$\begingroup\$ The whole question is abstract, I see no reason that discussion of displaying the output can't be more concrete. Where are the large numbers to be displayed coming from? Big bank of toggle switches? \$\endgroup\$ – CrossRoads Mar 4 at 18:53

This should be done in software.

If you must do it in hardware, consider that the output is extremely slow in electronic terms and displays tend to be multiplex scanned anyway. So there's no point in trying to build a parallelized implementation - that is really reserved for problems where the requirement is too blindingly fast for any other approach, something not true here by many orders of magnitude.

So instead, if you must build hardware, build a division-and-lookup engine which calculates the most significant digit's BCD value and resulting segments, and yields a remainder it can use on the next cycle to calculate the next digit. While you could theoretically cache the results until the input changes, re-doing the conversion calculation every re-scan of the display probably won't cost enough power to be worth the substantial complexity of avoiding.

You can probably build this with registers, PROMs and a clock. But for sake of sanity, simulate it or build it in an FPGA... or solve it with software, or find a more useful problem to solve.

  • \$\begingroup\$ I appreciate the response, and if this was a real project I would just use a microcontroller or FPGA - I was more curious how this would have been solved in, say, the early 1970s using discrete logic ICs. It is trivially easy today, but I suppose that if anyone had such a problem in 1970 or so, where they would have had to create a real-time display of computed values too big for commonly sized registers, I guess they must have tried to solve it using thousands of gates/flip-flops/PROMs/etc \$\endgroup\$ – TrivialCase Mar 4 at 19:30
  • \$\begingroup\$ I think you missed that within the enclosing argument against attempting it, the actual core of this answer was a proposal for something that could be built with a fairly small amount of low density logic (as was available historically) which would recursively light one digit at a time, and repeat fast enough to appear to the eye as a steady output of all digits. In effect, it would be a compact dedicated hardware implementation of a software-like algorithm for binary to BCD, folded with the usual multiplex-scanned way of driving multi-digit 7-segment displays. \$\endgroup\$ – Chris Stratton Mar 4 at 19:45
  • \$\begingroup\$ Though doing the subtraction for the remainder is going to be a pain... \$\endgroup\$ – Chris Stratton Mar 4 at 20:13

One can also use individual chips such as TPIC6C595 or 6B595 to sink current thru individual, non-multiplexed displays, such as those with segments made of 3 or 6 LEDs. This is an example of such a display.


I made (and offer) a board with 12 shift registers that sink current thru each segment to turn them on, these digits use 12V and a current limit resistor. The larger digits are two groups of 3.

  • 1
    \$\begingroup\$ Are you advising the OP that you can sell them a product? Is that what "I made (and offer)" means? This is still not a solution "in 74 series logic". \$\endgroup\$ – Elliot Alderson Mar 4 at 18:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.