Memory view

address

 

label

 

changed by

unsigned

 

signed

 

hex

 

binary

  

The memory view of the dot matrix arcade doesn’t update in real time and that just won’t do. It can be quite useful to see memory values change while the program is running and I’m sure I can make that happen. While I’m at it, I have some ideas for other features, too.

To show and test the new memory view, I’ll reuse the processor from the dot matrix arcade. I won’t include the dot matrix display or the colorful buttons, because we’re not here to play games. Not this time.

Sections

Most notable among the new features is the use of colors. Isn’t it pretty? The colors aren’t just decorative, they’re also functional, but their meaning is secret. Just kidding. Red values are code, green values are data, and blue values are part of the stack.

The processor has no way to know what memory values are used for, so you need to specify that yourself. In your assembly code, you can mark a block as code, data, or stack.

.code, .data, and .stack are assembler directives. They don’t end up in the machine code in any way, but they help the assembler do its job. In this case, the assembler will output some debug information that specifies where each block begins and ends. The memory view uses this debug information to add color. The processor, by the way, doesn’t receive the debug information, so it’s still not aware of what all the memory values are used for.

Labels

When you hover over an address in the memory view, you get a bunch of information, including whether that address has a label in the assembly code. Of course, the processor doesn’t know anything about labels. The assembler translates them into a number and that’s all the processor needs. So, this is another case where the assembler generates debug information and that’s what the memory view uses to work its magic.

Since I have this information anyway, I can also use it in the code view. The code view is generated from the values in memory, so it would normally show all addresses as numbers, but with the debug information, I can translate them back into labels. And make the labels clickable, while I’m at it. How convenient!

What just happened?

The memory view also tells you which instruction last changed the value you’re looking at. In this demo, where you can’t change the code, that may not seem all that important, but it can be really convenient during debugging. You run your program, you look at the memory and you don’t understand what just happened to all the data. This feature helps you find out without stepping through the code.

For this, I did have to update the processor. For every byte in memory it keeps track of the address that last changed it. This is cheating a bit, because it requires an extra 256 bytes of memory. I wouldn’t consider adding this feature to a hardware processor, but why not use the fact that this is a virtual processor for some extra convenience?

Resize

It’s hard to determine how much of the memory to show at once. It’s only 256 values, so I’d like to show it all, but that may not work so well on mobile devices. The obvious solution is to make the memory view resizable. You can specify this in CSS, but then the resize handle is this tiny thing in the bottom right corner. That’s fine if do your pointing and dragging with a mouse, but not if you have to use your bulky finger, so I’ll make the entire bottom part of the view draggable instead.

Speed

The memory view can easily keep up with a clock speed of 1 MHz, even on older mobile devices. Problem is that the values change so fast at that point, that you can’t see what’s going on. So, I give you custom clock speeds. It’s probably fine to go even higher than 1 MHz, but for this demo, that would be of little value.