N64 CPU Upgrade

[RobIvy64]

Oh boy, I'm bored again and my soldering iron has been cold for far too long.

I've recently taken a renewed interest in the N64, specifically it's hardware.

Years ago, I enjoyed experimenting with overclocking the N64. Now, I want to take this a step further by upgrading the CPU.

The specific details on the CPU in the N64 have always been conflicting. We know it's an NEC VR4300, but the question is, is it a custom chip or just a stock VR4300 with the Nintendo logo branded onto it.

Early N64 SDKs running in the SGI Indy workstation used a stock NEC VR4300. This makes me think it's just an off-the-shelf CPU with the Nintendo logo etched in.

Here is a comparison of the Nintendo 64's CPU and the NEC VR4300.


How would swapping one VR4300 CPU with another be considered an "upgrade"? I've managed to source a 133 MHz-rated NEC VR4300 CPU in the same 120-pin QFP as the N64's CPU. My goal is to finally achieve the currently unattainable 3X multiplier setting. If successful, the CPU would be clocked at around 187 MHz, two times the normal speed.

Any thoughts? Maybe I have too much idle time.

[Lawrence]

Idle time is how great things get done.  =D

[RobIvy64]

After thumbing through the 268 page VR4300 series manual, I have learned a few new things that will help me to achieve new speeds without altering the bus.

I have also decided to install the VR4310. The main differences are the addition of new internal multipliers, along with a 167 MHz maximum clock rating.

Below is a snippet of the chart outlining the differences between the  VR4300, VR4305, and VR4310. Note that the 1.5x multiplier, as used in the stock N64, is only available with the 100 MHz-rated VR4300.



The VR4310 uses 3 pins to determine the internal multiplier (marked as DivMode0,1,2 respectively, see below). Installing the VR4310 in place of the stock N64 CPU, lifting pin 15 and pulling that to ground, should set the internal CPU speed to 156.25 MHz. This will be a good starting point!

[RobIvy64]

A VR4310 CPU can be harvested from an HP Laserjet 8100 formatter board, which can be had for about $20.

From pushing 17 PPM B&W copies, to running Super Mario 64! These old HP Laserjet logic boards are the best source for the VR4300 and 4310 CPUs.

I have one of these boards on the way! Now I just need an extra N64 to operate on!

[public-pervert]

I'm super excited to see where you'll get!

[RobIvy64]

Unfortunately, I have bad news to report .

It appears there IS some type of glue logic between the CPU and other components. Possibly some additional security.

I performed the CPU swap (which was a BITCH!) and soldered in a stock NEC VR4300-100. Checked continuity on all 120 pins (see part about it being a bitch), and got nothing. Blank screen. Put this one to bed, folks.

[RobIvy64]

Here is a scan of the Ultra 64 development board. Notice the stock VR4300 CPU. There is a small EEPROM between the CPU and GPU that is interesting. Maybe some of you will have some ideas.

[Lawrence]

That's a shame, I hoped this would turn out to be more exciting.

Hehe, 'developmnet board'.

[public-pervert]

Maybe the right guy to clarify things about the N64 hardware, is Marshallh. Try contact him over the Benheck forums.
I really believe that what you're trying, can be done 

[sonyqrio]

I think that this project is spectacular. So much so that I just had to register to post this comment.

I know what's wrong - why it doesn't work.

As is the case with many embedded CPUs, a small operating system is required to get the chip to do anything useful. In the case of the Nintendo 64, the operating system checks to see if a cartridge is connected and, if one is, starts loading the game by coping the program's data into RAM and jumping to the code for execution.

I'm almost 100% confident that N64s ship with stock NEC VR4300-100s (with a Nintendo branded logo on), as you have suspected, but you're going to have to rip the firmware out of the old chip and flash it to the new one.

If you look at the datasheet you've provided, you can see that the chip has a JTAG bus (JTDI, JTDO, JTCK, etc.) This is exceedingly convenient and will make this process easy. If you've had experience ripping firmware from CPUs before, you are at a major advantage. If not, no sweat. It's not that difficult, you just need the right tools. If you're interested in carrying this further, get yourself some JTAGing software, a JTAG programmer, connect the pins on the programmer to the respective pins on the CPU, and see if you get anything out of the chip. If not, there may be some enable line hiding somewhere that you may have to tie to 5v. You're going to have to use an unmodified N64 for this, as there's no way you're going to get the chip you removed powered up properly (or at least you shouldn't waste your time trying to get it to.) Make sure that when you're JTAGing you don't have any expansion pack inserted in the N64.

