EEVblog #491 - Nintendo 64 Game Console Teardown

[EEVblog]

What's inside a 1997 vintage Nintendo 64 gaming console?

[marshallh]

All the silicon in the N64 was manufactured by:
1. NEC (CPU, RCP, RDRAM)
2. Rohm (linear a/v)
3. Sharp (regulators, security/contorller PIF)
4. Macronix (rambus clock generators, mask roms)

Of course the cart ROMs were second sourced from a variety of fabs.
NEC developed a 0.65um process just for this product.


All glue logic was integrated into the RCP which also contained a MIPS R4k with vector instructions and rasterizer.

I had this chip decapped - here are the pics:

Annotated:





The blotched portion says RCP Rev 2.0. This was the shipping silicon. 1.0 had a few bugs related to audio DMA, rasterizer hangs, so on.

I will post more when I get back from dinner.

[EEVblog]

Awesome pics!

[free_electron]

74hc125. Quad tristatable inverter.

The SGI logo is on both the cpu and gpu. SGI = Silicon Graphics Incorporated.
Yep. The guys that did all the gi end graphics workstations like the onyx and indi. They designed the MIPS architecture. It was their baby.

[marshallh]

The chip was designed with Verilog and NEC cell libraries. Verification was done with a C sim and verilog in parallel on SGI Onyx machines.
Early devs (Rareware, Paradigm Simulation, Nintendo EAD) had access to the basic C simulation libraries. This let them start writing the games before SGI was done taping out the chip.

The first fab run was used to build the 1.0 SGI Indy expansion boards. It is basically a N64 on a board that plugs into a GIO expansion slot. It had 16mb DRAM onboard so you could upload the ROM image over th GIO bus and debug it right there on the same machine.

This picture is not mine, it's from http://www.schrotthal.de/sgi/ultra64/



That is a Rev 2.0. Note the typo on the "developmnet" label. Hehe. The boards were done in Orcad/viewdraw. I am not sure what Nintendo used to do their own boards. They basically took the finished "reference" design from SGI and reimplemented it. SGI designed the entire system from the ground up, with the exception of the security system.

[marshallh]

The security system.

The PIF inside the N64 contains a small 2kb IPL that the R4300 cpu boots at power-on reset. This is mapped to the cpu's reset vector via the RCP.
However, the PIF will not load the next IPL until it talks to the security chip that is in each cartridge.

I have both chips decapped and I will try to get them posted up here soon.

PIF is actually a Sharp custom labeled part. It is their own SM5 4-bit microcontroller. You take the core and slap on whatever IO you need. In this case it has 1kbyte mask rom internaly (in addition to the IPL). My theory is that all the controller polling (using a manchester encoded 1wire signal) and serial comms with the RCP glue logic is done by the huge amount of cell logic on the chip. It is like a cheap ASIC.

In the cartridges is where the CIC lives. It is also the exact same SM5 core, 1k rom with 32 nybbles of RAM.



Full die image: http://retroactive.be/cic/cic_20x_die_image.jpg (Credit - Dr decap)

Using a SPI-like interface they constantly talk to each other while turned on, after exchanging the following info that is cooked into each CIC's mask ROM (there were about 14 variations):
 - Region code (NTSC / PAL)
 - "Lockout code", 5 different types

Here are the PIF and CIC dies side by side. You can see the identical SM5 cores in both (they are mirrored) sans IO in the PIF. And the right area is all the cell logic.
Bottom left are the SM5's own mask rom (yellow) and the MIPS cpu's IPL (blue)

Photo credits: Anonymous friend

[OzOnE]

This is fantastic stuff, Marshall. 

I think that documenting every aspect of these older systems is very important.
Many of these systems still hold a lot of discoveries which need to be uncovered for accurate emulation / preservation in the future.


OzOnE.
P.S. I liked your Mask ROM decoding vid btw, keep us updated.

[senso]

