The figure, as data
The diagram everyone learns this chip from, asked to prove itself.
Every datasheet for this processor opens with the same picture: a column of registers, a couple of buses, an adder, and the decode logic off to one side. It is how most people first meet the 6502. This page encodes what that figure claims as a dataset, draws it from that dataset, and then puts every block it names to the silicon.
Loading the chip…
Nothing below is traced. The dataset carries only the claim: a label for each block, and the name this die uses for the thing being claimed. Where each box sits, how wide the bus beside it is, which functional block owns it and whether it exists at all are answered by the published measurements, the same ones every other page here reads. A block that did not resolve would say so in place of its width rather than quietly disappearing.
The rails are the buses. Two of them carry a dashed edge: those are the ones the published figure does not draw, and finding them is the point of the row that differs below.
Measured
Every block the figure names, resolved
One row per block, and the two halves of the figure are answered by different questions. A datapath box is a claim about a bus, so it resolves to a name and a count of wires. A decode or timing box is not: it is a claim about a region, a place where work happens, and the only honest answer is how much silicon is filed there. Forcing the second through the first would mean inventing a width for something that has none.
The owning block is where blocks.rs files those signals when it grows the twelve functional regions out of the die's own names. The last column asks a harder question, and only of the datapath: whether the blueprint derivation, which knows nothing about any datasheet, arrived at the same unit independently.
| In the figure | On this die | What was measured | Functional block | A derived unit |
|---|
Measured, not written
What the figure gets right, and the one thing it does not
Each row pairs a claim the figure makes with the same question put to the chip. Nothing below is written down as a verdict: every row carries a function that re-derives the answer from the published measurements, and the verdict is the comparison.
Why this page exists
A block diagram is a claim, not a photograph
The figure is a good one. It has taught this chip to more people than anything else ever printed about it, and the measurements above agree with nearly all of it: every block it names is a real, named structure, and the wiring mostly respects the boxes it draws around them.
What it cannot show is the thing that only a switch-level model can. It draws one internal bus because one bus is enough to explain what an instruction does. The die has two, and the traffic between them runs through a pass transistor that a box-and-line drawing has nowhere to put. That is not an error in the figure so much as the boundary of what the form can express, and it is exactly the boundary this whole site exists on the other side of.
The Blueprint is the same diagram derived from scratch: the units, the paths, the control line on each path and the order they sit in are all computed from switch topology, with no figure consulted. Reading the two together is the point.
Credit
Sources
The architecture described here is the one published in the MOS Technology hardware manuals for this processor family. This page is not a reproduction of that figure: it is our own dataset of what the figure claims, laid out by our own rules and answered by our own measurements. The original drawing belongs to whoever holds the rights to it.
The die trace those measurements come from is by Greg James, Brian Silverman, Barry Silverman and Ed Spittles, and is licensed CC BY-NC-SA 3.0. Those terms carry to everything on this site.
The derived diagram Where the die data came from Credit and licence