Once you've successfully ripped the firmware from an unmodified N64, getting it onto the modified one should be a breeze. Just do the process backwards. Feel free to email me if you have any questions. I'd love to see this work out. (My email is sonyqrio(at)me(dot)com).

Also, hey public-pervert. It's me, SonyQrio, from ModRetro.

[public-pervert]

Hey Qrio!
I remember following obsessively your worklog for the uGC. Good work!

Welcome to the forums btw 

[RobIvy64]

Interesting find. This would be beyond my capabilities. Maybe someone else can carry the torch. I'd be happy to sell the motherboard with new CPU at cost

[sonyqrio]

Awh. It's really not that hard! Programmers are really cheap. You've already gone this far, why not finish it up.

If you really decide you don't want to, I'd be willing to buy the board at a reasonable price.

[public-pervert]

I doubt Nintendo doesn't implemented any FW dump protection, but I still believe this can be done 

[RobIvy64]

I have about $30 invested in the N64 and CPU. If you want it for that it is yours.

[sonyqrio]

Sounds good. PM me your PayPal info.

[RobIvy64]

PM sent. Let's keep this project alive!

[Justin566]

Please post your progress!!

[sonyqrio]

I certainly will! RobIvy just sent me the board. It should be here by Saturday. Hopefully I'll have some time to mess around with it.

RobIvy, would you mind posting links to the resources you used during the swap? Eg. The datasheet for the processor and any other information that may have been useful to you?

[RobIvy64]

If you are successful, I might swap this VR4310 into an N64 and send it to you for programming

[public-pervert]

Can't wait to see where you'll get, Sonyqrio. Please keep us updated 

[sonyqrio]

Okay, so...

I got the board in from RobIvy. I also picked up an unmodified board to rip the firmware from which has arrived.

I'm using an AVR Dragon as my JTAG programmer alongside AVRDUDE to dump the firmware. I haven't had a chance to do any tests yet, but I will soon.

[RobIvy64]

The CPU in the modified board probably has some sort of HP Laserjet boot software 

[RobIvy64]

sonyqrio is probably too busy enjoying his ultra-fast N64 to be able to post an update 

[public-pervert]

He probably loose the interest 

[emu_kidid]

From #n64dev regarding the "firmware" programmed into the logic:
<marshallh> he needs to read the mips datasheet and learn why that makes no snese
<marshallh> it boots from the pif
<marshallh> it probably didn't work most likely because the solder job was slightly botched
<marshallh> or maybe one of the mode pins was strapped differently in the chip revisions
<marshallh> but yes it should be able to drop right in

[RobIvy64]

100% confident it was not my soldering job. I checked each pin for continuity from pin to pad.

[eb1560]

I just joined the forum moments ago after seeing a thread like this actually existed on the internet.  A few days ago I purchased my own NEC VR4310 (167 MHz) CPU from a merchant on ebay located in Hong-Kong.  Obtaining the VR4310 (167 MHz) seems to be rather easy nowadays, if anyone is interested: http://www.ebay.com/itm/120921407701?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649. I wonder how much the boundary scan can manipulate the console, and how high it can clock stably.

[Cybertronic]

I was also under the impression that the N64 OS was indeed on the CPU and it was indeed a system on a chip.

3.5 N64 CPU
N64 CPU is part of the MIPS R4000 family of processors. The N64 CPU consists of the following components:
an execution unit with a 64-bit register file for integer and floating-point operations
a 16 KB instruction cache
an 8 KB writeback data cache
a 32-entry TLB (Translation Lookaside Buffer) for virtual address to physical address calculation
The Nintendo 64 game runs in kernel mode with 32-bit addressing. 64-bit integer operations are available in this mode. However, the 32-bit C calling convention is used to maximize performance.
For more information on the R4300 and the operating system control of the CPU, see the MIPS Microprocessor R4000 User's Manual, R4300 Specifications, and Chapter 6, "N64 Operating System Overview".

