---
title: The memory
description: The bytes themselves, read either as the processor sees them or as the machine's own memory holds them.
order: 12
---

`<colophon-memory>` shows the bytes: sixteen rows of sixteen, each with its address and the text it would make if it were text.

```html
<colophon-memory></colophon-memory>
```

## The two spaces

`CPU` is what the processor can see this instant, addressed in four digits. `RAM` is the machine's own memory, addressed in as many digits as it takes: five on a 6128, where that is twice what the processor can reach at once, and four on a machine whose memory is no wider than its address space.

The two differ wherever a ROM is paged in — the processor reads the firmware, the memory underneath still holds whatever was written there — and that difference is often the answer to why a program is reading what it seems to be reading. They are also offset wherever a machine's memory does not begin at zero: a Spectrum's RAM answers from `&4000`, so its physical zero is the processor's `&4000`.

## Moving

`At` is the address the dump starts at; it is rounded down to the beginning of a row. The wheel moves a row at a time. Escape puts the address back to where the dump actually stands.

The rest of the debugger can send the dump somewhere. [An instruction](disassembly.en.md#what-can-be-done-with-an-instruction) or [a name](symbols.en.md#what-can-be-done-with-a-name) offers to show its address here, and the dump moves to put it in the middle of the window rather than at the top, so that what surrounds it is visible too. Near either end of the space there is nowhere left to move, and the address sits wherever the edge allows. Whatever sends the dump somewhere says which space its address is counted in, and the panel changes to that space rather than guessing: an instruction or a name is the processor's, a pixel is the video hardware's. The panel scrolls itself into view if it was not, and the byte it was sent to is opened for editing with its value selected, so that reading it and changing it are the same arrival.

## Editing

Click a byte and the cell becomes a field with that byte in it. Two accepted digits commit it and move to the byte after, so a run can be typed straight through without reaching for the mouse again. Leaving the field commits what is standing in it. Escape abandons the edit and leaves the byte as it was.

A byte written into `RAM` goes to the bank; a byte written into `CPU` goes wherever the processor would have put it.

## What can be done with a byte

The right button on a byte asks what may be done with it, and the panel answers for its own. In `CPU` that is setting a breakpoint on the address, which opens [the breakpoint form](breakpoints.en.md#setting-one) with the address already in it. In `RAM` it is instead standing the machine on the instruction that last stored that byte, which [the record](record.en.md#where-a-byte-came-from) traces by physical address and so can only offer here. The character standing for a byte answers the same, since it is the same byte read another way.

A breakpoint is set on an address the processor can reach, which is why `RAM` is not offered one; the trace is kept against the banks themselves, which is why `CPU` is not offered that. Where a byte has neither the browser keeps its own menu.

## The marks

A byte the dump was sent to is turned inside out, foreground for background, in both columns at once. It is not a colour, because every colour here already means something: this is the debugger saying _this is the one you asked for_, and it lasts until the dump is moved again by any other means.

A byte that changed since the last redraw is lit, so a value moving under a stopped machine is visible without hunting for it. The window moving does not count as a change, or every byte would light at once. A zero is dimmed, which is what makes the shape of written data stand out from the memory around it.
