A couple of people have reported this issue: the stack counter resetting to zero for no apparent reason.
Here's what's happening. It's called a race condition — when a circuit works or doesn't work depends too much on the timing of the gates. In this case, depending on what order Logisim evaluates certain gates, the signal sent to sc1 and sc0 can be temporarily 00. If, just out of bad luck, Logisim decides to look at the stack counter at this point, it will reset the stack counter to 0, even if later on sc1 and sc0 evaluate to something other than 00.
(BTW, this seems to be happening to people who for some reason decided to make sc1 and sc0 sub-circuits.)
You can check if this is what is happening to you by disconnecting the zero line to the stack counter:
If your counter doesn't reset by itself after this, then you might have this problem. (You can have other problems too.)
You can make the stack counter more forgiving, by having it reset only if the clock is low:
This more robust version was uploaded to this webpage.
The fixed version is uploaded, but for most people, it would be easier to just swap the connections yourself.
In the project description, it says that if the ALU controls have d1=1 and d0=1, then the ALU increments Port B. This is not correct. The ALU increments Port A. (This is the same behavior as the ALU from Homework 3).
The web site has been updated.
The circuits on this web site have been updated.
Fixed main8c.c for Project 8. Testing of the bst_remove() function was buggy.
Updated bst.c for Project 8. Comments for bst_remove() were backwards between left and right.
cp /afs/umbc.edu/users/c/h/chang/pub/cs313/hello.asm .and
cp /afs/umbc.edu/users/c/h/chang/pub/cs313/toupper.asm .Don't forget the . at the end. It specifies the current directory as the target of the copy command.