[Lawrence]

I was also under the impression that the N64 OS was indeed on the CPU and it was indeed a system on a chip.

Certainly there's nothing in what you quoted that suggests it's a SoC design, and the image you included suggests exactly the opposite.  It clearly shows a CPU connected to the RCP chip by the MBUS.  I would guess that one of the following things is possible:

1. I don't know what a SoC is.
2. You don't know what a SoC is.
3. You're confusing the N64 with the iQue Player  which was a SoC N64 system released in China.

[Cybertronic]

You didn't have to be so blunt about it. 

So then the N64 OS is actually a thread loaded by the game pack when it loads the game possibly?

Every time I consult the manual its very sketchy about the NuSystem. I have been messing around with LibDragon and got things to boot but I still have no idea how the N64 actually operates. Mostly everything on the RCP is virtualized and is completely reconfigurable.

[Lawrence]

You didn't have to be so blunt about it.

I don't see anything particularly blunt in my reply, but Western society has developed a particular dislike of being corrected.  Perhaps you're inferring insult where none was implied.  I'm not sure how else I can tell someone "I think you're wrong, and here's why" but certainly if you have any suggestions you're welcome to PM me. 

[eb1560]

I guess no one has talked about the actual swapping of the CPU for some time.  I acquired two VR4310 167MHz chips which I have not tried to install, but would shed some light into the issues of a CPU swap on the N64.

The CPU-NUS or CPU-NUS A appears to have a pinout for the most part identical to the NEC R43xx CPUs, but they are not “just easily” swappable for at least one reason – if not taken into account, will brick the system.  Pin #8 on the R43XX series is designated as VDD (3.3V power input).  However, pin #8 on the NUS-CPU (A) on the N64 motherboard is not VDD, but actually VSS (GND), fed directly from the power supply.  Unless the R43xx pin #8 is detached or not connected, 3.3V will certainly fry the RCP through pin #100 (GND).  Divmode2 would need to be taken into account when setting clock registers too.  There could possibly be some other pins that may have been rearranged/reassigned for the N64 version of the CPU, such as JTAG; JTAG pins are hooked to the 3.3V low impedance rail (exceptions: JTDO is N/C and JTCK is connected to pin 44 on the cartridge and GND), if I am not mistaken JTAG pins should always be hooked to GND when not in use.  Overall, it seems the N64 used a variant of the R4300 with some pin rearrangements, and maybe it removed some “obsolete” functionality, such as JTAG/boundary scan (Nintendo probably did not want people using and become familiar with system's inner workings?), but kept everything else intact.  The early development boards did use a R4300 ES X:X (Engineering Sample?), no traces can be seen on the JTAG pins in images posted publicly;  the ES CPUs also had a slightly more complicated PLL filter than those in motherboard revisions 01 through 04, and 05 through 09-1.


Regarding the original post of this thread, the 3.0x multiplier is achievable, and have personally done it myself and have posted it elsewhere earlier this year (2014):

http://www.assemblergames.com/forums/showthread.php?51656-Mapping-N64-%93Overclockability%94-%96-achieved-3-0x-multiplier-but-not-3-0x-speed

To achieve the 3.0x multiplier, one has to cripple the RDRAM speed by 1/3, which is counterintuitive if one wants to increase N64 system performance – the limitation could possibly be with the RAC inside the RCP.  Someone posted that tampering with the ROM header can speed up a game without needing to overclock the CPU, by controlling the OS cycle counter.  The CPU is nowhere near being a limiting factor in the N64.

The only upgradable component on the stock N64 is the RDRAM, which I did modify in the link above – swapped with four NEC 600MHz 9-bit ICs, and clocked it up to “625MHz” (312 MHz) using a different xtal on X2.  There is no framerate improvement, but games speedup analogously to a CPU overclock, with some undesired side effects probably due to the RAC & RCP being outside of the 1:8 clock ratio - yet the system runs stable despite VI artifacts.

[MRKane]

Gidday,

