The chip
counts nothing.

The timing nodes are stages of a shift register clocked by the same two-phase clock as everything else, and each stage is a latch built from a pass transistor and an inverter, structurally identical to the pipeline latches that carry the decode PLA's output to the control lines.

They are active low on the die, which is worth knowing before reading any of it: a state is selected when its node is pulled down, not when it goes high. The same convention caught out the control-line analysis on the Decode page.

What ends an instruction is a product term. The chain would happily keep advancing; something has to stop it. Pick any opcode above and the panel lists the terms that arrive in its final cycle: high then, and not before. For 161 of the 244 instructions that is the instruction's own op-T0-… term, named for the state it ends: $20 ends on op-T0-jsr, $48 on op-T0-php/pha. Each links through to the Decode page, where you can see every opcode that fires it.

Arriving is coincidence in time, not proof of cause, and it is worth being clear about the difference. What is shown is that a term went high in the cycle the chain reset and had not been high before. The naming agrees, and the pattern holds across two thirds of the instruction set, but this page does not trace the wire from that term to the chain. It was tried: a backward walk from the timing nodes, the same one that resolved 32 control lines on the Decode page, reaches only four product terms here and none of them are the ones observed arriving. That trace is too weak to corroborate anything, so it is not shown rather than dressed up.

The remaining 83 split two ways. For 62 of them nothing new arrives at all, because every term high in the last cycle was already high earlier. Read-modify-write instructions like $FE and returns like $60 are in this group, and whatever ends them is not a term that appears at the end. The other 21 do have something arriving, but not a T0 term. Neither group is explained here.

A measurement that agrees with the datasheet is only interesting if it could have disagreed. Nothing here consults an instruction table, so the counts are free to be wrong: they come from watching the sync pin. Thirty-three documented opcodes were checked against their published cycle counts, covering every addressing mode and the stack, jump and read-modify-write forms. All thirty-three match.

The undocumented opcodes are where it gets more interesting, because there is no published answer to agree with. Twelve of them run for eight cycles, one longer than any documented instruction, and they are exactly the twelve read-modify-write forms using indexed indirect addressing. Nothing special was built for them; they take eight cycles because that is how long it takes the chain to get to a term that stops it.

Twelve opcodes never reach another sync. They are marked ∞ in the grid, and they are not a failure of the simulation or a timeout. The chain stops advancing and the chip sits there. These are the opcodes usually called JAM or KIL, and the list falls straight out of the measurement: $02 $12 $22 $32 $42 $52 $62 $72 $92 $B2 $D2 $F2.

They needed a decision in the exporter rather than a fix. A run that never terminates has to be recorded as such: the alternative is a timeout quietly reported as a cycle count, which would put a plausible number next to twelve opcodes that do not have one.