Stuck in Memory. Keyboard

[eVh1955]

Hi.  I have problems with the keyboard, especially at "K".  Please help me evaluate my problem.  Code is below. I've modified some parts.  Thanks.

CHIP Memory {
    IN in[16], load, address[15];
    OUT out[16];

    PARTS:
    DMux (in=load, (...something...something...), a=ramL, b=scrnKboard);    // between ram16k and keyboard/screen
    DMux (in=scrnKboard, (...something...something...) , a=scrload, b=kload);   // between screen and keyboard
    RAM16K (in=in, load=ramL, (...something...something...), out=ram);  
    Screen (in=in, load=scrload, (...something...something...), out=screen);  
    Mux16 (a=ram, b=screen, (...something...something...), out=ramOrScreen);  // outs either ram or screen
    Keyboard (out=keyboard);
    Mux16 (a=ramOrScreen, b=keyboard, sel=kload, out=out);  // outs either the item above or keyboard
}

[WBahn]

Not sure what you mean by "especially at K". Could you please elaborate?

This is like walking into an auto mechanic's shop and telling them "I'm having some problems with my car's engine. I've modified it. The car's not here, but here's a picture of the garage it's in. Can you tell me what's wrong?"

WHAT problems are you having?

What test is it failing? What are the corresponding lines from the .cmp and the .out files?

What parts have you modified? What modifications did you make to them?

Since we don't have your complete circuit, there's little to go on.

Do ALL of the parts you are using pass ALL of their tests?

[eVh1955]

Ok, sorry I did not clarify.  I passed the tests until I encountered the keyboard test.  Message says: " Click the keyboard and hold down the 'K' (uppercase)... until you see the next message ".  

So I clicked the keyboard icon and held down K but no message appears. In the internal pins, the keyboard appeared to show "K" (75) when I press the key but does not out as "K", and I don't know why.  Please advise.  Thanks.

[WBahn]

There's no way to tell what you are doing wrong because you aren't showing us what you are doing at all. I can't tell whether you are addressing the parts correctly or controlling the Muxes correctly because you aren't showing how you are addressing the parts or controlling the Muxes.

But let's look at the test script and see if we can narrow things down at least a little.

From the test script (starting on line 87):

set address %X2345,		// RAM[2345] = 2345
set in 2345,
set load 1,
tick,
output;
tock,
output;

We can identify these as the third and fourth lines from the bottom of your output where the first output is setting the address and the input and the second is verifying that that the value was actually written to that address (note that the comment is wrong, it is not RAM[2345], but rather RAM[0X2345]).

set load 0,
set address %X0345,		// Did not also write to lower RAM or Screen 
eval, output;
set address %X4345,
eval, output;

This section produces the final two lines in your output in which it is testing a couple of other memory cells that could also have been written to if the addressing/load lines had been done incorrectly in a couple of common ways.

So now we have identified which statement in the test script produced the final line in your output (the one on line 99). We thus know that the test never gets to the next output.

// Keyboard test

set address 24576,
echo "Click the Keyboard icon and hold down the 'K' key (uppercase) until you see the next message (it should appear shortly after that) ...",
// It's important to keep holding the key down since if the system is busy,
// the memory will zero itself before being outputted.

while out <> 75 {
    eval,
}

clear-echo,
output;

So now the script sets the address to 24576, and we see that in the input pins window. It issues the message via the echo, which we see. It then goes into a loop that whiles until the value of the output pin becomes 75 (the ASCII code for 'K') at which point it will clear the message and issue the next line of output. We know it isn't getting to the output command and it isn't clearing the message, so it must be getting stuck in the while-loop. The only way that should happen is if your chip is not sending the output of the keyboard part to the memory output when the address is set to 24576.

But since you show neither how you do your addressing nor how you control which part's output is directed to the chip output, I can only conclude that however you are doing it, you aren't doing it correctly.

[eVh1955]

I guess I need to show my code then. I was concerned that I might not be following the rules.  Anyway, here it is:  

PARTS:
    DMux (in=load, sel=address[14], a=ramL, b=scrnKboard);    // between ram16k and keyboard/screen
    DMux (in=scrnKboard, sel=address[13], a=scrload, b=kload);   // between screen and keyboard
    RAM16K (in=in, load=ramL, address=address[0..13], out=ram);  
    Screen (in=in, load=scrload, address=address[0..12], out=screen);  
    Keyboard (out=keyboard);
    Mux16 (a=ram, b=screen, sel=address[14], out=ramOrScreen);  // outs either ram or screen
    Mux16 (a=ramOrScreen, b=keyboard, sel=kload, out=out);  // outs either the item above or keyboard

[WBahn]

We can delete your code once the issue is resolved. But thanks for being sensitive to that concern.

Since we have identified that the problem is that the keyboard output is not getting routed to the chip output when it should, first determine under what conditions of the inputs the keyboard output should be routed to the chip output.

Next, follow your chain back from the output to the inputs and see what the inputs have to be in order for the output of the keyboard to be routed to the chip output.

Do that, and I think you'll see your problem. When you do, apply what you've learned and see what other problems that error is creating.

[eVh1955]

Ok, thanks.  I was wondering if any of you uses the program Logism?  It could have been useful, except it doesn't have the SCREEN chip.  What do I use as a substitute?  There's LED and other stuff, though I'm not sure it that's the same?  

About my code, the earlier assumption I had was if load is 0, the in should be exclusively directed to the RAM16K and out as well.  At 1, the in is diverted to the screen and keyboard.  

But then, during testing, it appears that the tester expects that the output should be coming from the keyboard even at load 0.  

So how should this really work?  So at load 0, the in should be directed at memory and keyboard instead?  Or something else?  Thanks.  

[WBahn]

Think about the name "load". When you set it to 1 it means that you want to load the value that is at the input pin into the memory location whose address is on the address pin. When it is set to 0, it means that you don't want to load the value that is at the input pin into the memory location whose address is on the address pin. Notice how nothing in that description of what the "load" signal does has any bearing on the value of the output pin.

The output pin ALWAYS puts out whatever value is presently stored at the memory location whose address is on the address pin.

[WBahn]

As for Logisim, I don't use it (wasn't impressed by it) but I've used other simulators for "real" work.

Even if you make the screen and keyboard parts in Logisim and get them to behave like you want them to, you won't have the ability to run the test scripts to know whether or not your design is working properly.