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


Rom ClockRate
Goto page Previous  1, 2, 3, 4  Next
 
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: Mon Jan 08, 2018 3:14 am    Post subject: Reply with quote Back to top

Holy cow! They finished it off!

As fate would have it I was sniffing around with this before I lost access to a PC at work thanks to being transferred onto another project. I'd be dead keen to follow these up and see if there's a "normalise overclock" code that could be used Very Happy

EDIT: Because I'm lazy and busy as all hell at the moment does anyone have codes to normalise a PAL overclock? Fingers crossed that PD is next!
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Mon Jan 08, 2018 4:25 am    Post subject: Reply with quote Back to top

Ah that's great it works, it makes sense. Can you detail precisely what you overclocked to and what exactly changed counter to? The pal locations are in my post too but you have to port to rom which has a offset. I can look tonight.
 
View user's profile Send private message
Trevor
007
007


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

 PostPosted: Mon Jan 08, 2018 7:04 am    Post subject: Reply with quote Back to top

I totally forgot to reply to MRKane in march, heh, but we can confirm now that GE uses CPU Time (possibly osGetTime) for all speed and time values and so makes it independent of VI, however, this is also the very reason overclocking the CPU speeds up timers.

"MIPS R4300 count register, which is incremented at half the speed of the CPU clock. Since this counter increments at 46.875 MHz, 1 cycle represents around 21.33 nanoseconds."


The value sub found is most likely a multiplier for gettime since gettime alone provides an extremely big number.

We know GE worked at 30hz internally so there might be something like

tickcount = (osGetTime / 1562744.18 ) //(1 second / 30) / 21.33 nanoseconds = 1 562 744.18 counts per tick.
tickdifference = tickcount - lasttickcount //usefull for skipframes
lasttickcount = tickcount

Trev


ps

I didn't realise sub posted the sum, but I still find it odd... it seems contrary to what DrDoak said about ticks in the GE engine

