Why doesn't this Memory implementation work?

[riverfish]

I've made an implementation of Memory as below, but for some reason it doesn't pass the test. Can anyone explain to me why?

RAM16K(in=in, load=load, address=address[0..13], out=ramout);
Screen(in=in, load=load, address=address[0..12], out=screenout);
Keyboard(out=keyboardout);

Mux4Way16(a=ramout, b=ramout, c=screenout, d=keyboardout, sel=address[13..14], out=out);

[cadet1620]

Because RAM and Screen both have load=load, they both load for every Memory write operation.

You need additional logic to control the load inputs so that writing to one part does not write to the other. Also note that writing to the Keyboard address should not write to either of the other parts.

--Mark

[riverfish]

cadet1620 wrote

Because RAM and Screen both have load=load, they both load for every Memory write operation.

You need additional logic to control the load inputs so that writing to one part does not write to the other. Also note that writing to the Keyboard address should not write to either of the other parts.

--Mark

Right gotcha. Makes sense. So I assume I could use a DMux on the load to load either the RAM or Screen.

And how do I go about solving writing to the Keyboard address? Do I need to connect it to a Register?

[cadet1620]

Yes, demultiplexing 'load' is a good way to start.

The Keyboard is a read only device, so your current implementation for it is correct.

My Keyboard comment could have been clearer.  What I was meaning was that writing to that address, or any other address above the Screen memory, is an undefined operation. For safety, in case a buggy program did such a write, it is good design practice to prevent the write from corrupting any of the RAM or Screen memory. Using a demux to split the address space into four equal ranges automatically does this.

--Mark

[riverfish]

Gotcha. Thanks!