GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[eb1560]

First time posting but long time N64 console tinkerer.

I did quite a bit of overclocking on the N64 a few years back on Assemblergames with crystal swaps. I recognize MRKane, discussing RDRAM a few years back in nffgames.

There is not a whole lot more that can be done in performance boosting with RDRAM in the console. Two RDRAM36-NUS chips are essentially the optimal config. Rambus claims it’s 250 MHz chips (500 MB/s DDR) will peak at under 380 MB/s, depending on the memory operations performed over a period of a second. Latency is a bit weird in RDRAM vs other DRAMs. The CAS and RAS values can be changed in a ROM’s bootstrap (loading through 64drive), tighter or looser timings have no impact on framerate or gameplay (I tried this a few times). Rambus states performance is improved only upon raising the RDRAM’s clock frequency, an issue with a variable latency setup; impractical on an N64 since video gets corrupted when raising RDRAM/RCP clock in relation to the RCP's VI.

Regarding an earlier post, there was an 18Mb chip produced by LG (GM73V1892AH16L) advertised as “low latency,� this was often implemented on desktop graphics cards (Laguna3D and Mpact!), since it supposedly freed up RDRAM core cycles by ignoring acknowledgement packets on the bus – it would need to be manually activated in the RDRAM Mode register, but I have no idea if it can further improve console performance, the datasheet might be more informative. This would call for a 3rd party exansionpak that allows for two RDRAM chips to be mounted.

Although on another note, cartridge bus timings can be altered, these are found at the start of a ROM – kind of interesting. N64 dev manuals state the PI’s bandwidth with a cartridge is roughly 5MB/s, and can peak to almost 50MB/s. ROMs (all of them?) set the PI timings for release time, pulse width, and latency in # of cycles: 3-18-64 respectively (each clock cycle in RCP is 16 ns, math is straightforward). Some games, SOTE being one, can operate with timings as low as 1-8-1, framerate did not improve, but loading times seemed faster (it should, since timings were more than halved, bandwidth more than doubled). However, not every game can run with these low timings, Goldeneye as an example, will boot, but the audio will glitch out upon loading a level; other games (Perfect Dark) refuse to boot. So, every game will have its own optimal value through trial and error.

[MRKane]

Welcome to the forum and thank you for the information!

I had pretty much concluded the same as you regarding the potential to improve performance with RAM, and was messing about a little with the clocks this weekend but tend to conclude that there's no way to boost performance while maintaining gameplay standards across the system. As fate would have it I was using your charts as reference myself, but wanted to check with different games (Turok 2, PD, GE, Beetle Racing...I don't own many more sorry).

At a glance that RD Ram chip you suggested looks like it has the correct pinout although I don't know how the console would handle it. It might depend on the block arrangement etc. I'd love to find a good 4MB chip with a low latency just to finally sate my curiosity.

A few of us here did experiment with trying to change the ROM internal clock timings so that the console could be overclocked (standard CPU) and the ROM clocked up at the correct rate to balance this out. The closest I got was in Perfect Dark with a custom slow motion setting that was almost correct and a bit of a thrill to play actually due to it being so smooth. This is an area I'd be interested in trying to pursue a little because I feel there's possibly an un-turned rock here (or so to speak).
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

Its a pity that PD didnt have a performance meter, its proving very usefull in Goldfinger to play with things and check its performance to squeeze as much detail as possible in while keeping the little red bars down. (and tmem as loading it is worse than I imagined and Im the worst at using full 2k textures hahaha)

The slow-mo is the perfect remidy to CPU overclock in PD to restore correct Real-Time-Clock while gaining CPU clocks to do things like AI.

Its just a pity that increase in CPU means decrease in RAM.
That said... if we found that Nintendo didnt use optimal timings we would be complaining a lot. Its good to know that the N64 was optimal, it would just be good to upgrade something.

The flip-side of optimal which we can exploit which I might as well state as it refers back to the PD overclock is that optimal might not be the best, it depends entirly on what exactly is slowing a game down. If a game has lots of textures then the ram is slowing it down with transfers (like a side-scroller for example)
however if a game has few models but high pollies then it is the RCP processing that is slow.
If a game has lots of logic then the CPU needs overclocking.

Im rambling, sufice to say Im glad your still tinkering

Trev
_________________

[eb1560]

Quote:

As fate would have it I was using your charts as reference myself, but wanted to check with different games