Long time tinkerer, first time poster here. I've been working with replacing the RAM on the N64 board with something that has a lower latency as that appears to be the bottleneck in many of the higher aspect games. While the pinout seems simple enough it's the serial arrangement of the older board that are hampering my efforts. I noticed you swapped the ram out on yours for the NEC A60s, do you think that A50s would remove the latency issue while having the same speed as the original RDRAM chips? And do you have any suggestions on the ram replacement front? I'm also unsure as to how accurate the pinout information I've got is - might search this forum a bit deeper for that now that I've found it.

I hark from the GE/PD mod front, and did also wonder if the ROM header could be modified to offset the increase in overclock speed (kind of backwards to the suggestion earlier in the thread) so it'd remain at playspeed through the overclock - just a thought

[public-pervert]

You sound like a GE/PD speedrunner 

[MRKane]

LOL no! But I am part of the crowd that's been working on the editor for those two games, and it's always been the excessive use of transparents which pull PD down, which led me to wondering about the RAM, which led me to here. Another day of searching and I'm still no closer to finding a suitable replacement - getting close to a weeks worth of looking now, think I'm more at home inside code than hardware

[eb1560]

Gidday,

Long time tinkerer, first time poster here. I've been working with replacing the RAM on the N64 board with something that has a lower latency as that appears to be the bottleneck in many of the higher aspect games. While the pinout seems simple enough it's the serial arrangement of the older board that are hampering my efforts. I noticed you swapped the ram out on yours for the NEC A60s, do you think that A50s would remove the latency issue while having the same speed as the original RDRAM chips? And do you have any suggestions on the ram replacement front? I'm also unsure as to how accurate the pinout information I've got is - might search this forum a bit deeper for that now that I've found it.

I hark from the GE/PD mod front, and did also wonder if the ROM header could be modified to offset the increase in overclock speed (kind of backwards to the suggestion earlier in the thread) so it'd remain at playspeed through the overclock - just a thought

Hey, I guess I may have deviated from the topic on the N64 CPU replacement. 

Swapping the RDRAM chips out of the earlier N64 revisions is a bit tricky.  Desolder chips starting from the RCP towards the expansion slot, then solder chips starting from the expansion slot towards the RCP – use lots of flux and you should be fine.

As far as N64 console limiting factors go, the RDRAM isn't on the top of the list, it is really the RCP (fill rate).  I've seen this after having tampered with the console's crystals in various games for a long time – particularly when raising X1’s frequency, which increases the number of frame buffer reads from the RDRAM to the VI (video interface).  When the RDRAM is clocked at 500 MHz DDR, it can cope somewhere between 20 to 40% more frame buffer reads before hitting a brick wall in memory bandwidth (game dependent) – then the RDRAM clock (X2, also clocks CPU, RCP, PIF, Cart) needs to be raised further to permit more frame buffer reads.

If you want to tamper with RCP – RDRAM timings, the only place I can think of looking would be the R/W registers (0x03F00018) that every Concurrent RDRAM datasheet mentions: tRC, tRCD, tRP, tRPA?  I am not sure you will get a "performance boost" by messing with those settings.  If latency is the primary endpoint without editing registers, I’d put two Nintendo RDRAM36 NUS chips on a revision 04 board (with a jumper pack) to minimize the RCP – RDRAM talking distance, if there is latency improvement it would be incredibly minor and not perceivable.

I have not played with the ROM header clock rate setting, I think it is on 0x0004.  I would add that games base their internal timings on different N64 components: some use the CPU (thus CPU overclock overshoots timings), some use RDRAM/RCP/PIF/Cart (they are all based off each other), and others may use the video clock (VCLK generated by X1).

Super Mario 64 is a unique game that uses VCLK: you can swap X2 with a faster crystal to overclock the RDRAM/RCP/CPU/PIF/Cart altogether.  The game’s actual frame rate increases in laggy places (Jolly Roger Bay, lag is minimized!!), and there is no overshoot in timing or frame rate – however a harmless but annoying video corruption does appear (might be correctable by manually configuring the VI?).

[MRKane]

Sorry for deviating off topic there - I felt it was kind of related, but feel free to [re]move my posts if need be.
Outstanding information there eb1560! Thanks for the information! Back to the drawing board for me it'd seem.