This page serves as a repository for chip images I have traced and analyzed.
If you'd like to contact me, email quietust at either @qmtpro.com or @gmail.com - I'm also available on Skype as "Quietust", but you'll have to email me first as I only accept messages from existing contacts.
Nothing new to report for the past 3 months - I'm still here, but I've got nothing to work on.
After further examining the RP2C02 surface die shots, I've managed to locate several additional important bits: the VRAM address register (including part of the logic that resets only the horizontal scroll bits at the end of each scanline), part of the background render pipeline (and the fine horizontal scroll register used to index into it), and what appear to be the pixel/scanline counters used during rendering. I'll update the "Regions" pseudo-layer image later today.
I've also received news that the person who normally does the chip depackaging/delayering/photography for Visual6502.org has been abnormally busy for the past several months and does not expect to have any free time until early next year, so in all likelihood there will be no further progress on the Visual 2C02 for quite a long time.
Since nothing's been happening with the RP2C02 for the past month and a half, I've started tracing my first non-NES chip: the Motorola 68000.
I've been gradually altering the ChipSim visualizer to work better with non-CPU chips, most notably replacing the "sample program" with a way to interact with I/O ports. It isn't complete yet, but hopefully it'll be ready by the time I've got enough data to simulate the RP2C02.
In other news, I've just discovered a missing transistor in the RP2A03's DPCM address counter, which caused A12 to always be set after the counter was incremented. Fortunately, the new chip tracing workflow I'm using for the RP2C02 should be immune to this sort of mistake.
All chip images posted below are divided into several different layers. For ideal analysis, all of the images should be loaded as separate layers within a single master image using your graphics editor of choice, preferably making the Metal and Polysilicon layers partially transparent.
The layer descriptions below currently apply only to the chip images currently posted here, which all use depletion-load NMOS logic.
- Labels
- Not an actual layer on the chip, this simply serves to assign names to various signals for reference purposes.
- Regions
- Not an actual layer on the chip, this serves to group together certain parts of the chip according to their functionality for reference purposes.
- Metal
- This layer serves to connect different parts of the chip together, though older chips also use them to form the gates of transistors (instead of polysilicon). Newer chips often use multiple metal layers in order to save space.
- In my images, red-colored metal is connected to VCC (+5V), green-colored metal is connected to GND (ground), and blue-colored metal forms interconnects.
- Vias
- Much like those found on printed circuit boards, vias form connections between layers. In this case, they connect the Metal layer to the Polysilicon and Diffusion layers.
- In my images, vias are black.
- Polysilicon
- When a Polysilicon trace passes directly between and thus connects two Diffusion regions, it forms the gate of a transistor. Polysilicon can also be used to form wires which connect sections of the chip to each other, mainly to route Metal interconnects underneath each other. In some cases, polysilicon can also be used to form capacitors and resistors.
- In my images, polysilicon traces are purple.
- Buried Contacts
- Buried Contacts are just like Vias, except they cover larger areas and are used to form direct connections between Polysilicon and Diffusion without making transistors, thus avoiding the need to jump through Vias to the Metal layer and back.
- In my images, buried contacts are light pink.
- Transistors
- Transistors are one of the elementary components of electronics. Each transistor has 3 terminals - source, gate, and drain. When the gate receives a sufficient voltage, the source and drain are connected, otherwise they are disconnected. The source and drain terminals of transistors are formed from the Diffusion layer, while the gate is usually made of polysilicon (though some older chips use metal gates). In depletion-load NMOS logic, certain transistors are depletion-mode - always on, and generally used as pull-up resistors. Some chips also use depletion-mode transistors for design simplification (by allowing polysilicon to cross diffusion without forming transistors) or even to thwart reverse-engineering attempts.
- In my images, transistors are cyan.
- Diffusion
- Diffusion consists of conductive areas of silicon. Used alone, they can be used to form short interconnects or resistors, but their main purpose is to be used in pairs (along with Polysilicon traces running directly between them) to form the source and drain terminals of transistors. In some cases, diffusion can also be used to form capacitors.
- In my images, red-colored diffusion is connected to VCC (+5V), green-colored diffusion is connected to GND (ground), and yellow-colored diffusion floats to whatever voltage is applied to it.
Each image is also timestamped in the tables below - since I trace the individual layers manually (as opposed to using sophisticated image analysis tools), I occasionally upload new versions whenever I find errors.
The RP2A03 is the NTSC version of the NES CPU; this particular chip is revision G. It contains 5 sound channels and a slightly modified (to remove decimal mode) MOS 6502. The 6502 itself is not included in the following layer images, mainly due to its complexity (and the fact that the Visual6502 project has already traced a real 6502).
The lack of decimal mode was seemingly intentional - several specific transistors were removed with surgical precision (one of which resulted in a strange "via to nowhere" observed at the very center of the following 2 images: 1, 2), the result being that the 6502's ALU no longer operates in decimal mode when the status register flag is set.
The Diffusion layer image is not 100% correct, as it was traced using the assumption that all intersections with Polysilicon formed enhancement-mode transistors (excluding the depletion-mode transistors which form pull-up resistors recognizeable both visually and programmatically). This assumption has already been proven false by the barrel shifters and full adders used in the frequency sweep logic for the 2 square wave channels - the layer image was updated to take this into account, but other similar instances may yet be lurking within the chip.
Using several special tools (and the Visual 6502 chip simulator and data), these layer images have been successfully combined to form The Visual 2A03.
Using the experience I've gathered from tracing this RP2A03, I'd eventually like to trace another one with the 6502 included, though I'll only do it if I can get better quality layer images (higher resolution, cleaner, and better focus), ideally from a fresh chip.
Errors found and fixed since making the simulator:
- Sprite DMA: 1 short (between APU clock and CPU /RDY control, prevented the 6502 from actually working)
- Square channel 0: 4 shorts (between output bits and debug readback logic)
- Square channel 0/1 duty cycle generators: 2 bad interconnects (for duty cycle mode 01)
- Frame timer: 1 bad interconnect (in LFSR's XOR gate)
- DPCM: 4 missing transistors in timer LFSR, 1 missing via in DMA logic, 1 missing transistor in address counter
- Noise: 1 missing via in LFSR feedback mode register
Known issues:
- The embedded CPU is a real 6502, so decimal mode actually works
- Several hacks had to be added to the triangle channel in order to eliminate race conditions
Interesting bus names to monitor (in Expert mode, "Trace these too"):
- (sq0/sq1/tri/noi/pcm/frm)_(name) - registers specific to various sound channels
- envp (sq0/sq1/noi) - envelope period / volume output ($4000/$4004/$400C)
- envt (sq0/sq1/noi) - envelope timer
- envc (sq0/sq1/noi) - envelope counter (volume output)
- len (all) - length counter
- out (all) - current output bits
- p (sq0/sq1/tri) - duty cycle period ($4002-$4003, $4006-$4007, $400A-$400B)
- t (all) - duty cycle timer (noi/pcm use an LFSR)
- c (sq0/sq1/tri) - duty cycle counter (phase)
- c (noi) - random number generator (LFSR)
- swpb (sq0/sq1) - sweep bit shift count ($4001/$4005)
- swpp (sq0/sq1) - sweep period ($4001/$4005)
- swpt (sq0/sq1) - sweep timer
- lc (tri) - linear counter timer
- en (all) - channel enable (write $4015)
- t (frm) - frame timer (LFSR)
- on (all) - channel active (read $4015)
| Last Updated | Size | Layer |
|---|---|---|
| Sat, 07 May 2011 03:13:35 +0000 | 25,993 bytes | Labels |
| Wed, 08 Jun 2011 00:27:13 +0000 | 70,564 bytes | Regions |
| Thu, 23 Jun 2011 19:51:18 +0000 | 78,070 bytes | Metal |
| Wed, 29 Jun 2011 21:53:34 +0000 | 64,739 bytes | Vias |
| Sat, 25 Jun 2011 00:39:15 +0000 | 122,666 bytes | Polysilicon |
| Fri, 24 Jun 2011 03:45:42 +0000 | 36,056 bytes | Buried Contacts |
| Thu, 18 Aug 2011 15:05:27 +0000 | 54,475 bytes | Transistors |
| Wed, 27 Jul 2011 02:45:46 +0000 | 147,997 bytes | Diffusion |
The RP2C02 is the NTSC version of the NES PPU. Much of its behavior has been determined via "black box" reverse engineering, but the actual implementation of said functionality remains unknown.
The NESdev community has donated several of these chips to the Visual6502 project. One has been depackaged and photographed (and was used to produce the layer images below), though it still requires further cleanup.
No further work can be done on this chip until it is delayered - I've made several attempts to trace the Polysilicon layer from what's currently available, but there are too many ambiguous areas caused by the Metal layer getting in the way, and several important areas of the Diffusion layer are completely obscured.
Once the chip is delayered, it'll probably take less than two weeks to trace the remaining layers and get a simulator working.
| Last Updated | Size | Layer |
|---|---|---|
| Thu, 11 Aug 2011 01:36:00 +0000 | 28,519 bytes | Labels |
| Wed, 12 Oct 2011 23:52:09 +0000 | 72,132 bytes | Regions |
| Sun, 14 Aug 2011 03:27:00 +0000 | 144,338 bytes | Metal |
| Sun, 14 Aug 2011 22:47:00 +0000 | 97,017 bytes | Vias |
The RP2A07 is the PAL version of the NES CPU. The only known differences from the RP2A03 are the clock divider (divide by 16 instead of divide by 12) and several timer lookup values (noise, DPCM, and the frame timer).
No die shots of this chip are yet available.
The Visual6502 project has one of these chips depackaged, but no plans to delayer or photograph it have been announced.
The RP2C07 is the PAL version of the NES PPU. The only known differences from the RP2C02 are the number of scanlines per frame, various timing details, and a different means of producing the video signal.
No die shots of this chip are yet available.
The Visual6502 project has one of these chips depackaged, but no plans to delayer or photograph it have been announced.
The 68000 is a CPU designed by Motorola, used in numerous computers including the classic Apple Macintosh and the Commodore Amiga. See Wikipedia for more information.
The layer image(s) below were traced directly from the 10000x11299 die shots available here.
| Last Updated | Size | Layer |
|---|---|---|
| Wed, 28 Sep 2011 00:14:06 +0000 | 291,949 bytes | Metal |
These are the tools I used to make the Visual 2A03. They may not be fully versatile and efficient, but they get the job done.
Last Updated Name Description Mon, 15 Aug 2011 00:14:09 +0000 convertsvg.php Converts exported SVG files to vertex lists for the tools below. Mon, 29 Aug 2011 20:10:44 +0000 check.cpp Checks polygon data for consistency - makes sure that each via and buried contact connects exactly two nodes together and that no metal/polysilicon/diffusion segments are hollow. Mon, 22 Aug 2011 15:10:53 +0000 netlist.cpp Reads in all of the layers, figures out which segments are connected to each other (and assigns node IDs appropriately), and builds segdefs.js and transdefs.js files for ChipSim. Mon, 22 Aug 2011 00:30:07 +0000 polygon.h Used by the above two programs, keeps track of the shape and location of each segment and quickly determines whether or not two arbitrary segments intersect. Using GIMP, select all segments in each layer image (using either "Alpha to Selection" or "Select by Color"), perform "Selection to Path" with advanced settings (Corner Threshold:150, Line Reversion Threshold:0.200, Line Threshold:2.00, and optionally Corner Surround:3), export path to SVG, then run convertsvg.php. If the SVG happened to contain any non-straight lines, it'll complain - go back into GIMP and fix the problem segments to make them more square, or recreate the Path with more strict settings. Once the SVG files are converted, run check, verify that there are no errors, then run netlist.