I took those charts down a while back, they wrongfully hinted at the video clock (X1) having some influence on the RDRAM clock (X2). Here is an abridged update to those charts. The X1 crystal is important for setting the AI and VI bandwidth as well as some timer function in the RCP, overclocking this can correct the video corruption, but it throws off software timings and the video encoder chip’s frequency to the TV (I use a NTSC -02 board). X2 sets the clock that drives the RDRAM, and after further divisions the RCP (& CPU base clock), PIF, and CIC – overclocking X2 improves the overall performance of the console, throws CPU timings off, and then there is the video corruption that worsens with clock increase. It might be safe to say that all N64 consoles can easily handle a 10% overclock on X2 (10% faster RDRAM, RCP, *CPU*, PI, and CIC), and 25% is achievable by using only RDRAM36-NUS chips, from 25% to ~40% things become incredibly complicated.

I’m quite interested in what clockrate rate value you used for the slow-mo setting in PD. I never thought a CPU multiplier overclock could be of any practical benefit on the N64 even if the timings can be compensated, I’m curious if any games may actually benefit from this. My understanding of the NEC R4300 docs is that the multipliers only influence the CPU’s PClock or internal clock, the system interface clock or SClock stays matched with the MasterClock, which is 62.5 MHz from the RCP – there may be more bus traffic with a faster PClock, but there is no change in peak bandwidth between the CPU-RCP bus when changing multipliers.

I didn’t have any luck in framerate improvement when changing RDRAM core timings for Goldeneye or SOTE, but maybe someone will find a game that may benefit with different settings. I am running the games with altered timings on a 64drive, it should work on an Everdrive as well. ROM’s bootstrap sets the CAS latency optimally to 0x1808-2838, they have a unique encoding scheme according to Rambus: (RDRAM clock is 250 MHz, which is a 4 ns cycle period)
AckDelay: 0x18 = 3 cycles (12 ns) *included in AckWinDelay below
WriteDelay: 0x08 = 1 cycles (4 ns)
AckWinDelay: 0x28 = 5 cycles (20 ns) *Low latency chips ignore this for tighter timings
ReadDelay: 0x38 = 7 cycles (28 ns) *this is the CAS parameter

There are two configurations for RASInterval in bootstrap, it seems 0x101C-0A04 is mainly used, bit reversed encoding (I think they are correct):
RowImpRestore: 0x10 = 1 cycles (4 ns) *a value of 0 appears stable
RowExpRestore: 0x1C = 7 cycles (28 ns) *unstable with lower value, must equal 7 cycles (CAS)
RowPrecharge (tRP): 0x0A = 5 cycles (20 ns) *a value of 0 appears stable
RowSense (tRCD): 0x04 = 2 cycles (8 ns) *a value of 0 appears stable

EDIT/UPDATE:
I tested RASInterval settings with two RDRAM36-NUS chips on motherboard, unsure how earlier RDRAM chips may behave. Game unlikely to boot if RowExpRestore is set lower than 7 cycles (VRAM artifacts do appear if it does), Rambus says this must equal CAS, this parameter involves writing data back to its memory cell if it was fetched and altered. Everything else appears to be stable when set to 0, this would indicate quite a substantial reduction in latency, but no perceivable improvement in gameplay.

[MRKane]

I'm not smart enough to follow half of that! But I do follow a bit of what you say about the different clocks and how they affect the system, although any unusual results I got I generally attributed to my poor electrical work. I'll see if I can find the paper I scrawled notes on, although given that was months ago it's probably gone by now.

Pertaining to the PD "realtime at overclock" it was a standard CPU overclock and a tweaked ROM. It's a shame that games don't all get their timings from the same place. Those from Acclaim seem to have a good boost in performance from the CPU overclock, but others are rather hit and miss.

I was actually wondering about forcing different video modes the other day, given the AA settings in the ROM memory, I was looking for something that might be setting video resolution (and working on the idea that it could be tweaked) but was unable to find anything.
_________________
No Mr. Bond, I expect you to be re-coded!

[eb1560]

I can sometimes go a bit overboard on the explanation. Everything in the previous post amounts to an attempt to reduce RDRAM core latency, it provides insight into what type of timings are involved inside RDRAM – I grabbed this information from datasheets, Rambus design guides, and verified them with a Gameshark.

Since memory is a series of matrices of columns and rows, these columns and rows have their own delays, so I lowered the delay for the rows (columns delay can’t be further improved). I did this by changing the code close to the beginning of the ROM at 0x220 (0x101C) and at 0x224 (0x0A04), these are the row delay values I described above – though the actual location of the code might not be the same for every ROM. Even after lowering the row delay in the RDRAM, there was no change in framerate for PD, GE, or SOTE.

Interestingly, when a feature like video AA (VI) is disabled, there is a modest bump in framerate performance, give or take 5%, but it will vary across games (z-buffer). I even probed RDRAM data lines (on jumperpak) with an o’scope in the past, and saw that when disabling AA, there is a decrease in memory traffic by approximately 5%.

