Then you can make PC like you made bit Bit, except that the feedback wire is replaced with a circuit that computes the next value for the PC.
Also, in hardware it is often easier to generate all the options you might need and select the one that's required by the current control values. Think about handling the f bit in the ALU, but in this case there are more options.
http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/PC-Counter-td4030223.html Just an update/FYI I actually did figure this out after reading another comment of yours! My logic was flawed in the assumption that we only wanted the register's load bit to be 1 when we load from "in". I hope this isn't too much of a hint to others looking to solve this the "simple way" but we actually want the register's load bit to be true any time there is an operation requiring a state change in the register. From there it was a simple matter of combinational logic to construct what constitutes a state change - and voila!
You've got two Register parts in your design, but a program counter only stores a single value, hence it only needs one Register.
Think of the PC as a circuit that has different behaviors depending on the three inputs and first make circuits that just have each of the designed behaviors: increment, load, reset, and hold. What are the differences between these circuits? Can you use Mux16 parts (or other parts) to be able to change between the different behaviors? Now all you need to do is figure out how to use the three input signals to control the multiplexer select inputs.
It was getting pretty late when wrote and posted that code. Here are the building blocks I've been trying to work with. The previously posted code shows my frustration in wiring the circuit leading to two registers. I basically just tried to mash the puzzle pieces together.
Mux16(a=?, b=false, sel=reset, out=?);
Idea 1: Register(in=in, load=load, out=out);
Idea 2: Mux16(a=?, b=in, sel=load, out=toReg);
Register(in=toReg, load=load, out=out);
The thing you need to note is that the only difference between the various behaviors is what gets applied to the input port of the Register part.
Using a Mux4Way16 is a perfectly reasonable way to go and makes things pretty simple in the end.
But you have two select inputs but three control signals. So you need a little circuit to take the three control signals and map them to the two select signals of the mux. The simplest way to do that is to make a truth table showing all eight possible combinations of the three control signals and have a column for the desired behavior (of which there are four). Then you can assign one of the four possible select signal combinations to each of the behaviors (conceptually it doesn't matter, but certain choices make the resulting logic a bit simpler, but not enough to spend too much time fretting over it -- pick one and push one). Then you just need to apply the signal that needs to make it to the Register input port to the appropriate mux input.
Success! The thing I love about this course is that moment when the hardware simulator returns a success!
Thank you for your feedbacK! I ended up scratching the idea of using the Mux4Way16 and decided to work backwards from the output to the inputs. Whiteboarding this method resulted in three Mux16's, one Register, and one Inc16.
I can't believe the struggle to write 5 lines of code. LOL
What a thrilling experience!