I don't mean to come off as rude but since the beginning of this thread I've always known that.

Sorry. It sounded to me like you were saying that you couldn't understand why people thought you were working in decimal.

As I said in my first response, there are tricks to dealing with the conversions and, as with everything, there are tradeoffs involved.

You don't need to implement a general purpose multiplier circuit because the algorithm you need to implement is very narrowly defined. But you do need to make some decisions early on such as what range of values you want to represent? Your schematic implies that you are only interested in working with unsigned three-digit integers (so 000 <= x <= 999). Is that correct? No negative numbers? If not, that makes things easier. Since you represent this range of integers with a 10-bit binary representation, do you want your ALU to be 10-bits wide? Or 12-bits so that it matches up with the bits needed for your I/O? Or what?

There are a several ways to do the conversion. One approach is to build up the converted value incrementally. You can do this with less hardware by having the work performed in a loop, or you can do it all combinatorically. Each has its pros and cons.

 

Apart from early calculators, I can't think of an example of a decimal keypad being interfaced in hardware at the keyswitch level. I understand the challenge of what you are attempting, and the satisfaction of making it work (if possible), but it is MUCH simpler to perform the logical processes of interface and display conversion in software.

There are limits to the appropriateness of any design solution, and your approach is stretching the practical capabilities of chip-implemented boolean logic. For example, you are faced with the problem of BCD-to-Decimal conversion for input and back again for display which you fear will lead to a hardware morass.

Where you are now, switches and lights for direct boolean I/O are appropriate. Once your architecture has evolved to the point of having controlled I/O paths, software can drive a more human-friendly I/O.

There are lots of instructional videos about various architectures, both combinatorial and microcoded. You might find it very instructive to explore the use of a microcoded keyboard interface. Maybe something based on this: https://www.alternatezone.com/electronics/plc.htm

Very informational, I understand that worrying about human readability shouldn't be a main priority at this point and in hindsight any work arounds wouldn't be needed if i just stick to a binary i/o. I was planning to make the system future proof, meaning if i wanna hook it up to a custom cpu far in the future I can without reworking any existing logic. Even though with enough logic gates anything is possible I also realize that this system isn't very efficient. I do believe the entire system i have AND the summing up products of powers of tens could work for the i/o i'll just do that last until have something to show for it.

 

You can also look at implementing your logic in an FPGA, unless the whole goal is to be able to show off a system with lots of chips and wires (which can definitely be an impressive sight, particularly if well done).

One thing to keep in mind is that building logic systems using using discrete gates quickly moves out of the realm of a hobbyist-level project. Historically, these were the domain of extremely well-funded government and commercial efforts.

Since you indicted you were willing to consider using an off-the-shelf chip to do the BCD/binary conversions, you actually have a very simple solution staring you in the face (assuming you are planning to stay limited to three decimal digits). Use a LUT (look-up table). Load a PROM with two tables, one converts from BCD to binary and the other converts from binary to BCD.

 

You can also look at implementing your logic in an FPGA, unless the whole goal is to be able to show off a system with lots of chips and wires (which can definitely be an impressive sight, particularly if well done).

One thing to keep in mind is that building logic systems using using discrete gates quickly moves out of the realm of a hobbyist-level project. Historically, these were the domain of extremely well-funded government and commercial efforts.

Since you indicted you were willing to consider using an off-the-shelf chip to do the BCD/binary conversions, you actually have a very simple solution staring you in the face (assuming you are planning to stay limited to three decimal digits). Use a LUT (look-up table). Load a PROM with two tables, one converts from BCD to binary and the other converts from binary to BCD.

I have thought of using EPROMs to replace combinational logic but I haven't used them before so they scare me for now. I also have thought of using a simple adding circuit, a counter, and temporary sum C register to sequentially add the sums until A and B are multipleyd but idk if it works and is just a throw away idea I had. I also plan to use two M74HC299 which are 8 bit pipo registers so 16bits total. I tried contacting STMicroelectronics for spice models because I can't seem to find any models online. I also signed up for that NandtoTetris course.

 

I have thought of using EPROMs to replace combinational logic but I haven't used them before so they scare me for now. I also have thought of using a simple adding circuit, a counter, and temporary sum C register to sequentially add the sums until A and B are multipleyd

You are tickling the edges of a microcoded logic engine replacing the morass of a combinatorial solution. If you want to get into building such a processor (which is a very interesting space I think) then Winkel and Prosser's book has a great chapter covering the theory: The Art of Digital Design which I highly recommend.

 

You are tickling the edges of a microcoded logic engine replacing the morass of a combinatorial solution. If you want to get into building such a processor (which is a very interesting space I think) then Winkel and Prosser's book has a great chapter covering the theory: The Art of Digital Design which I highly recommend.

I probably could make my life easier by learning EPROMs but I haven't learned them because I never needed them. As long as your able to build nand gates you can construct anything. This is probably a good chance to finally learn though I guess. I have started to look around for good books that really dive deep but also provide tons of example circuits and pictures.

A few years ago my old high school professor gave me most of his inventory of ttl logic and other components because the next year they where changing the curriculum to focus on microcontrollers. He even gave me a old 2 channel oscilloscope that I almost never use. I know its dumb but I personally feel horrible for not using any of that stuff he gave me. Its literally just rotting in my fathers moldy ass shed. I actually have a lot of equipment that I wish I could use more often. It really is sad...

 

As long as your able to build nand gates you can construct anything.

You CAN build anything out of gates but you will build something complicated (eg an ALU), get it working, and then decide that the design needs changing, and THEN you will appreciate why microcode (ie software) is so much better.

EPROMs are obsolete, replaced by EEPROMs - they are not complicated. But they are in short supply at the moment unfortunately.