27C3 - Version 1.6.3
27th Chaos Communication Congress
We come in peace
| Referenten | |
|---|---|
|
Michael Steil |
| Programm | |
|---|---|
| Tag | Day 2 - 2010-12-28 |
| Raum | Saal 1 |
| Beginn | 12:45 |
| Dauer | 01:00 |
| Info | |
| ID | 4159 |
| Veranstaltungstyp | Vortrag |
| Track | Hacking |
| Sprache der Veranstaltung | englisch |
| Feedback | |
|---|---|
|
Haben Sie diese Veranstaltung besucht? Feedback abgeben |
Reverse Engineering the MOS 6502 CPU
3510 transistors in 60 minutes
The MOS 6502 CPU, which was designed in 1975 and powered systems like the Apple II, the Atari 2600, the Nintendo NES and the Commodore 64 for two decades, has always been subject to intense reverse engineering of its inner workings. Only recently, the Visual6502.org project has converted a hi-res die-shot of the 6502 into a polygon model suitable for visually simulating the original mask at the transistor level. This talk will present the way from a chip package to a digital representation, how to simulate transistors in software, and new insights gained form this research about 6502 internals, like "illegal" opcodes.
The presentation only requires a basic understanding of assembly programming and electronics, and is meant to teach, among other things, the methods of efficient and elegant chip design used in the early years of integrated CPUs. The talk consists of three parts. The first part, "6502 from top down", describes the programmer's model, as well as the basic layout of the components of the CPU. In the second part, "6502 from bottom up", we describe how to decap and photograph chips, convert each physical layer of the chip into a polygon model, and how to finally convert this into a network of wires and transistors suitable for logic simulation. The third part, "6502 from the inside out", explains the inner workings of the CPU: how the logic blocks work together, how an instruction is decoded by the PLA ROM into controlling these blocks and busses, and how details like interrupt delivery work. Finally, this information can be used to describe and explain undocumented behaviour, like illegal opcodes and crash instructions, and explain bugs like the BRK/IRQ race, the ROR bug and spurious reads and writes in certain situations.