(it's divided by this value, a tick is (cpu change + 5EB61) / BD6C3

when I lets say, pretend it takes a second to check this value (very complex scene with smoke)
we know that in 1 second the count value will increase by 46882325.4
so entering this into the equation seems to imply a 60hz ticker
(46882325+387937)/775875 = 60.925


All that said, maybe Doak forgot after all this time or we are still missing something?
_________________


Last edited by Trevor on Mon Jan 08, 2018 9:01 am; edited 1 time in total
 
View user's profile Send private message
eb1560
Agent
Agent


Joined: 10 Sep 2016
Posts: 23
Location: North America

 PostPosted: Mon Jan 08, 2018 8:25 am    Post subject: Reply with quote Back to top

When I get a chance, I can do a video capture of GE from my N64 with the GS speed display on top since my setup is a bit unusual. Your post came at the perfect time though, since I successfully installed a VR4310-167 CPU onto an N64 motherboard this last Friday (long and tricky process), it turns out the 3.0x multiplier can actually work on this particular CPU.

Since the 3.0x setting doubles the internal CPU clock from 93.75 MHz to 187.5 MHz (and halves the clock cycle time from 10.66ns to 5.33ns), it is really a matter of either doubling or halving one of those values. So I doubled BD6C3 to 17AD86, and that alone normalized the game speed/cadence for a 3.0x multiplier.


The two images are quite big, so I put them as links:

Memory expansion port angle: https://i.imgur.com/5dKqI3S.jpg

Power input angle: https://i.imgur.com/j9XKPn4.jpg
 
View user's profile Send private message
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Mon Jan 08, 2018 12:33 pm    Post subject: Reply with quote Back to top

I'd be interested to see some footage. I'm sure it helps a little, but I'd think the rsp graphics are the main slowdown. I'll try and see if Perfect Dark has this too.
 
View user's profile Send private message
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Mon Jan 08, 2018 2:01 pm    Post subject: Reply with quote Back to top

GoldenEye
NTSC

ROM 00007074/00007078
80006474: 3C010005 LUI $at, 0x0005 #
80006478: 3421EB61 ORI $at, $at, 0xEB61 #(*CONSTANT) 0005EB61

ROM 000F5698/000F56A8
7F0C0B68: 3C120005 LUI $s2, 0x0005 #
7F0C0B78: 3652EB61 ORI $s2, $s2, 0xEB61 #(*CONSTANT) 0005EB61

ROM 000F569C/000F56A4
7F0C0B6C: 3C13000B LUI $s3, 0x000B #
7F0C0B74: 3673D6C3 ORI $s3, $s3, 0xD6C3 #(*CONSTANT) 000BD6C3

PAL
ROM 00006494/00006498
80005894: 3C01000E LUI $at, 0x000E #
80005898: 342134EA ORI $at, $at, 0x34EA #(*CONSTANT) 000E34EA

ROM 000F2A10/000F2A20
7F0C15C0: 3C120007 LUI $s2, 0x0007 #
7F0C15D0: 36521A75 ORI $s2, $s2, 0x1A75 #(*CONSTANT) 00071A75

000F2A14/000F2A1C
7F0C15C4: 3C13000E LUI $s3, 0x000E #
7F0C15CC: 367334EA ORI $s3, $s3, 0x34EA #(*CONSTANT) 000E34EA
 
View user's profile Send private message
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Mon Jan 08, 2018 2:10 pm    Post subject: Reply with quote Back to top

I think this is PD 1.1 US's counters:

The 7F16CXXX seem to be the real counters...I slowed game to a crawl by modifying.

(part of compressed PD 3050 file)
8000E238: 3C01000B LUI $at, 0x000B #
8000E23C: 3421EBC2 ORI $at, $at, 0xEBC2 #(*CONSTANT) 000BEBC2

8000E248: 3C01FFFA LUI $at, 0xFFFA #
8000E24C: 34210A1F ORI $at, $at, 0x0A1F #(*CONSTANT) FFFA0A1F

(Compressed ASM file 12DC3E)
7F16CEB0: 3C11000B LUI $s1, 0x000B #
7F16CED0: 3631EBC2 ORI $s1, $s1, 0xEBC2 #(*CONSTANT) 000BEBC2

; Believe it is this one
7F16CEB4: 3C120002 LUI $s2, 0x0002 #
7F16CECC: 3652FAF0 ORI $s2, $s2, 0xFAF0 #(*CONSTANT) 0002FAF0

7F16CEB8: 3C130005 LUI $s3, 0x0005 #
7F16CEC8: 3673F5E1 ORI $s3, $s3, 0xF5E1 #(*CONSTANT) 0005F5E1

7F16CEBC: 3C140001 LUI $s4, 0x0001 #
7F16CEC4: 36947D78 ORI $s4, $s4, 0x7D78 #(*CONSTANT) 00017D78


Also, this is combat boost factor:
7F16BFA4 Combat Boost multiplier value 0004 (normally 08 )

If you double speed, you probably want to set this to 0010 for example, but not tested.
 
View user's profile Send private message
eb1560
Agent
Agent


Joined: 10 Sep 2016
Posts: 23
Location: North America

 PostPosted: Mon Jan 08, 2018 10:16 pm    Post subject: Reply with quote Back to top

SubDrag wrote:
I'd be interested to see some footage. I'm sure it helps a little, but I'd think the rsp graphics are the main slowdown. I'll try and see if Perfect Dark has this too.


I am having a bit of an issue running a USB loaded GE onto my 64Drive on top of the GS, the game runs fine, but the audio seems to be disabled every time a level is loaded (except the main menu). I'll look into recording something tomorrow night. As far as the normalized overclock goes in improving a game's framerate, I am not convinced it is improving anything at all aside from just normalizing the faster processor speed for GE.

In the meantime, I put up a video a few hours ago showing how a cartridge GE runs on the 3.0x multiplier - probably not very useful, but kind of amusing to watch Bond "sprint" around.


GE gameplay on 3.0x: https://www.youtube.com/watch?v=z0RGtbf1N14
 
View user's profile Send private message
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Tue Jan 09, 2018 1:40 am    Post subject: Reply with quote Back to top

I was able to trace it as far as a Clock value inside Project 64 - it was actually Bonds watch which turned out to be the key for tracking that down, and while it worked in emulator there was no effect on console. Well that's all explained now Very Happy

Also eb1560: I remember talk about that processor from the assembler forums! Great stuff - it's a really impressive feat! And I'd love to see a write up on it if you've ever done one Very Happy

Frankly I'm thrilled to see this sort of stuff unfolding. As for the clocking on my N64: It's a standard overclocked PAL N64. I actually have no idea what the proper clockrate would be on that (I think it's something like 133% of normal?) - you'd better correct me on that.

But do know that this has really kicked the doors open for speedrunning.
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
eb1560
Agent
Agent


Joined: 10 Sep 2016
Posts: 23
Location: North America

 PostPosted: Sat Jan 13, 2018 5:33 pm    Post subject: Reply with quote Back to top

I got a bit carried away testing several games during the week, it turns out quite a lot of games (mostly non FPS) have no issues with the 3.0x CPU multiplier. I’ve been comparing gameplay with two N64s, one is a stock console, the other has the 3.0x CPU mod.

Unfortunately GE does not see any improvements on framerate with a 3.0x CPU overclock, even after “normalization.” The ROM I used is a dump of my own cartridge (through GS), despite the audio issues I mentioned before with the 64Drive (USB loading), there is really no point on making a video of the normalized gameplay (it plays exactly like a 1.5x CPU) – plus I disabled the audio in order to draw a comparison, which also made the RSP% decrease significantly (and VI AA disabled as well). I imaged my TV, some images have a bit of sun glare:

GE cartridge + stock 1.5x CPU: speed display while standing still in Facility and Frigate.



GE cartridge + 3.0x CPU: Framerate counter is halved, bar lengths are twice those of 1.5x.



Normalized GE ROM (64Drive-USB) + 3.0x: Framerate counter is the same as 1.5x, yet bars are twice those of 1.5x.



I would venture a guess that the bar length corresponds to the execution time (in cycles) of an in-game process – so doubling the CPU’s internal clock frequency (halving cycle time) brought little to no change in execution?

Quote:
Also eb1560: I remember talk about that processor from the assembler forums! Great stuff - it's a really impressive feat! And I'd love to see a write up on it if you've ever done one Very Happy


This CPU mod is quite complicated: essentially two pairs of pins need to be cross-soldered, one pin on VR4310 is 3.3V but on the N64 it is GND, and then three divmode pins need to be set. I decided to go for a permanent 3.0x mode, though the 2.0x and 2.5x modes are also doable, I didn’t bother to test higher multipliers (4x, 5x, 6x) because I highly doubt the silicon would work. This 3.0x CPU multiplier project was more of an experiment to see how the console behaves, I haven’t made up my mind yet, but I may just put it up for sale in the future.
 
View user's profile Send private message
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Sat Jan 13, 2018 6:00 pm    Post subject: Reply with quote Back to top

What games did you see an improvement with? And did you fix their tick rate, or somehow they were ok faster. Maybe some videos if possible.

It's a nifty mod for sure, but I think most games are limited by rsp not cpu.
 
View user's profile Send private message
pavarini
00 Agent
00 Agent


Joined: 07 May 2015
Posts: 479

 PostPosted: Sat Jan 13, 2018 7:22 pm    Post subject: Reply with quote Back to top

Could you try Perfect Dark (USA 1.1) using this code? 8138CEB6 0008 8138CECE F0D0
 
View user's profile Send private message
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sun Jan 14, 2018 4:21 pm    Post subject: Reply with quote Back to top

SubDrag wrote:
What games did you see an improvement with?


I'd suspect that the Turok games would show a definite improvement as I know for sure the standard overclock improves framerate for them. Anything by Acclaim also doesn't seem to be affected by the overclock mod so they should boot up just fine.

Pertaining to the bars: Is there a possibility that the different clocking is throwing off the games analytical tools? I'd personally suspect that the RCP is the bottleneck here but with the clocking being different the numbers coming out mightn't be accurate.
_________________
No Mr. Bond, I expect you to be re-coded!
 
View user's profile Send private message MSN Messenger
eb1560
Agent
Agent


Joined: 10 Sep 2016
Posts: 23
Location: North America

 PostPosted: Sun Jan 14, 2018 10:22 pm    Post subject: Reply with quote Back to top

Here is PD Gameplay using 3.0x: https://www.youtube.com/watch?v=VNDGZxsVQbA

Since the magazines in some weapons can discharge incredibly quick (e.g. cyclone), I get the impression that a portion of the bullets fired actually become "projectiles."

SubDrag wrote:
What games did you see an improvement with? And did you fix their tick rate, or somehow they were ok faster.


I didn’t notice improvements in any game. I tested mostly my old cartridges, and focused mainly on in-game timers (vs my cellphone’s stopwatch) and some gameplay (i.e. animation speed doubling). I would be interested in testing a CPU-limited game if I have not already.

Games with sped-up timers and gameplay:
Goldeneye, Perfect Dark, Pilotwings 64, and Shadows of the Empire (SOTE). Interestingly, the increased CPU speed throws the in-game physics out of order in SOTE.

Games with unaffected timers and gameplay (animations aren’t doubled in speed):
Super Mario 64, Cruis’n World, Hydro Thunder, Doom 64, StarFox 64, Top Gear Rally, Turok Dinosaur Hunter, Wave Race, Bomberman 64, Blast Corps, and Automobili Lamborghini. If the 3.0x multiplier is of any benefit, it would probably be with these games, I would like to test a game that can provide stats.

pavarini wrote:
Could you try Perfect Dark (USA 1.1) using this code? 8138CEB6 0008 8138CECE F0D0


After I applied this code, the game’s pace slowed down, 1:00 of the mission timer equates to 1:30 on my cell phone’s stopwatch. The game locked up in one instance when a combat simulator match was starting up (vs 8 meatsims).
I also tested your code using a jumper pack and no enable codes, in this scenario, the game’s pace seems to be the same as 3.0x. However, the game would always lock-up within a couple of minutes in a combat simulator match with 8 meatsims – though the music would continue to play in the background.
So far, the only games that have crashed/locked up with this CPU setup are GE and PD, the latter game only while using your GS code. Crashes happen infrequently and randomly. In one instance on Streets I tried driving the tank through a narrow alleyway, right as I collided with the alleyway’s walls, the game froze – after repeated attempts, I was unable to replicate the crash. Interestingly, a reset is enough to the restart GE, it didn’t require the console to be powered off – to me this suggests the overclock (hardware) is very stable, the game may be running into some issues with the faster processor speed.

MRKane wrote:
Pertaining to the bars: Is there a possibility that the different clocking is throwing off the games analytical tools? I'd personally suspect that the RCP is the bottleneck here but with the clocking being different the numbers coming out mightn't be accurate.


I checked SOTE’s debug mode today, the game’s framerate while standing still in the beginning of Hoth drops from a fluctuating 14-16 Hz in a stock CPU to 8 Hz in a 3.0x overclock – similar to GE’s speed display. I guess both tools may rely on processor cycle time, which is halved when moving from 1.5x to 3.0x.
 
View user's profile Send private message
MRKane
007
007


Joined: 11 Dec 2008
Posts: 1073

 PostPosted: Sun Jan 14, 2018 10:33 pm    Post subject: Reply with quote Back to top

eb1560 wrote:

I checked SOTE’s debug mode today, the game’s framerate while standing still in the beginning of Hoth drops from a fluctuating 14-16 Hz in a stock CPU to 8 Hz in a 3.0x overclock – similar to GE’s speed display. I guess both tools may rely on processor cycle time, which is halved when moving from 1.5x to 3.0x.


That pretty much confirms your prior suspicions there, and it makes a whole lot of sense. It's a real shame that it wasn't a dream come true! Give Turok 3 or 2 a crack - I convinced myself that they both got a better framerate with the overclock, but without analytical tools we cannot really get valuable numbers.
_________________
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, 3, 4  Next
Page 3 of 4

 
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 ]