この文書はまだ翻訳されていません。本文は英語のまま表示されています。
A 6502, half a clock phase at a time. Every value is read out of a storage node on the die.
Boot a program to begin.
Every sentence on this tab is generated from the bytes and control-line booleans of this half-cycle; nothing is authored per instruction, so the words cannot outlive the wires they describe. The two panels above follow the value through the datapath, and this one covers the blocks that never appear in that story because they do not carry a value: what is decoding, what is timing, what is remembering.
B is where the cursor is. A follows one half-cycle behind it until you pin it, so this reads as "what did this edge do" without any setup, and as "what happened between here and there" once A is somewhere else.
Every box is named storage on the die, read from its own
wires each half-cycle: the API's alua, alub,
idl, dor, abl, pclp
fields and friends. A box lights when its value moved at this
half-cycle. This is the layer the datapath tab's diagram rides on:
the values that exist between the registers, which is where the 6502
does most of its thinking.
Each bar is one instruction, fetch to fetch, its cells coloured by T-state. The glowing inset past a bar's end is that instruction still finishing: its T+ half-cycles run inside the NEXT instruction's fetch, which is where an ADC's sum finally reaches A. Click anywhere to go there.
Every bead is one of the PLA's product terms, watched on the die by its own name and grouped by the T-state its name carries. The lit set IS the instruction being decoded: the opcode's bits select the rows, the timing chain gates when each may fire, and everything the datapath does follows from which of these are high.
The carry row is read from the die's own carry-chain
nodes (alucin, C01..C78,
alucout), not computed: each dashed cell is the carry
arriving INTO that bit from the bit to its right. Bit 7's answer is
last because its carry has rippled through all eight slices, which
is why the flags cannot settle before the sum does.
Time runs left to right, one column per half-cycle; each touched address is a row. Reads cool, writes warm. Click to go.
Reads cool, writes warm, four addresses to a cell. This fills in as the program runs and empties on rewind: it is the footprint as of where the cursor is, not of the whole recording. The rows are every page the recording touches, so the map keeps its shape while you scrub.
S is the low byte of the next push's address; a push writes then decrements, a pull increments then reads, so the live bytes sit ABOVE the pointer. Out of power-on S is whatever its storage nodes came up as (reset only decrements it by three), which is why the subroutine example sets it with TXS before the first JSR: run that preset and watch return addresses appear here.
Each button pulses its pin low for eight cycles and releases it, then appends what the chip did to the end of this trace and jumps there. IRQ is ignored while the I flag is set, so run the interrupt example (or any program that has done a CLI) and give it a handler; NMI cannot be masked at all.
The 6502 has no interrupt sequencer. Predecode forces
the instruction register to $00, which is
BRK, so IRQ, NMI and reset all run the BRK sequence and
only the vector and the B flag differ. Everything above is read out
of this recording: the byte that was actually on the data bus, what
each push wrote, and the vector the chip fetched.
The datapath diagram and its narration are generated from these same booleans, so the picture cannot disagree with the words.
Every request to the API carries the whole machine and every response carries it back, so a machine is a value rather than a session. A value fits in a link.
Not a reading of the names: every container here is walked out of the switch network, and between them they cover every node the netlist touches, exactly once. The same derivation the chip map draws.