|
|
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Fri Jan 20, 2017 3:50 pm Post subject: |
|
|
I used my o’scope to probe the RD line off the RCP in my 64drive while using tighter cartridge bus timings – the RD signal indicates when a read transaction is occurring. When the voltage of the RD signal rises (active), data is transferred over the cartridge bus, and data stays transferring as long as the signal stays active as shown in the graph (voltage is the yellow line).
The first image is the RD signal with standard cartridge timings (all cartridge ROMs use this), five arbitrary data packets are transferred over a period of approximately 6 microseconds (6000 ns).
On the second image the cartridge bus timings were tightened to the fastest settings tolerated by the ROM (SOTE), the same arbitrary five packets of data were transferred in just 2.5 microseconds (2500 ns)! The time scale is the same in both images, 1 microsecond per division (background grid). The fastest timings for the cartridge bus will differ in every game, some are either faster or slower than others. I suppose this is one area of enhancing gameplay and loading times (despite being already quick enough), I suppose texture data would stream quicker off the cartridge.
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sun Jan 22, 2017 2:05 pm Post subject: |
|
|
Well that's solid proof of concept! I know there are some situations where games moving data off of the cart and into memory is noticeable, but two things spring to mind here - the first is a potential performance boost for the memory use on the RCP (thinking alpha combines etc.) and the second is: why was it so rigidly set? _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Sun Jan 22, 2017 3:59 pm Post subject: |
|
|
Stock cartridge settings can peak at about 96 bits per microsecond (3 packets of 32 bits), this would be a theoretical bandwidth of 12 MB/s when scaling with math – in practice I doubt it would reach near this. When tightening the latency, release time, and pulse width (settings on 2nd image), approximately 192 bits of data can be transferred per microsecond (6 packets of 32 bits), the bandwidth theoretically doubled to 24 MB/s. The cartridge timings can certainly be further tightened, the 64drive can tolerate it, but game ROMs seem to have problems booting up. Nintendo probably stuck with a safe and reliable set of timings for the various cartridge ROM chips, including that there might not be any issues if two devices were sharing the same cartridge bus simultaneously, say the 64DD.
I ran into some issues with Goldeneye. I dumped and patched my own ROM with AA disabled, altered the cartridge and RDRAM timings. Subjectively, the game certainly runs smoother with these new settings to say the least. I am more of a hardware oriented person that can perform some rudimentary program hacking – I cannot figure out how to patch my ROM with MCM or speed display activated, I spent some time searching on Google and Youtube, as well as hacking through trial and error, no luck. It seems SM64 has had more successful ROM patches for GS codes? Anyone know how to patch speed display onto a ROM?
I have not seen anyone put up a video of crystal overclocking the N64 on the web, so I uploaded one on Goldeneye recently with speed display:
https://www.youtube.com/watch?v=M2o-REsQx7s
If speed display can be patched, I would post a video and record the levels or places that Trevor mentioned some posts back. |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sun Jan 22, 2017 6:49 pm Post subject: |
|
|
I'm lost pertaining to your question about patching the rom - that video has speed displays on it? Someone smarter than me might have to answer that! They're usually around every day
Another question: What were the timings you elected to use for your clocks? I was very surprised that there appeared to be no speed difference on the play speed, which is something I've always experienced with GE or PD (although I am PAL...) _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Tue Jan 24, 2017 5:47 am Post subject: |
|
|
I have nothing to add... eb1560 has already got display speed up and running.
It certianly looks much smoother although Im interested in why the reading seem to suggest no change.
I mean, your running around as though your running at 30fps yet the speed is showing as 15 taking 4 frames to complete.
I wounder if the multiplier is also altered (or fixed?)
eg, maybe its
clocktickstocomplete/62.5=4
instead of
clockticktocomplete/clocktickspersecond =2
to test gamespeed you need to activate a timer (silo on 00agent) and compare that with a real stopwatch.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
Wreck Administrator
Joined: 14 Dec 2005 Posts: 7200 Location: Ontario, Canada |
Posted: Tue Jan 24, 2017 1:11 pm Post subject: |
|
|
Way over my head technically, but the video did seem to be smoother, with less minor slowdown while things are being loaded in or enemies responding to Bond. |
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Tue Jan 24, 2017 2:56 pm Post subject: |
|
|
I uploaded another video on Goldeneye overclocking, a 25% overclock from some time ago.
https://www.youtube.com/watch?v=jKpfA7PUxfw
Youtube does the deinterlacing upon uploading, I think some of the video quality was degraded, especially with the screen artifacts, hopefully squinting isn’t necessary. The higher the overclock, the less choppy the sound (i.e. RC-P90 firing), also the CPU speed on this second video is quite close to the “CPU multiplier 2.0x mod,” in fact it is clocked at 117.3 MHz (1.5x multiplier). If the multiplier were to be set to 1.0x, it would be a very nice and smooth slow-mo.
These videos are with a GS and Goldeneye cartridge only, no software modding was performed other than just disabling VI AA and activating speed display through GS. I’ve always had the impression that the speed display may be miscounting events with a system-wide overclock like this. I’ll try out the silo level, I’m quite sure the in-game timer will be accelerated.
As far as I can tell there can be a slight performance boost when using/combining 2x 2MB RDRAM chips, disabling VI AA, tightening cartridge timings, and perhaps tightening RDRAM timings (not 100% sure on this last one). SOTE showed a give or take 15% framerate improvement, I’d say its better than nothing.
The 64drive does not seem to work with a GS iirc, altering a ROM’s RDRAM timings makes the ROM unbootable unless it is done with a bootloader (64drive and Everdrive). So patching a ROM with speed display would show how all “improvements modifications” listed above would change the behavior of the game. |
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1688
|
Posted: Tue Jan 24, 2017 8:27 pm Post subject: |
|
|
64drive is usable with a GS in USB mode but not in menus mode.
The GS would hook the menus, not the bootloader of the launched game.
I've used it in USB mode for a few silly things in the past. Just remember that your game's bootstrap needs to match the internal CIC when you do it that way. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Wed Jan 25, 2017 1:57 am Post subject: |
|
|
Zoinkity, perhaps you can make the display speed perminent hack instead of GS?
I beleve eb1560 was asking for this above.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Thu Jan 26, 2017 5:28 pm Post subject: |
|
|
I might be able to do this. I'll see if I get the time on a PC to look into it at the end of today
EDIT: Sorry guys - I'm not going to get near a computer for a long time to do this one. _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Sat Feb 04, 2017 2:20 pm Post subject: |
|
|
I thought I’d give an update on the low latency (LL) RDRAM after not tinkering with it for about a week. The long story short is these LL RDRAMs can significantly improve certain types of RCP-RDRAM operations (over Nintendo branded RDRAMs), it does not translate readily into improving a game’s framerate perceivably on the N64. Unless a game already runs at a high framerate and has a fps counter (VI AA disabled), then a minuscule improvement will certainly be visible. When programmed into a ROM’s boot code, for those who are interested or hardware savvy: the LL chips allow for faster minimal timings on RETRYSENSE, RETRYREFRESH, and RASAGAIN operations between the RCP and RDRAM – these are influenced by row timings or RAS INTERVAL timings in memory.
The main attraction for these LL chips, aside from the 300 MHz rating, is the faster row timings. Interestingly, when altering the boot code so all RDRAMs have identical row timings (instead of only the first being faster), the row timings can be set even faster than the LG LL datasheet specifications. The LL chips also have a unique feature, AckDis, which allows for tightening RDRAM request packet (REQ) processing by about 8 ns when activated. Neither AckDis or faster row timings seem to bring any benefit to gameplay.
In order to take advantage of the faster row timings, the boot settings for the RDRAM Interface (RI) in the RCP needs to altered: particularly the clean refresh delay and dirty refresh delay registers, which are set to 0x36 (~864 ns) and 0x34 (~832 ns). When all LL RDRAMs are timed identically, all row timing parameters can be set to 0, and the overhead delay allows for both the clean and dirty refresh delay to be set to 0x1E (~480 ns). This essentially shaved off about 40% of the Retry Refresh delay. |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Mon Feb 06, 2017 3:49 pm Post subject: |
|
|
Well you're far and beyond my level of expertise there, but I'm more than thankful for the research, and what looks to be a final answer here _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sat Feb 18, 2017 3:15 pm Post subject: |
|
|
Just ended a crazy drive at work so I've finally got time to do leisurely stuff like sleeping, or tinkering. I was thinking about all of this work in relation to what I've read about the iQue - what was the real difference there as many speculated it was the RAM, but you've pretty much excluded that possibility now. _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Sun Feb 19, 2017 2:56 pm Post subject: |
|
|
Nintendolife had an article recently about Martin Hollis, the director GE 007 evaluating some early hardware at SGI. The story goes that Hollis ran a geometry/drawing program that uncovered some of the performance issues of the RCP, and the project director over at SGI almost did a 3rd RCP revision to correct the memory interface – I am assuming this is the RDRAM interface or DMA controller? They probably corrected the N64 hardware deficiencies in the IQue, the GDDR memory is leagues ahead of RDRAM in terms of performance. Lag is absent for the most part on the IQue, but it does show up in certain graphically intense instances in StarFox. If only there was a way to run an N64 game on the IQue…
The LL mod in many ways reduces the amount of “down time,” during which the RDRAM is “busy” and cannot be accessed by the RCP. My o’scope’s counter shows the LL mod increases memory traffic by about 4% compared to stock Nintendo settings in GE and PD, so more data is actually passing between the RCP and RDRAMs – the overall memory bandwidth increased. |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Wed Feb 22, 2017 1:55 pm Post subject: |
|
|
Fantastic information there! It amazes me that people are still discovering things about this system. I guess that makes this matter properly explored now as I've really no more thoughts or ideas to follow up here.
Onward until the next crazy idea - which will probably be isolating the clock timings within the GE & PD rom so that it'll work correctly with an overclock. _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|