[MRKane]

Nice work!

I'll put the soldering iron down for a bit (have two broken CPU-08 consoles that are about to donate some 4MB ram to another unit) and ask if there's anywhere you can think of that we've not explored for improving the unit performance? I've about given up in that department as things are too finely balanced to get a good across the board gain.
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

Remember there are 2 types of AA,
Sclioete AA and full AA

In full mode the Blender reads from the framebuffer to find the colour of the current pixel.
In RA mode if the Pixel has data (I.e. not fillcolor() ) then its ignored.

Z-Buffer kills RAM and essentially makes AA free.

You guys should enable the MCM and Display Speed when doing these tests, it gives more info than just feeling and/or basic fps readout.

The bars have been explained elsewhere on this forum, but basically it will show you how long it takes to load textures and show fractions of a frame rather than whole fps.

It would be interesting to see if textures are loaded any quicker with your ram mods.

A guard appearing on-screen will suck 36% off utz into loading TMEM
(Basically 36% of a frame/second is spent RSP idle waiting on RAM)

Trev
_________________

[MRKane]

Shame I didn't know about that when I was doing those RAM mods. I do still have two sticks and was thinking of making a 4MB internal board - I could try a swap out and then strip them off to see if the latency does make a difference with proper tools
_________________
No Mr. Bond, I expect you to be re-coded!

[MRKane]

Suppose I had just stumbled across a spare board, and had some of that very-low latency ram left over: what was the method for finding out what the frame details were within Goldeneye and Perfect Dark? The soldering iron has been cold a little too long and I'm licking my wounds after having the multi-region console die for no apparent reason so would like a cheap win
_________________
No Mr. Bond, I expect you to be re-coded!

[eb1560]

Was the board by any chance a Cirrus Logic Laguna 3D or an Mpact! derived video card?

The ‘low latency’ mode needs to be manually activated in a ROM’s bootstrap, otherwise these low latency chips will operate like any other standard RDRAM. The low latency feature can be activated in the RDRAM’s mode register at 0x03F0-000C. In datasheets and Rambus design guides, this feature is referred to as 'acknowledge disable', ‘AD’ (AckDis). I suppose the code would need to be added after the CAS settings are set, maybe somewhere around 0x150 in a ROM? I am interested to see how this works out.

[Trevor]

If you mean the MCM, the codes are on the vault somewhere.

To activate the mcm press Cup and Cdn at the same time.

the menu will flicker fast but display speed it at the top on the 3rd column (use Dpad to navigate)

ah, not the vault, but betagoldeneye
http://web.archive.org/web/20160128064827/http://betagoldeneye.com/mcm.htm

Trev
_________________

[MRKane]

Thank you Trevor that's what I was after! I'll consider if it's worthwhile when the console frames show up in a few weeks

eb1560: I actually poured over data-sheets until I found some RDRAM that I could purchase, and had a lower detailed latency (I think I've mentioned it earlier on this thread). I'd love to find some 4MB compatible chips with a lower latency which would really get around the expansion pack problems too!

Pertaining to the Roms bootstrap: I didn't know about it then...which is suddenly why my interest is caught again!
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

What we need is a benchmark.

I guess standing at the front of frigate is pretty hard on the system.
bar1 = 5
bar2 = 5.25
bar3 = 5.4
10fps
utz = 31%
rsp = 53%
tex = 16%


looking out to sea from boat
bar1 = 2.5
bar2 = 0.5
bar3 = 0.5
30fps
utz = 76%
rsp = 5%
tex = 18%
Fast but a lot of stuff in BG being processed
Lots of textures waiting on DMA

Eqypt Spawn Point (No move)
bar1 = 1.9
bar2 = 4.4
bar3 = 4.5
12fps
utz = 77%
rsp = 18%
tex = 5%
Complex scene to render but straight forward matrix calculations

Main Menu
bar1 = 0.25
bar2 = 1.25
bar3 = 1.4
30fps
utz = 96%
rsp = 0%
tex = 4%


Watch
bar1 = 1.1
bar2 = 1.2
bar3 = 1.3
30fps
utz = 88%
rsp = 4%
tex = 8%



For info on these numbers I updatd my post on Display Speed
http://www.shootersforever.com/forums_message_boards/viewtopic.php?p=63111#63111


Trev
_________________

[MRKane]

Thanks for the information! When I next get the chance I'll compare them with the PAL numbers before beginning on this. Hopefully the system will be a little more stable this time around as the one I've got coming isn't broken!
_________________
No Mr. Bond, I expect you to be re-coded!