ShootersForever.com Forum Index

GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion
GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community


Overclocking: a review
Goto page Previous  1, 2
 
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Console Workshop
View previous topic :: View next topic  
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sat Mar 14, 2015 12:23 am    Post subject: Reply with quote Back to top

Right, this wouldn't be happening if a mate hadn't of come forward with a cheap N64 that he didn't want, this one really really really is the last one and I want a little hand from the sharp brains out there.

From what I've read:
The Pal N64 has two clocks, both are set to ~17mHZ which then hits the . The RCP clock generally seems to govern the overall system speed as a follow through from the Ram clock messing with the CPU.

What I know: PD seems to get it's timings from somewhere other than the CPU, possibly RCP or ram...possibly that other clock.

Theory: Overclock the CPU using the 1.5X or 2X modifier, and then install a different crystal to try and bring down the framerate to a "stable" speed (it'll either be half, or double, in one or both positions). I might look at getting two sort of doubled or halved crystals, which should be fine according to the forum as long as it doesn't exceed 40 or go below 10, and try installing them in different slots and seeing if there is any notable difference to the general "gamespeed" not becoming faster while overclocked.

Hypothesis: Push hard, then balance it out. I figure that the increased timing on the RCP will control the clock that's reading for the timing inside PD and GE as the multiplier (overclock) is having the effect of just spitting extra frames through, if I can balance those two elements the game should have some level of normal timing with *possibly* a higher push on expected frames from the CPU.

Here's the rub: Anyone got any ideas on this as all bar a tiny bit of reasoning (possibly just me hoping with every fibre that I can play PD at 60fps on console) on the feasibility of this one? I reckon it's going to be a total failure frankly. It's a crazy-far out one that I thought of while we were trying to get latency out of the new Nvidia graphics cards due to them buffering frames to keep things smooth.
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
Trevor
007
007


Joined: 15 Jan 2010
Posts: 926
Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest

 PostPosted: Sat Mar 14, 2015 7:30 am    Post subject: Reply with quote Back to top

Well... my suggestion would be to not overclock the CPU, but instead overclock the RCP and reduce the CPU back to syncronicity.

As this post shows, getting 3x on the cpu actually reduces all the rest of the system.

I say, tlets make the system faster and keep the CPU at 93.75MHz

So, thaking his info on the xtals, what we would like to do is increase the RCP to 93.75MHz and multiply the CPU by 1 (93.75).

However... to make the RCP get that speed we would require an X2 of 22MHz pushing 375Mhz (750MB/s) RAM, which as pictured below will crash the System unless we had ram capable of that speed.

* Note that he has listed speeds wrong, Eg, 14.7 (500MHz) should read 14.7 (250MHz/500MB/s)
[spoiler][/spoiler]


Since the image lists that 600MB/s (300MHz) RAM is available and stable in certian consols, this effectivaly allows a 75.25MHz RCP.
Unfortunatly this reduces the CPU by far too much.
The CPU will need to remain at 1.5 giving 112.875MHz.

Overall this is a 20% improvement.
It would still be better to have a 50% RCP improvement allowing graphics tasks to complete faster.


So... the end result is that the only next stable system requires much faster ram to even attempt.

Any further ideas?

Trev

Darn, I wish the image wasnt so big... sorry guys. I dont think the forums img code can specify width

Althedark, spoilers dont work
_________________


Last edited by Trevor on Sun Mar 15, 2015 3:52 am; edited 2 times in total
 
View user's profile Send private message
AL64inthedark
00 Agent
00 Agent


Joined: 18 Sep 2014
Posts: 548
Location: France

 PostPosted: Sat Mar 14, 2015 9:39 am    Post subject: Reply with quote Back to top

Regarding image size, a spoiler mode would be appreciable to compensate.
 
View user's profile Send private message MSN Messenger
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sat Mar 14, 2015 3:53 pm    Post subject: Reply with quote Back to top

Man I totally forgot about the ram limitations and the nature of RDRam! Really good point there, m so use to beating the living snot out of modern equipment that I forgot things weren't always so flexible.

Ok guys. Any ideas or any idea where th slow motion multiplier in PD is stored?
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sat Mar 28, 2015 3:11 am    Post subject: Reply with quote Back to top

So for the first time in ages I decided to have a bit more of a mess around with overclocking rates and stumbled across something funny with the 1.5x overclock on Mario Kart...

It gets weird. Some tracks play faster, some play smoother. Red shells were tracking along the entire track without colliding with the sides, the blue shell kept on hitting player 2 regardless of their position. Flat out I've got nothing as far as suggestions go for why on earth this was (and kept) happening. I'm lead to think that the "overclock" is not as straightfoward as the forums would suggest.

Even weirder is that the 2x overclock ran delightfully. Smoother framerates and more "responsive" control actions.

I've tried messing around with the code in Mario Kart (as I've always wanted the bomb players to get more than one "kill" as we'd all love that!) and frankly the code base looks like a total mess, I could only put it down to that.
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
Trevor
007
007


Joined: 15 Jan 2010
Posts: 926
Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest

 PostPosted: Sat Mar 28, 2015 5:08 am    Post subject: Reply with quote Back to top

Oh... wierd... but once again Im questioning the overclock terminology since what you literally described (at 1.5) is that at 'Normal CPU speed' some stages ran fast while some ran smoother etc etc...?

That is unless you meant the Cart Header?


Now of course, in an un-modded 64 a 3/4p multi skyscraper runs way to fast, yet in 1/2 player mode it runs normal. Also normally red shells travel in a straight line and hit walls.
So youve definatly hit something but im not sure what if the CPU is normal?

Trev
_________________
 
View user's profile Send private message
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sat Mar 28, 2015 6:24 pm    Post subject: Reply with quote Back to top

I have noticed those speed issues too - browsers castle on 4 player is the main one we try to avoid.

On "normal" speed it runs as expected. The more I look into messing around with, or modding this game, the more I'm thinking that it's a bad idea and should stick to GE!
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Wed Apr 22, 2015 9:09 pm    Post subject: Reply with quote Back to top

Well I said I'd post on PD slow-mo levels and overclocking.

Sub was gracious enough to provide me with a sample of patches for various slow-motion speeds and I gave it a crack on the better cooled of the overclocked systems.

So apparently standard speed setting for Perfect Dark is a value of "8", and the closest to normal play on "2.0x" overclock (how about for simplicities sake, and also the sake of being correct in statements we call this "overclock" in future as 1.5x is "standard" in reality and 1.0x is a "underclock"). I found that a value of "7" was the closest to normal play, but was still about 25% slower than "real time" if you will.

*ahem* ok. There was one key thing to note: gameplay speed was variable depending on the amount of duress the system was under. So in complex areas the whole playspeed would slow down instead of becoming fragmented and trying to maintain a constant framerate. It resulted in a funny Johnny Woo kind of effect when there was a lot happening on screen. Some of the speeds for things like projectiles didn't feel correct either - as though the balance had been thrown off.

The system pulled a very nice and extremely attractive framerate in the levels that I tested but some of the running around did get a bit boring when forced to do it at 75% of standard game speed. I think any further development here might involve tracking down some of these factors and seeing if there's a way to mess with the tickers.

So that ends one phase of the testing with overclocking. Now pertaining to Mario Kart running too fast there is this:
http://tasvideos.org/GameResources/N64/MarioKart64/Patches.html

Which could be useful for those of us who play it frequently Smile
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
Trevor
007
007


Joined: 15 Jan 2010
Posts: 926
Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest

 PostPosted: Thu Apr 23, 2015 11:43 am    Post subject: Reply with quote Back to top

Hehe at least GE/PD does seem to have a dynamic Frameskip.

hmm, so with a 25% increase it only moves 1 place for slo-mo and yet still feels slow?
those places must have a 50% shift or something.

Trev
_________________
 
View user's profile Send private message
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Thu Apr 23, 2015 2:55 pm    Post subject: Reply with quote Back to top

If not GE then defiantly PD. I suspected they were factors, but was surprised to find that game time was "elastic". I might see if I can find the ASM that handles this as it'd be typical that the factor is multiplied by 8 and divided by 5 to turn it into miles per hour and then used in the time system - there could also be a bit of slack in the timing department too (which would be the dream solution).
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Console Workshop All times are GMT - 8 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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

Cobalt 2.0 BB theme/template by Jakob Persson.
Copyright © 2002-2004 Jakob Persson


Powered by BB © 01, 02 BB Group

 


Please Visit My Other Sites: GoldenEyeForever.com | GrandTheftAutoForever.com

Got kids? Check out my Dora The Explorer site with games and coloring pages!

Our forums feature Nintendo 64 games, GoldenEye 007 N64 New Maps and Missions, GoldenEye Cheats, N64 Emulator, Gameshark, GoldenEye Multiplayer and more!

[ Privacy Policy ]