The program,
frame by frame.

A behavioural emulator has a loop: fetch, decode, execute, and a register file it writes at the end of each instruction. This chip has none of that. It has … wires and … switches, and a clock that goes up and down. A frame here is the level of every one of those wires at one edge of that clock, and everything printed on the plate is read out of them.

That is why the plate can show a value in the adder that is in no register yet, or an accumulator that changes a whole cycle after the instruction that changed it has ended. Those are not glitches in the recording. They are what the silicon does, and the Trace page explains the overlap.

The datapath is joined by pass transistors, and a pass transistor is drawn the way the schematic draws it: a break in the wire that a control line closes. The island shows only the ones whose control line changed between the previous frame and this one, one bit of each as a stand-in for the eight, with the wire either side lit by its level.

The island is never empty, and that was a surprise. The first draft of this page said an empty island was the common case, and the check written for it found no such frame: some of the datapath's paths change at every edge, whatever the instruction. The line under the island counts them over the whole recording and names the paths that change most, and they are the ones that reload the program counter from the address bus and the adder from its two buses, machinery that runs whether or not the instruction needs it. An emulator does none of that between instructions; the silicon does not know it is between instructions.

Beneath it are the other things that happened at this edge that are not a switch: a memory read or write on the pins, a decode term arriving, a register whose stored value moved.

The trace under the strip is the manual's own figure for single-instruction execution redrawn from the recording: the two clock phases the chip puts out, then RDY, SYNC and the timing states, over the half-cycles either side of the frame you are on. The two phases come off the clk1out and clk2out pads as levels, like every other pin here, so their non-overlap is measured rather than drawn: neither is ever high while the other is.

Record can be switched off. Running or stepping past the end of the recording then moves the chip without keeping frames, which is how you get deep into a program quickly; switching it back on takes a frame where the chip now is, marked on the strip as following a gap, with a fresh snapshot of memory so the window stays honest about what the chip wrote while nobody was looking. Reset power-cycles the chip and records again from the start.

Download gives you the recording as one JSON file: the first frame's node levels in full and every later frame as the nodes that went up and the nodes that went down, with the derived state kept beside each frame so the file reads without the netlist. It is lossless, and the harness proves it by replaying the deltas and comparing against what the chip said.

The file says how it is encoded, in an encoding block, because the first person to read one cold had to guess: the bitset is bit i for node i, least significant bit first within each byte, padded with zeros to a whole byte; a unit whose every bit has a storage node is a bare byte and one that does not is [value, mask], which is how the status register, whose bit five has no storage node, is written; the node numbering is visual6502's own; and the rails are declared and hold their level in every frame. That last one is a fix the same reader prompted: the supply node used to dip on most opcode fetches, because the solver wrote a group's level back into a rail it had touched, and nothing on the site could see it because nothing reads a rail's level except this file. A recording also never ends on a φ1, so a reader pairing the two phases of a cycle finds both.