And this is why this forum is so epic, post something, and like magic there is always a couple of persons that know a LOT about it.
Great info, and even better images, love to see the decaped chips 

[marshallh]

Development carts:

Most were connected to a host comoputer via SCSI with onboard DRAM.

KMC Partner64 (sorry I can't remember the photo credits for this)


IS-Viewer (was used for development of Zelda - Ocarina of Time)


Rareware late development board.
Around late 1998 Rare contracted ALPS (they also made the 64DD expansion) to build them a more capable development board. It has a 68k on board with dual port RAM, 64mb DRAM, and SCSI connection to the host PC.
This was used for the development of Conker's Bad Fur Day and probably Perfect Dark/others.


And my own that I designed (sorry couldn't help myself )


The console was built into the LodgeNet and "Gateway 64" inflight entertainment systems. Lodgenet offered pay per play hotels, the rom images were streamed via SCSI from a host box onto the top board. Video was transmitted over coax to the hotel room.

Photo credit: willis82


SN Systems PsyQ cart - Analog Devices cpu


Will cut this short to keep from blabbing on endlessly.

[cloudscapes]

Thanks for this!

I love oldschool game console teardowns. In no small part because I actually currently work in that industry!

[Stonent]

Reality was an SGI branding that a number of their products had i.e.
Reality Engine: http://en.wikipedia.org/wiki/RealityEngine  (N64 is somewhat related to this)
Infinite Reality I, II and III: http://en.wikipedia.org/wiki/InfiniteReality

I had an SGI Indy that I picked up off of Ebay about 10 years ago that's in storage now
Indy R5000SC/150Mhz
128MB RAM
8bit Newport Graphics
36GB IBM UltraStar 10K (Added this one myself)

I didn't like the 8 bit graphics but never wanted to cough up the money for a 24bit board.  They also had a 3D card but it was almost never paired with the R5000 processor because the R5000 processor could do graphics calculations faster than the chip on the 3D board.

There used to be a guy known as ChicagoJoe back in the day who was building his own upgrade boards for SGI O2 workstations.  He would build boards to replace the 350MHz RM7000 chip with a BGA 600MHZ PMC Sierra RM7900 that would actually run faster than the R10000 boards.

In case anyone was interested in that cool bit of hardware hacking, it all took place here:

http://forums.nekochan.net/viewtopic.php?f=3&t=1071&start=120

[marshallh]

I actually remember reading that a while ago. They really benefited from the die shrink.

I always did want an SGI machine but never ended up with one. Pretty inept with unix systems as well. They are very neat hardware though.

[Ed.Kloonk]

Quick (dumb) question?

Why have a 3.3v power input along with the 12v input? There's already a 5v reg on the board so why not put a 3.3v reg on there also?

[Stonent]

Quick (dumb) question?

Why have a 3.3v power input along with the 12v input? There's already a 5v reg on the board so why not put a 3.3v reg on there also?

Maybe they moved that to the PSU to save on heat.

[c4757p]

Because then it would be compatible with any off the shelf 12V plug.[/cynic]

[terriea]

Thanks marshallh for that sweet console hardare porn ! keep it flowing !

What about the memory expansion pack ? What's inside ? Is that a simple Ram chip with a connector or there is something more ?
Does the existing packs reach the hardware limits or could we theoretically pack more RAM ?

[TacticalCode]

Sweet! I can remember the day I went to Toys'r'Us (only time I've been there) with my dad to buy the N64, I must have been like 4-5 years old back then 
Unfortunately we sold the N64 when we got a Gamecube, bad decision 

[Kaluriel]

Nice to see a console teardown, we should send you some more

[N2IXK]

The non-soldered cartridge port is a good idea.

That connector sees a lot of wear and user abuse, and being able to swap it out without soldering is a big plus for serviceability.

[amyk]

PIF is actually a Sharp custom labeled part. It is their own SM5 4-bit microcontroller. You take the core and slap on whatever IO you need. In this case it has 1kbyte mask rom internaly (in addition to the IPL). My theory is that all the controller polling (using a manchester encoded 1wire signal) and serial comms with the RCP glue logic is done by the huge amount of cell logic on the chip. It is like a cheap ASIC.

In the cartridges is where the CIC lives. It is also the exact same SM5 core, 1k rom with 32 nybbles of RAM.

Looks very similar to the one in the NES:
http://visual6502.org/images/pages/Nintendo_3193A.html

[Alexei.Polkhanov]

74hc125. Quad tristatable inverter.

Hmm, isn't it a NON-inverting buffer? (http://www.onsemi.com/pub_link/Collateral/74HC125.REV0.PDF)

[Kernel]

From what I remember (and I have spent many many hours over the years playing N64 games) the system would not sit there 'waiting' for a cart if you turned it on without one in, after placing in the cart it was necessary to power off the system and power it back on for the game to load.

[Winston]

74hc125. Quad tristatable inverter.

The SGI logo is on both the cpu and gpu. SGI = Silicon Graphics Incorporated.
Yep. The guys that did all the gi end graphics workstations like the onyx and indi. They designed the MIPS architecture. It was their baby.

SGI was hot stuff at the time the N64 came out.  From Wikipedia:

For eight consecutive years (1995–2002), all films nominated for an Academy Award for Distinguished Achievement in Visual Effects were created on Silicon Graphics computer systems.

Conventional wisdom holds that SGI's core market has traditionally been Hollywood visual effects studios. In fact, SGI's largest revenue has always been generated by government and defense applications, energy, and scientific and technical computing. The rise of cheap yet powerful commodity workstations running Linux, Windows and Mac OS X, and the availability of diverse professional software for them, effectively pushed SGI out of the visual effects industry in all but the most niche markets, as studios adopted newer, cheaper technology.

On April 1, 2009, SGI filed for Chapter 11 again, and announced that it would sell substantially all of its assets to Rackable Systems for $25 million. The sale, ultimately for $42.5 million, was finalized on May 11, 2009.

[marshallh]

What about the memory expansion pack ? What's inside ? Is that a simple Ram chip with a connector or there is something more ?
Does the existing packs reach the hardware limits or could we theoretically pack more RAM ?

The "expansion pak" is just another 36bit rambus chip on a high density connector, with terminator resistors.
The "jumper pak" is just terminating resistors and loopbacks for the flyby serial interface and clocks.
The topology actually reminds me very much of modern day DDR3 dimms, where the address/control signals are not wired in a tree T arrangement, instead they are wired in a loop going through each part in series. Whereas the Rambus design runs the clocks serially to get around the data skew. There are two clocks so that each direction is source synchronous.
The IPL depends on the game but I believe it will loop through the initialization of each RDRAM in the chain as part of the boot process. I've booted mine with 12mb ram before (The normal max is 8mb) and it worked fine. Obviously games are coded with a fixed memory map in mind so nothing beneficial comes as a result. You're only limited by signal integrity and the distortion caused by each chip loading the bus.

74hc125. Quad tristatable inverter.

Hmm, isn't it a NON-inverting buffer? (http://www.onsemi.com/pub_link/Collateral/74HC125.REV0.PDF)

Yes, it's used as a 4bit open collector buffer, to keep the PIF inputs from blowing up if static shock is delivered to the 1wire controller interface.
4bits = 4 controllers

Looks very similar to the one in the NES:
http://visual6502.org/images/pages/Nintendo_3193A.html

It is the spiritual successor, the arch is similar but not as crusty. For example, the LFSR program counter is now a regular linear PC. However there is no stack pointerr. You just get 12bits of stack and that's it. I dumped out the rom and wrote a disassembler, but going through the code is completely horrible, with poorly named mnemonics and extremely obtuse algos. Writing PIC assembly is like coding high level Java compared to this.

[adam1213]

Methods of opening nintendo consoles https://www.eevblog.com/forum/chat/can't-open-nintendo-consoles-or-carts-oh-yes-you-can!/msg37205/#msg37205

[FrankBuss]

Nice board layout. They managed to do it with just two layers. But I guess not that difficult, if you can design your own chips.

[Rerouter]

as far as console CPU decapping goes, is there a reason why its been avoided on much more complex things like an Xbox? is it the sheer area of the die or is it more than there are many many layers,

[marshallh]

as far as console CPU decapping goes, is there a reason why its been avoided on much more complex things like an Xbox? is it the sheer area of the die or is it more than there are many many layers,

Well the Xbox cpu is just a Pentium III, and the graphics just a nVIDIA derivative. Even so, you are right that more modern high-current packages typically have more complex power delivery structures. For example, graphics ASICs in the last 10 years or so have power and ground metal meshes laid over the die. It is really annoying to try to get around these and while it's no problme for those with the right tools, it makes it harder for the hobbyist decapper.

[David]

I got half way through reverse engineering the N64 PCB in order to make my own portable version. This information may be useful to some people (not my own):

On the early N64's (NUS-CPU-01 to NUS-CPU-04) the DAC and Video Encoder chip are separate. the DAC is labelled 'VDC-NUS' (Or 'VDC-NUS A') and takes the digital video data directly from the RCP and outputs RGB. This RGB is then sent to the separate 'ENC-NUS' video encoder chip wheres its encoded into Composite and S-Video. It is possible to perform an RGB mod on these consoles because you can tap the RGB signals from inbetween these two chips.

The AVDC-NUS (NUS-CPU-05) combines the DAC and the Video Encoder together into one chip (It actually also combines the Audio DAC aswell) Which means that it converts to RGB internally and then encodes directly into Composite and S-Video - so there is no way for us to tap into the RGB signals anymore   

The Video/Audio chip progression seems to go like this:-

NUS-CPU-01 to NUS-CPU-04 (Early-ish NTSC N64's)
VDC-NUS - Video DAC
ENC NUS - Video Encoder
BU9480F - Audio DAC
-------------------------------------------------------------------------
NUS-CPU(P)-01 (Early PAL N64's)
DENC-NUS - Combined Video DAC and Video Encoder
(The DENC-NUS chip was only ever used in PAL consoles)
BU9480F - Audio DAC
-------------------------------------------------------------------------
NUS-CPU-05 (Mid NTSC N64's)
AVDC-NUS - Combines Video DAC, Video Encoder and Audio DAC into one chip
(The AVDC-NUS was only ever used in NTSC consoles)
-------------------------------------------------------------------------
NUS-CPU-05-1 onwards (Late NTSC N64's) and NUS-CPU(P)-02 (Late PAL N64's)
MAV-NUS - Combines Video DAC, Video Encoder and Audio DAC into one chip
-------------------------------------------------------------------------

The AVDC-NUS and MAV-NUS chips seem to share exactly the same pinout. It is my guess that they are both almost identical and only differ in that AVDC-NUS chip can only use NTSC color encoding (Just a guess) whereas the MAV-NUS can do both PAL and NTSC color encoding by making one pin high or low.

[lilshawn]

The "jumper pak" is just terminating resistors and loopbacks for the flyby serial interface and clocks.

yes, absolutely correct.

Anybody else remember RDRAM memory? you had these continuity "dummy" sticks to terminate the bus (called CRIMMS) to continue the signal to the termination on the main board... same thing here, you need to have the "jumper pack" installed (or the memory expansion) to have the RDRAM operating. This is why you are seeing no action on the ram.

[andersm]

The team that designed the N64 chipset later went on to found a company called ArtX, where they designed the GameCube graphics chip for Nintendo. ArtX were bought by ATI, where they worked on the Wii's graphics chip and the Radeon 9700.