Mapping N64 Overclockability : achieved 3.0x multiplier, but not 3.0x speed

Discussion in 'Nintendo Game Development' started by eb1560, May 10, 2014.

  1. eb1560

    eb1560 <B>Site Supporter 2014</B>

    Joined:
    Apr 7, 2014
    Messages:
    61
    Likes Received:
    24
    Started this thread in mid-2014, re-emerged, corrected, and updated in July 2016. A number of games suffer from low framerate on the N64, so I tried a few swaps on the crystals, RDRAM and carried out a CPU multiplier mod to try and see how they impacted overall performance on general gameplay.

    [​IMG] [​IMG]

    How clock is generated and distributed on the N64 board (verified with oscilloscope and crystal swaps), this is an NTSC version, thus X1 is 14.318 MHz:

    [​IMG]

    Overclocking:
    X1 (Video Clock VCLK)
    -X1 sets the video and audio bandwidth for the RCP (VI and AI), DACs, and encoder.
    -VCLK is a 40%/60% duty cycle signal from clock generators.
    -Putting a higher clocked crystal will increase sound pitch, and distort video color – likely from feeding the analog encoder a different frequency than NTSC 3.57 MHz.
    -X1 can be swapped while console is running, system won’t crash, audio still works, but video won’t recover
    -If overclocking X1, might be best to alter the VI settings at the same time to try and take advantage of the faster video and audio signal (horizontal scan, etc).
    -Unless raising the voltage, the clock generators on the N64 won’t reach a VCLK over 94 MHz – at this frequency the video output appears as such below.

    [​IMG]

    X2 [System Clock]
    -Clocks and synchronizes RDRAM, RCP (MClock: MasterClock of CPU), PIF, and CIC.
    -Overclocking X2 increases the speed of the entire console, minus the video and audio circuits.
    -X2 above 15.0 MHz causes a video corruption (video lines seem to shift right), can be corrected by overclocking X1 at the same time, i.e. raising video bandwidth.
    -Maximum limit for X2 is a 20.5 MHz crystal (lots of modification), it seems the PIF might be having issues and locks the console. Above 19.0 MHz, a number of games stop outputting video, but sound and game still continue running.
    -The highest clockable memory chip is the RDRAM36-NUS

    [​IMG]

    CPU Overclock (R43xx CPU)
    -CPU gets its clock from RCP’s MasterClock (MClock), and multiplies it accordingly to what the DivMode settings are set at. Each DivMode setting can work with a certain range of MClock frequencies, 187.5 MHz is impossible to reach at 3.0x, but an MClock of 41.7 MHz will work at 3.0x to generate 125 MHz (this seems to be about the limit on N64 CPU). DivMode of 1.0x can still work up to about 90 MHz.
    -As far as a CPU-only overclock goes, success and stability probably lies in a number of factors: decoupling and bypassing capacitor integrity/quality, CPU voltage, and noise on power rails (fan installed on 3.3V line).
    -I won’t argue which CPU revision can handle a higher clock, but I have had more success in the Non CPU-A chip in running consoles at 2.0x setting.
    -Moving the CPU multiplier up can mess up the cadence of certain games (more CPU cycles made available over a 1 second period), overclocking with a crystal swap will have the same effect - it would be interesting to feed the CPU its own clock source locked at 62.5 MHz, while everything else (RCP) runs at a faster clock than 62.5 MHz.
     
    Last edited: Jul 1, 2016
    radorn likes this.
  2. LukeLexeme

    LukeLexeme <B>Site Supporter 2013</B>

    Joined:
    May 23, 2013
    Messages:
    380
    Likes Received:
    5
    This was an interesting read, thanks for sharing :D
     
  3. amiga1200

    amiga1200 Dauntless Member

    Joined:
    May 9, 2012
    Messages:
    703
    Likes Received:
    4
    ^^ THIS!
    ..
    appreciate the share, fantastic stuff! :friendly_wink:
     
  4. marshallh

    marshallh N64 Coder

    Joined:
    Mar 16, 2006
    Messages:
    663
    Likes Received:
    30
    A while ago I subbed out the 14.7mhz xtal on the N64 (which is the base for the rambus clock, which stock is about 249mhz DDR) and wired it to a PLL output on my fpga board.

    I found that I wasn't able to clock it very much faster at all actually. It was on a CPU-NUS-08 with first party expansion pak. IIRC I was only able to increase to 14.9mhz reliably. Although I could run it a good bit faster, there was graphic corruption from the VI. However all games ran reliably which means that the actual RDRAM was working properly, and the RCP internall crossbars had no problem, but the problem was the video output was not able to cope with such a fast clock.
    The VI read corruption was very similar to yours. I believe it's a design limitation.

    You are right that 90% of games out there are fillrate limited. The #1 design flaw of the N64 in my opinion was the restricted texture cache, and the RDRAM latency / low bandwidth was the next. Many games abuse the zbuffer and do transparent triangles all the time. The CPU is not the limitation here. Increase the rambus bandwidth and almost all games instantly perk up. The iQue has GDDR in place of Rambus and as a result the games it runs are much smoother.
     
  5. Goemon

    Goemon AG Member since 2005!

    Joined:
    Feb 4, 2013
    Messages:
    585
    Likes Received:
    17
    How different is the iQue from the N64? Is it possible to run N64 Roms or would it be possible to swap the GDDR from an iQue into a N64?
     
  6. eb1560

    eb1560 <B>Site Supporter 2014</B>

    Joined:
    Apr 7, 2014
    Messages:
    61
    Likes Received:
    24
    I came across a neat datasheet about the Rambus ASIC Cell (RAC) a while back (if of interest: http://www.datasheetarchive.com/dl/Scans-064/DSA2IH00157976.pdf). On the 4[SUP]th[/SUP] page (41) the datasheet specifies that when RDRAM is clocked at "500 MHz," the ASIC side (RCP side) of the RAC should be 1/8 the clock of the Rambus Channel (~62.5 MHz), since the ASIC side of the RAC handles data in eight byte blocks or octbytes in a very time specific manner (though there appears to be some wiggle room). I am assuming perhaps the RDRAM overclock is throwing off the 1/8 relationship, since keeping the RCP clocked close to this ratio prevents the corruption from being present.

    Meant to put pictures on the original post:

    RCP: 60.8 MHz, RDRAM: 520 MHz; small visible bands on left side of screen

    [​IMG]

    RCP: 60.8 MHz, RDRAM: 626 MHz; can still be played :)

    [​IMG]



    NEC apparently made the iQue chip which basically consolidates all N64 ICs into one, I think I read somewhere that it uses some sort of encryption when running games or software? Interestingly, there is a vendor on www.hkinventory.com with the actual chip in stock, don't know if it is useful at all.

    RDRAM is quite different than other memory types in many ways - advantages and disadvantages, but it seems implementing the RAC may have limited the clock and performance on the RCP? I think the highest clocked Base/Concurrent RDRAM went up to 667 MHz by Samsung and Hyundai, but I have only seen them on datasheets.
     
    Last edited: May 17, 2014
  7. Zoinkity

    Zoinkity Site Supporter 2015

    Joined:
    Feb 18, 2012
    Messages:
    500
    Likes Received:
    108
    When you ran your test ROMs, did you change the clock rate value at 0x4 in the header? If not provided (0) and you're running something standard library ROMs set a default value of 1.5x, so it's worth asking. It stands to reason that if the software's own timing value doesn't match that of the processor there's a better chance of software issues.
     
  8. eb1560

    eb1560 <B>Site Supporter 2014</B>

    Joined:
    Apr 7, 2014
    Messages:
    61
    Likes Received:
    24
    I tried to edit a reply of mine yesterday, but I think I accidentally ended up deleting it.

    I did not modify anything while the game was running, but what software would allow me to do this (does a GameShark allow it at a value that high)?

    I would note though that my charts in the original post are not quite complete. The “wallâ€￾ of X1 being at 16.9 MHz (57.4 MHz VCLK – 71.8 MHz RCP) appears to be the highest operating crystal that the MAV-NUS can tolerate to output an image and audio (at least on my system). I just got a non-crippled GameShark (3.3) this past week; I can say with a good degree of certainty the RCP can definitely handle a clock of at least 102 MHz (X1 being 24 MHz, the highest xtal I have at the moment) at stock multiplier. When using this xtal and despite having no video output, the GameShark dial does countdown during boot up; when blindly activating the code generator, the dial does its in-game spinning motion (using Super Mario 64 cartridge). I am still reading up and getting acquainted with a number of N64 docs out there, I guess it would be neat to change the VI registers to compensate for the higher X1 (including wiring/soldering a lower VLCK to the MAV-NUS, or an HDMI adapter!).

    I came across a neat datasheet on the RAC (Rambus ASIC Cell) a while back: http://www.datasheetarchive.com/dl/Scans-064/DSA2IH00157976.pdf. Although the datasheet goes into much more depth, apparently the RAC’s control logic handles data on its ASIC side (the RCP) in eight-byte blocks (octbytes). According to this Rambus design, the RCP (ASIC) needs to operate at 1/8 the clock of the RAC/RDRAM – in the case of the N64: “500 MHzâ€￾ RDRAM means 62.5 MHz RCP, though there is some wiggle room in actuality. Interestingly, when swapping xtals to clock the RCP clock as close as possible to this 1:8 ratio with an overclocked RDRAM, the video corruption is absent. Since I can clock RDRAM up to 626 MHz, the RCP should be at least 78.2 MHz for no corruption.
     
  9. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    This is fantastic stuff, eb1560!

    Thanks for the mention btw. :D

    I'm loving this overclocking stuff, and I've always wanted to try one of the faster NEC chips.

    I even looked at the possibility of using an R5000 CPU module from an SGI machine, but I think all of them use a 64-bit system bus, which would be a pain.
    Maybe it could be done with a CPLD or FPGA to convert the interface, but probably not worth the effort tbh.

    Anywho, I have some info on the NEC CPU which may be handy....

    When I was doing the schematics for the N64 (under Cadsoft Eagle), I found a few discrepancies between the VR4300 datasheet I was working with, and the R4300i.
    I was trying to check everything as thoroughly as possible, and some of the pinouts just didn't add up...

    [​IMG]

    It looks like they swapped a few pins, as the /INT1 pin was supposed to be connected to cart slot pin 44.
    I assumed this was swapped with JTCK on R4300i pin 58, since it's close by, and JTCK is likely tied to VCC anyway.

    Then /EVALID was definitely swapped with something, because when I checked with the oscilloscope (many years ago), the proper signal was appearing on the pin marked "/RESETB".

    So, /EVALID is swapped with /RESETB, and /RESETB is just tied High to VCC, because resetting of the CPU is done via /COLDRESET instead.
    (again, makes sense, because the two signals are next to each-other).

    Then, I noticed from the old overclock guides that the order of the DivMode pins simply didn't make sense either.
    I couldn't get my N64 to even underclock and still run (was obviously trying to run at 3:0 or something), so I figured those pins were swapped too (R4300i, pins 112 and 116).

    All the other pins seem to make sense, and I could see the proper signals flying along the SysAD and SysCMD bus to / from the RCP.

    EDIT2: Oh, for pin 8 btw, it does look like it's normally tied to VCC on the NEC datasheet, but is definitely connected to GND on the N64 mobo.
    I don't think that pin is swapped with any others at least?


    I may have to buy one of those HP formatter boards soon, to test the faster CPU.
    Great find on that btw - I knew the MIPS chip was very popular in printers and copiers, but I wouldn't have known where to start looking tbh. :p


    btw, I'm currently doing a project which I think you might find very cool. Still waiting for parts atm, but I think it might just work...

    It's probably one of the biggest projects I've ever taken on, but something I've wanted to try for years.
    I don't want to build people's hopes up though, as I have way too many unfinished projects already (GD Emu, console HDMI board, 64DD ripper etc.)

    Think "Nintendo iQue", but with a big FPGA. ;)

    I may be posting some photos in the next day or two, but I'll start a new thread if I do.


    Loving the work in this thread though, it's a great read.
    See what you can do with that above info on the NEC pinout - would be fantastic to see it running at 133MHz in our old friend, the N64.


    Regards,
    OzOnE.

    EDIT: Updated the image, 'cos the Win 7 Snipping tool compressed the JPG too much.
     
    Last edited: Jun 17, 2014
  10. eb1560

    eb1560 <B>Site Supporter 2014</B>

    Joined:
    Apr 7, 2014
    Messages:
    61
    Likes Received:
    24
    Hey OzOnE, I was planning on swapping the CPU NUS A with the VR4310-167 a few weeks back and came across the same difference in pin assignment – I published some info on another forum (http://nfggames.com/forum2/index.php?topic=5223.0). Another user found the printer board with the CPU (100 MHz variant), I found that ebay has the 167 MHz variant for sale (http://www.ebay.com/itm/120921407701?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649.).

    There are quite a number of pins that are different on the N64 CPU. Using the NEC PD30200 and PD30210 datasheets along with the continuity tester on my multi-meter, I have found at the very least the following pins deviate from the datasheet on my 08-1 board:
    #8 GND (VDD in datasheet)
    #15 VDD (Divmode2 depending on NEC CPU)
    #18 N/C (TClock)
    #28 VDD (Int4)
    #52 VDD (JTAG: JTMS)
    #57 Attaches to cartridge pin #44 (JTAG: JTCK); 64DD motherboard (dev) designates as “Int-“ but could be Int1 or CartIni in 08-1?
    #58 VDD (Int1)
    #63 VDD (JTAG: JTDI)
    #65 N/C (JTAG: JTDO)
    #74 N/C (PReq)
    #95 N/C (PMaster)
    #99 VDD (EReq)
    #105 VDD (EValid) – N64 patent paper shows EValid somehow connects to the RCP…?
    #118 VDD (Int3)

    If I had an oscilloscope handy I might be able to verify if any other pins are different. Nintendo certainly eliminated or swapped pins, especially JTAG on the NUS CPU (A), they probably did not want people playing around with boundary scan. What you said in your post makes sense OzOnE, I was wondering where the EValid pin ended up. I am tempted to design a custom N64 board just to see the faster R43xx chip in action and to see how JTAG would work out in such an environment.


    I did not get a chance to update the original thread post, but the highest system overclock can only be achieved using the 1.0 and 1.5 CPU multipliers. The CPU multiplier controls only its internal operating clock, but swapping X1 will change the CPU's internal and external bus clock (including RCP and VCLK).


    There are some unique effects on the system with higher xtals than those in the charts I posted previously: (compared game timers vs a real world stopwatch for increase in speed, not necessarily performance)

    1) Maximum X2 varies from N64 to N64 (RCP-quality lottery), but should be able to do 584 to 625 MHz DDR using only RDRAM36 (I read somewhere RDRAM36 was designed for 567 MHz).

    2) Maximum X1 I have tested is 50 MHz - yes its very high, see below for max system speed

    3) My monitor/screen cannot display image or output sound using X1 from 17.2 to 25.0 MHz, but from 26 MHz to 42 MHz it display the same image “miniaturized” on each quadrant of the screen (multiplayer like) but in black and white with some occasional flickering – sound pitch is considerably increased

    4) X1 of 48 MHz and 50 MHz outputs a black and white image no different than stock X1 with minimum to unnoticeable system speed and sound pitch increase

    5) Maximum system speed (and sound pitch) at 1.5 multiplier is 26 MHz at X1: some games are up to 40% faster at stock RDRAM clock (up to ~79% with RDRAM at 584 MHz, no improvement if clocked higher), the majority of games out there do not appear to exceed a 20% increase in this clock setup. In this setup, the clocks are: RCP ~110 MHz; CPU ~166 MHz; VCLK 88.4 MHz! My Kill A Watt meter says the N64 in this clock configuration consumes just a bit over 11 watts, that is 2 watts higher than its stock setting for most games.



    Since the system is sped up, has anyone tampered with the VI registers in a game (through ROM hacking) to display an image beyond 240p or 480i using a higher X1 on actual hardware?
     
    Last edited: Jun 18, 2014
  11. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    TADA! :D

    https://mega.co.nz/#!a9ABHTpR!aYziyIAjJr40arowTl-DhlReDM62uhe3TwU4R0BoNrI

    Please don't assume this schematic is 100% correct, as it was mainly done with the multimeter and a lot of patience.

    We were discussing the schematics stuff on benheck a few years ago, and a couple of guys were working on it too.

    The above is for Cadsoft Eagle, and is just what I've found so far. I think it's 99% correct now though.

    There are a few things still missing too...

    It's not routed or laid out properly at all - just the crappy auto-router.
    It doesn't have any of the decoupling caps.
    It's missing quite a few of the resistors and other bits on the underside of the board.
    It doesn't have the Reset IC yet.
    The connections from the Reset IC to the MX8330 clock chips need to be checked (I think this was a "slow start" thing, to allow the RCP time to start up the RAC module?).
    Doesn't have the test pads for things like the NTSC / PAL clock freq switch etc.
    None of the ceramic caps have values.
    Some of the part numbers might not match the real N64.
    A PAL N64 was used for the schematic.


    As far as I can tell, I think the R4300 pinouts are correct now.

    The RCP pinouts were mainly worked out from the R4300 pinouts, OKI RDRAM datasheet, and tests with the o'scope etc.
    /EVALID definitely connects between the 4300 and RCP, as this tells the 4300 that the RCP is driving valid data / command onto the bus.

    /PVALID and /EOK go to / from the RCP as well.
    /EREQ is tied high on the 4300, then /PMASTER and /PREQ are tied high. <- EDIT: Correction - /PMASTER and /PREQ are "no connects".

    Also, only interrupts 0 to 2 (and NMI) on the 4300 are used - ints 3 and 4 are tied high.

    Good work on the overclock tests and NEC chips, eb1560. :)

    I'd still like to try running a faster NEC the N64, but not sure when I'll get chance tbh.

    I did want to try modding a cart image to tweak the VI settings as well, but never got around to it (HDMI board still hooked up to the GC, but sat collecting dust, sadly :( ).

    A few years ago, I was even trying to change the viewport matrix stuff in SM64, so we could do true stereo 3D by using two N64 mobos in sync. :p

    OzOnE.
     
    Last edited: Jun 19, 2014
  12. saturnu

    saturnu Spirited Member

    Joined:
    Dec 8, 2011
    Messages:
    143
    Likes Received:
    29
  13. eb1560

    eb1560 <B>Site Supporter 2014</B>

    Joined:
    Apr 7, 2014
    Messages:
    61
    Likes Received:
    24
    Some other neat things I checked out:


    Early design of the N64 may have used a 208 pin RCP (ASIC), 2x 16Mbit (8-bit) RDRAMs, and a single HC49u Xtal (photo is of a prototype N64 board, not around the internet): Past Rambus site is rich in much more information

    http://web.archive.org/web/19970629114055/http://www.rambus.com/docs/nintendo.pdf



    N64 Patent submissions, there may be more than just these:

    Video game system with coprocessor providing high speed efficient 3D graphics and digital audio signal processing
    https://www.google.com/patents/US63...a=X&ei=4PAEVLySOdOvggS-zYL4Cw&ved=0CB0Q6AEwAA

    High performance low cost video game system with coprocessor providing high speed efficient 3D graphics and digital audio signal processing
    https://www.google.com/patents/US62...a=X&ei=G_EEVPb5CpOnggT87ILIBQ&ved=0CB8Q6AEwAA

    Video game system using memory module
    https://www.google.com/patents/US60...&sa=X&ei=hfEEVPapM5WONsbEgPgJ&ved=0CB8Q6AEwAA




    Manufacturers that produced 9-bit Concurrent RDRAM in 18mbit capacity (speeds in parenthesis): +600 MHz chips were probably dropped in favor of Direct RDRAM.

    Hyundai – HY5RC1809-xx (533/600/667 MHz; 667 never produced?)
    LG – GM73V1892AH-xxL and GM73V1892AH-xxC (580/600 MHz)
    NEC – μPD488170LG6-Axx (400/500/533/600 MHz)
    OKI – MSM5718C50-xxGS-K (533/600 MHz)
    RAMBUS (NEC?) – R18MC-xx-xx (a 72mbit ‘holy grail’ chip may have existed as R72MC-xx-xx)
    Samsung – KM49RC2H-Axx (533/600/667 MHz; 667 never produced?)
    Toshiba – TC59R1809HK-xx (500/533/600)

    Desktop video cards that used 9-bit RDRAM:
    - Cirrus Logic (Laguna 3D): CL-GD5464 and CL-GD5465
    - Jeronimo J2/N
    - STB Nitro 1X0-0645-305 and 1X0-0591-305 (LG / Chromatic Mpact)


    -N64 games work fine with 12 to 16 MB of RDRAM. Gameshark does not allow Perfect Dark to start when using more than 8 MB. I’m sure many out there already know why more than 8MB serves little purpose.
     
    Last edited: Sep 3, 2014
  14. Zoinkity

    Zoinkity Site Supporter 2015

    Joined:
    Feb 18, 2012
    Messages:
    500
    Likes Received:
    108
    For unhacked, commercial titles yes. If you want to make a console-side development enviroment using one of the available backup devices, well that's something completely different ;*)
     
  15. retrorgb

    retrorgb Spirited Member

    Joined:
    Jul 20, 2013
    Messages:
    160
    Likes Received:
    39
    Has anyone tried this with the UltraHDMI yet? A friend of mine has been wanting to try, but hasn't been able to get an UltraHDMI kit yet.
     

Share This Page