nand2tetris | Computer System Elements - Building a Modern Computer

I find that it helps to break things down, and in complex situations, write down the truth table for the various signals (including the intermediate signals). Sometimes this will lead to an "aha" moment where you see a connection you can use to simplify things.

You may also find it helpful to draw a graph that maps the flow of the signals through the circuit.

Finally, the adage that "first make it work, then make it pretty" applies. Once you have something working, you can look at the design and find simplifications and optimizations. A good example of this is building the XOR circuit. Once you have the straightforward version, if you look at it hard, you can find the clever optimization.

I suppose it is just one of those things where you have to practice until you get the knack of it. You may find it useful to revisit earlier projects with an eye to making them cleaner and easier for you to understand. There are often several ways to build the required circuit, but some ways may be more comprehensible to you. Also, I would recommend you get in the habit of commenting your designs; it is helpful to have a reminder what you were thinking when you did something.

The y & twoToThe[0] expressions evaluates to a new integer (as a result of a bitwise and operation between the bits of 5 and the bits of twoToThe[i]), not to a boolean as I think you were expecting. Check it:

gcc warns about unknows escape sequence \- Demo.

You have to escape \,

Your logic for selecting what input to pass through appears to be incorrect. You should test it by creating a truth table for finalSel, notFinalSel, aAndB, cAndd and out for each of the 4 control conditions.

In general, when doing these kinds of problems, the KISS principle holds; Keep It Simple and Stupid. You don't need any fancy logical manipulation of your sel[] bits, you can just use them directly. So once you get your version fixed (and understand where you went wrong), try doing a version that just consists of 3 Mux16's and nothing else. Once you have both versions working, you'll then understand the error that caused you to go down the wrong path in your first attempt, and that will be a valuable lesson going forward.

Have fun!

There are 2 main parts to consider here:

1. call foo 2 : this instruction tells vm to call funcion foo that takes 2 arguments ( which should be pushed on top of the stack before this call ).
   Calling any function means that you should take these steps as follow: push return address on top of stack (SP++), then push LCL, ARG, THIS,THAT ( SP+4). At this point SP should equal 310.
2. function foo 4 : this is NOT the first instruction in function foo, but still it has an effect on SP as this means that functionfoo has 4 local variables. And these variables must be located somewhere. Where? On top of the stack. This means that before first 'real' instruction of foo gets executed, we must push 4 values onto the stack. What values? Well - according do vm specification it should be 0's, resulting in local variables being initiated to 0. This also means that we increase SP for every local variable ( SP + 4)

This leads to conclusion that SP, after calling foo but before executing 1st instruction of this function will have value of 314.

I'm sorry, but the solution you posted does not solve the problem. I think this is why coursera is rejecting it.

When I run your solution through an assembler and then a cpu emulator I do not see the behavior required of Fill.asm. I'm comparing your solution to a solution I know to be correct and I am seeing different behavior.

Here's a screenshot of the cpu emulator while pressing the keyboard using your solution:

Here's what I expect to see:

I suggest reviewing your solution.

Hint Something missing from your solution is code to fill the screen.

Here's why I think it's missing:

1. Line 19 M=0 of your solution is where I believe the color is set to white
2. I change line 19 to M=-1, setting the white color to black
3. I expect to see the screen always painted black, but instead, I see only a small line of black in the top left corner of the emulator screen as seen below

Hint: You have one loop ((LOOP)) that repeatedly listens for the keyboard. I expect to see another loop ((FILL), or whatever) which fills the entire section of memory dedicated to the SCREEN with white or black.

Good luck.

These memory leaks are from the runtime, like /usr/lib/system/libdispatch.dylib, /usr/lib/libSystem.B.dylib, /usr/lib/dyld.

I ran your program on linux (valgrind --leak-check=full ./a.out Pong.asm):

This should do it:

From what can be seen your input pins are: