Welcome to the Hack CPU Emulator.
The CPU emulator is a Java program that gives you a visual rendition
of what is happening inside the Hack computer when a program is being executed.
And indeed, if you look around,
you will see all sorts of familiar elements from the heck platform.
On the left-hand side, we see the instruction memory and
right next to it, the data memory.
And below, we see the current value of the A-register here and
the current value of the D-register there and
there's also a visual rendition of the ALU operation.
Another control of interest is this one,
which shows you the current value of the so-called program counter.
The program counter is a register that contains the address of
the instruction that will be executed next in the program,
which is currently loaded into the instruction memory.
Now right now, we have no program in the instruction memory,
so lets go ahead and load one.
So, I click this control here and I have this folder called program examples.
So, I'm going to select it.
And inside program examples, there are all sorts of Hack programs.
I'm going to select the first one, add2and click the Load ROM button.
And I see that now the instruction memory contains what seems to be
a sequence of Hack machine instructions, written in assembly.
[COUGH] I'm sorry, written in assembly language.
Now, if I want, I can look at these instructions in binary format.
And yet as we argued before, it's much easier to think about the program and
display it and understand it when it's visualized using these assembly comments.
Now, according to the rules of the game or more precisely,
according to the rules of this program.
In order to run it, we first have to enter some numbers into the the RAM.
So let's see.
I'm going to enter, let's say, 12 here and 7 there.
These are completely arbitrary values.
And hopefully, the program will end up summing up these two values and
putting the result in in RAM 2.
So to check that this is actually the case,
I can begin running the program and I do it by using this
visual metaphor here of an advance of sort VCR control.
So let's, let's advance and execute the first instruction.
Well, nothing dramatic happened let us execute the next instruction and
I see that the D-register became 12.
So we managed to load the contents of RAM 0 into the D-register.
Moving along, I now execute the next instruction, which was at one.
And indeed, I see that the value of the A-register is now one.
Let's do the first instruction D equals D plus M.
And indeed, we see that the current value of D became 19, which is 12 plus 7.
And finally, we execute at two, which selects this
register here in In the RAM register number two, I see it here as well.
And finally, M equals D.
And indeed, we see that RAM 2 became 19.
So, lo and behold, it looks like the program is actually working.
Now notice that the program counter is six, so
if I keep on executing commands I will continue to execute
whatever resides here in memory in all these addresses.
Which is a little bit worrisome and
I will get back to talk about it a little bit later on.
All right.
Now let us suppose that we want to rerun this program from scratch.
So what we can do is rewind the program, so to speak.
Now there's no rewind in, in computers but
this visual metaphor here indicates that the program counter has been set to zero.
And this actually causes the computer to to set itself to
a position in which it can start executing this program again.
So we can, you know, try some other values here.
Let's, let's enter just the first value is now minus five and
I'm going to rewind once again.
And now, I'm going to fast forward, which actually means, just, you know,
let the whole program execute automatically, so to speak.
So we see that the program is indeed executing without any help from us and
let us pause it for a little while and
we see that we got the right answer, which is 2 minus 5 plus 7 is 2.
And if we continue to execute it the computer will kind of,
spin its wheels, so to speak and will execute all these null instructions.
And indeed, we see that nothing's actually happening, but
the program's kind of out of control and we have to think about way to resolve it.
But for now, what is more interesting is the fact that we learned
how to execute a program and how to inspect the various controls here and
convince ourself that the program is actually doing what it's supposed to do.
So now that we understand how the ROM comes to play in simulation,
let's go back to the general specification of the ROM.
It's almost a regular memory chip.
It has an address coming in.
It has some output coming out.
It's a ROM device, read-only, so
we don't have any machinery that enables writing into it.
And if you recall, the output of of the ROM is always
the contents of the register that is selected by the address input.
