A chip dissolved in acid, photographed, and redrawn by hand.

In December 2010, at the 27th Chaos Communication Congress, Michael Steil gave a talk called Reverse Engineering the MOS 6502 CPU, subtitled 3510 transistors in 60 minutes. It covers the chip from three directions: the programming model, the physical die, and what the first two look like once you can see the second one working.

The number in that subtitle is the number this simulation switches. It is not a coincidence or a round figure: it is the count that fell out of the trace being finished, and it is the same count the engine reports today.

Ed Spittles was originally to have presented the die half and did not, so the account of the process below is second hand even in the talk. The team is Greg James, Brian Silverman, Barry Silverman and Ed Spittles.

The recording The visual6502 archive Credit and licence

The obvious way to learn how a processor works is to ask whoever made it. For this one that route is closed twice over.

MOS Technology was founded in 1974 by people who had left Motorola, and shipped the 6502 in 1975. Commodore bought the company in 1976 and went bankrupt in 1994, after which its assets were split between several buyers. There is no company to write to.

The deeper problem is that even an intact company would have had little to send. The 6502 was laid out entirely by hand: the masks were cut in plastic film by layout engineers working at wall scale, then reduced photographically. There was no design file, because there were no computers in the loop to hold one. A few schematic sheets have surfaced over the years, in varying states, and one hand reconstruction was made in Hungary by Beregnyei Balázs, who derived a complete schematic from his own photographs of an R6502 and wrote it up. But there is no authoritative machine-readable description of this chip anywhere, and there never was.

Which leaves the chip itself as the only primary source.

The plastic package is removed with hot sulfuric acid, applied directly to the part. Done carefully the die survives intact and the chip still works afterwards, which matters more than it sounds: a decapped part that still runs can be probed electrically and compared against the picture.

The surface is then photographed through a microscope in many small, overlapping frames and stitched into one image, which for this die came to roughly two hundred megapixels. The talk notes that this was more than the job needed, and that about six thousand pixels square would have been enough to recover everything.

One photograph is not sufficient, because the structures are stacked. The metal wiring hides the polysilicon, which hides the diffusion, and from directly above it is not always possible to say which layer a feature belongs to. So the layers are chemically stripped and the die is photographed again underneath. That step is irreversible: it consumes the chip. This is why the trace is a one-way process and why a single team doing it carefully is worth more than many doing it casually.

The images are then vectorised by hand. Someone draws the outline of every conducting region on top of the photographs, with a purpose-built tool, producing polygons rather than pixels. This is the slow part and it is pure labour. What comes out the far end is a geometric description of the chip: a set of shapes, each on a known layer.

A transistor in this process is not a component that was placed. It is a place where polysilicon crosses diffusion. So once the polygons exist and their layers are known, the transistors can be found by intersection, and the wires by which polygons touch. That yields a netlist: every switch, the node that gates it, and the two nodes it can join.

The claim the talk makes at this point is the one worth pausing on. The netlist alone specifies the complete working of the processor. Not a summary of it, not a model of it that has to be corrected against a datasheet afterwards. Everything the chip does, including the parts nobody documented, is a consequence of that switch network.

This site is a test of that claim. It contains … transistors across … nodes and no model of a 6502 at all. There is no instruction table in the simulation path, no cycle counter, and no register that is stored anywhere but in the nodes that physically hold it. Every number on every other page of this site is read back out of that network after settling it. The instruction decoder alone, the block the talk singles out as where the chip's personality lives, is … of those transistors.

The two files it is built from are the polygons and the transistors of that trace. They are CC BY-NC-SA and they are not this project's work: see Credit.

A talk is prose, and prose about silicon is exactly the thing this site exists to stop taking on trust. So each claim below is paired with a function that asks the same question of the published measurements, of the … decode product terms and everything else derived from the switch network, and the verdict is computed by comparing the two rather than written down. If this chip stops agreeing, this page changes on its own.

One claim could not be checked from a published file, because it is about two things happening at the same moment. It is also the best story in the talk, so it was worth running.

The 6502 has no separate interrupt sequencer. Its predecode logic forces the instruction register to $00 when an interrupt is pending, and $00 is BRK. So the hardware runs the BRK sequence for IRQ, NMI and reset alike: push the program counter, push the status register, fetch a vector. Only the vector and the B flag differ. It is a real saving, and it is the kind of thing that is invisible from outside until it costs you something.

What it costs is this. A genuine BRK being fetched at the instant an interrupt arrives has nothing left to distinguish it, and is serviced as the interrupt instead. The BRK is lost.

We reproduced that on this simulation by asserting IRQ at every half-cycle offset around a BRK's own opcode fetch, and reading back what reached the stack. The offsets are offsets from the fetch, found by running until sync, so nothing here depends on a remembered half-cycle number.

The same experiment settles the other half of the claim. Reset is said to run the identical sequence with the writes suppressed, and it does: nothing lands in the stack page, and the stack pointer still moves by three, one for each push that was not performed. That is why a 6502 comes out of reset with whatever stack pointer it happened to have, minus three, and why this site's stack readout refuses to report a depth.

Follow any opcode half-cycle by half-cycle on Trace

The last part of the talk is a list of things that ought to be done next. It is a useful list to be measured against, because some of it is now done and some of it is still open, and the difference is not the part anyone would have guessed.