Where the data came from
A chip dissolved in acid, photographed, and redrawn by hand.
Nothing on this site would exist without a physical 6502 being destroyed. The polygons every page draws, the transistors the solver switches and the names the analyses are seeded from are one team's trace of one decapped die. This page is what that took, and what happens when the account of it is checked against the chip it produced.
Loading the chip…
Written, not measured
The talk
続きを読む
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.
Written, not measured
There was nobody left to ask
続きを読む
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.
Written, not measured
Opening the package and photographing what is inside
続きを読む
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.
Written, not measured
Geometry becomes a netlist, and a netlist is the whole chip
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.
Measured
The claims, asked of the chip
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.
Run on the chip
The BRK that gets lost
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.
| IRQ asserted | Pushed address | B flag | Serviced as |
|---|---|---|---|
| never | BRK + 2 | set | BRK |
| 1 to 2 half-cycles early | BRK + 2 | set | BRK, the interrupt missed its sampling point |
| 3 to 6 half-cycles early | BRK | clear | IRQ. The BRK is lost |
| 7 or more half-cycles early | BRK - 1 | clear | an ordinary IRQ, before the BRK was fetched |
In the middle band the handler is given the address of the BRK itself with B clear, so it cannot tell a BRK happened, and the skip past the byte after BRK never occurs.
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.
Measured
What the talk asked for, and where it stands
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.
Understand the random control logic
The talk is candid that nobody had found a way to make this part of the chip legible. NMOS builds logic exactly one way, which turns out to be enough: a pullup holds a node high and a pulldown network to ground beats it, so every static gate is an inverted sum of products. Reading that rule off the switch network recognises … gates, with … node left over.
Test other emulators against a perfect one
Done here in the opposite direction: the original JavaScript engine is the oracle, and this implementation is the thing under test. Every node is compared at every half-cycle rather than just the registers, because matching registers would only show agreement about the 6502 while matching nodes shows agreement about the silicon.
Simulate any chip made the same way
The talk's strongest structural claim is that this style of emulator never grows: you add polygons, not code, and the same engine runs any chip from the same process, or something that is not a processor at all. That is now a library rather than an argument. The engine names no chip, and the 6502, the 6800 and the Z80 load and settle through identical calls.
Break transistors and see what still works
Not built. The talk describes disabling transistors and finding that a test program still passes, which measures the coverage of the program rather than the health of the chip. It is the one idea on the list that nothing here does, and it needs no new die data: it is a property of the solver.
Open
Whose work this is
The die trace 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 talk is Michael Steil's. This page is our account of it and our own measurements against it, and where the two disagree the disagreement is on the page rather than smoothed away.