[feature]: Multiple RAM views in the CPU Emulator

[Arcadonauts]

Tool

CPU Emulator

Interface

Website (https://nand2tetris.github.io/web-ide)

Contact Details

No response

What feature are you proposing?

The VM Emulator allows you to see two parts of the RAM at the same time, and it would be really helpful to be able to do that in the CPU Emulator as well.

Additional Comments

I can't remember what project I was working on when I made this note, but I just remember having to scroll up and down and up and down to try to figure out what was going on.

Do you want to try to add this feature?

• [ ] I want to try to add this feature!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[DavidSouther]

They're intended to show different things. The CPU only "sees" one big chunk of ROM and RAM. The VM has very specific interpretations of chunks of RAM, which is what that's supposed to be showing, but it doesn't make that clear.

@netalondon can you clarify why the VM view is showing two copies of the RAM? I see one has the common register labels, and the other starts at 256 (the "stack" RAM). I thought the point was to show the registers and non-stack pieces, then show the stack in its entirety (separate from the call stack on the left). But we already have the call stack? So I'm now thinking that the VM Structures panel should let us show:

VM Internals (registers, statics, etc), Internals RAM, VM Stack, RAM stack, VM Heap, RAM Heap

[Arcadonauts]

"They're intended to show different things. The CPU only "sees" one big chunk of ROM and RAM. The VM has very specific interpretations of chunks of RAM"

That's very clear, thank you, but I think in some projects it's really useful to be able to peak at two chunks of RAM at the same time while running a program step by step. Of course, it's possible to scroll back and forth, but a bit of a pain.

[netalondon]

@DavidSouther I'm not sure I understand what you mean?

I thought the point was to show the registers and non-stack pieces, then show the stack in its entirety (separate from the call stack on the left).

Yes, isn't that already the case? What changes are you proposing?

Also, should this be moved to a separate issue?

[DavidSouther]

The current views are unlimited, and have the same headings:

As I understand it, I expect the view on the left to be limited from 0-255, and the right to show 256 to 32767

[netalondon]

@DavidSouther This seems to have been the case in the past, but @Shimon-Schocken requested a change.

Here is the relevant part of this discussion from an old email:

Presently the left panel of the RAM displays only the stack subset of the RAM, as I wanted. I change this requirement, as follows: The left panel should ve exactly the same as the right panel, showing all the RAM addresses. But, by default, the display should start at address 256 (if the user wants, s/he can scroll up to 0, although users will probably scroll form 256 downwards).

Should we reopen this for discussion? How should I proceed?

[Shimon-Schocken]

Stating the obvious, these decisions must be guided by usability / pedagogy issues. In the VM emulator, the two RAM views help see / demo / explain how pointers like SP, LCL, ARG etc. change in one RAM view, and how the addresses that they contain change in the other RAM view. For example, see the screenshot below, where the user executes push constant 10, push constant 11, and sees how SP and RAM[256] and RAM[257] are impacted. These experiments are very helpful before you set out to realize this logic in assembly, when implementing the VM translator.

In the CPU emulator such needs / experiments are less eminent, so my initial thought was KISS (keep it simple stupid).

Having said that, we can, as an experiment in a different CPU emulator fork, split the RAM into two scrollable views, one on top of the other. It will be nice if the bottom view could be switched on/off. Both views should be 100% scrollable.