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

[MRKane]

Funny we've not managed to find anything different. Will try to find the time to have a tinker with this, but it wouldn't surprise me if the numbers were almost a processor reference. Might checkout some of the beta releases to see if I can find different come to think of it.
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

I just found an interesting file.
It seems as though the header prior to CRC is injected into all makerom builds.
The file is called "romheader" with no extension and it contains ascii text

Quote:

803712400000000f 000020000000144c

How some retail games have different values is a puzzlement as there is no documented information on the first 128bit other than by hackers.

Anyway, just thought id through that out there

Trev
_________________

[acceptable67]

I have many tools on my computer that pertain to building and programming N64 ROMs.

There is a program that specifically builds a ROM specifically from MIPS assembly code that has a Library folder with a file named 'N64_HEADER.ASM'

Quote:

;============ ; N64 Header ;============ ; PI_BSB_DOM1 db $80 ; Initial PI_BSB_DOM1_LAT_REG Value db $37 ; Initial PI_BSB_DOM1_PGS_REG Value db $12 ; Initial PI_BSB_DOM1_PWD_REG Value db $40 ; Initial PI_BSB_DOM1_PGS_REG Value ; CLOCK RATE dw $000F ; Initial Clock Rate ; VECTOR dw Start ; Boot Address Offset dw $1444 ; Release Offset ; COMPLEMENT CHECK & CHECKSUM db "CRC1" ; CRC1: COMPLEMENT CHECK db "CRC2" ; CRC2: CHECKSUM dd 0 ; UNUSED ; PROGRAM TITLE (27 Byte ASCII String, Use Spaces For Unused Bytes) db "TEST ROM N64" ; "123456789012345678901234567" ; DEVELOPER ID CODE db $00 ; "N" = Nintendo ; CARTRIDGE ID CODE db $00 db 0 ; UNUSED ; COUNTRY CODE db $00 ; "D" = Germany, "E" = USA, "J" = Japan, "P" = Europe, "U" = Australia db 0 ; UNUSED

I noticed clock rate was an option in the above script. Perhaps that may be of use to you.
_________________

Rare wrote:

Perfect Dark Forever.

[MRKane]

Interesting...I've found the header information to be sparsely documented and am actually wondering if some games (looking at you GE!) throw out the information and continue on their merry way shortly after load. Zonkity gave me a memory address for the timing values but I've not been able to make good with modifications using a gameshark, but I've had a machine running windows for a week now so should get back into it soon!

Also talking with Sub about the "slow mo speeds" in PD makes me think that there might be a multiplier in the TLB which handles "normal" speed for the game - that one won't be easy however and it might be something only people with a backup device could use were we to ever get onto it.

In other news, brought a "broken" N64, found a $40 can of automotive spraypaint at the tip for $2...I feel another overclock coming on! hehehehe
_________________
No Mr. Bond, I expect you to be re-coded!

[MRKane]

Right. I had a bit of a chat with Zonkity and he explained things in "N64 for Dummies" for me. It would appear that the clockrate is getting through to the timing value in memory - just the emulator doesn't respect it and runs at normal speed.

I'm keen to test on the Everdrive when I finally get it from the post office. To be honest I've never met any paid service so backwards at the New Zealand postal system...
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

The problem is I have already tested this on the ED and it has made NO difference except for crashing as posted in the previous page.

Zoink, to save double testing, which values did you use?

Trev
_________________

[MRKane]

So a N64 I was trying to salvage didn't make it. I got it going but the deck was a bit intermittent and I found that some of the pads had lifted thanks to what looked like juice being spilled through it (this is the one that had some qtips INSIDE it...how?). The pad off pin 113 turned out to be the problem and had come totally unstuck (and probably others elsewhere, but if anyone knows where it's got to go I might wire it in, why? BECAUSE...also more annoying as I had a $30 lighting setup to drop into it).

Anyway, time to breakout the multimeter and get invasive. So pin 112 (1.5x overclock) actually has 3v going to it under standard operation, and 116 is grounded. I found this odd as a standard overclock will feed 3.3v off one of the capacitors to this pin which does result in faster gameplay for PD and GE as well as weird stuff in Mario Kart. I've still not found where it gets 3V from, but it's got to be one of the microresistors on the board that are bringing it down to exactly this. So as Trevor said way earlier, feeding ground to this pin is probably an underclock, but I've not noticed any difference in play.

I'm sure the CPU was sound and undamaged from water, so really do think that it was 3V exactly (also, my voltmeter is analogue but pretty accurate) and I probably wouldn't have either if the pin didn't slip off while I was cleaning it.

EDIT: Found that pin 113 is VCC (main cpu voltage) which means a jumper to another likewise pin might resolve this particular instance (until I find another one) I might have a play with this 3V stuff afterall!
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

Doh... kids and juice...

Yeah, The internet is mixed terminology with regard to 1.0x, [1.5x]*, 2.0x and 3.0x.
Absolutly Technichally speaking they are all 'Overclocks' from 62.5MHz Bus speed (RCP)

However, I tend to think of it in relation to Nintendo's Baseline which States the CPU at 93.75MHz* (1.5x) as Normal.
With this, 2 & 3x are both "Overclocks" while 1x is an "UnderClock"

Is it not the same for PC CPU's?
A 2.4GHz CPU is actually something like 24x 100MHz

Someone might "Overclock" it to 2.9GHz while some "Underclock" it to 2GHz to cool it.
Even at 2GHz considered an "Underclock" is still in all Absolutes an 'Overclock'



What we should do is decide which to use and stick with it.

I would probably concede that at least here the general Definition is that Nintendo 'Overclocked' their system and so ALL pins are 'Overclocks'.



Hopefully you get pin 113 connected.

Trev
_________________

[MRKane]

I agree with you on that one. I'd say that:

112 116
GND GND Underclock
3V GND Normal
3.3V GND 1.5x+ overclock (timing increase on RCP and instability in some games)
GND 3.3V 2x overclock

Running it in underclock can have funny results in some games - timers can be thrown way out also (which is amusing if nothing else).

EDIT: The VCC for the processor is 3.3V and can be supplied from the second closest capacitor. The actual closest appears to supply a little under 3V - would use it if I didn't now have a wire running across it to fix pin 113.
_________________
No Mr. Bond, I expect you to be re-coded!

[Trevor]

Code:

112   116 GND   GND   1x      Underclock 3V    GND   1.5x    Normal *Stock 3.3V  GND   1.5x+   Overclock (timing increase on RCP and instability in some games) GND   3.3V  2x      Overclock 3.3V  3.3V  3x      Overclock (Never sutable)

Oh... I see now... so feeding 112 a slightly different voltage (3/3.3) seems to alter the speed of 1.5x?
I thought the pins were binary, in that ANY voltage counted as 1 and the multiplyer only had 4 states?

Trev

* Found the word Stock and realised it was a better word to Normal.#


EDIT
wait a sec... Timing increase on RCP? OHHH... so this is not part of the CPU multiplyer, you added it for completion of the table?
_________________

[MRKane]

"Stock" is an excellent word for that! I'm only mentioning the 3.3 on 112 from what I've observed. GE and pd for instance seem to have something going on when 112 has 3.3 volts through it. I'm hoping it's something I can experiment with a little but I'd thought (until now) that the board only delivered 3.3, 5 or 12 volts. Remember that this could also be the result of damage to this particular board that I'm messing with! Still, it would be interesting to track down a switch to test it...I thought they were binary also. Might have to find a board that's not damaged...and I haven't messed with...

Hopefully the everdrive will be here soon - I really want to dry PD with a different slow motion level
_________________
No Mr. Bond, I expect you to be re-coded!

[MRKane]

So I can't leave well enough alone and I'm back into this again (and trying to track down internal clock settings).

So this time I decided to try and go about modifying the value set within memory (around 80026980) and that resulted in some really interesting stuff happening with load times (going from some two to fifteen minutes), or in some cases not loading at all - and it was only the last values on the number that had any load success.

So: 02 CB 41 78...overwriting the first two causes a lockup, overwriting the second two loads, but painfully slowly. I've the feeling that it might have to do with the GS here so I'll see about investigating the ASM side of this one over the next while, but there could be so much more going on here which could make it impossible for the unit to run with different timing values.

EDIT:
Changing it during runtime using a GS doesn't change anything either. What's to bet that the speed calculations are handled as a frame delta time calculation occurring somewhere in the main programme loop? Now finding that - that's nearly impossible.
_________________
No Mr. Bond, I expect you to be re-coded!

[MRKane]

You guessed it! Back at it! This time, with some timing studies.

So my chosen game of choice was Goldeneye and I'm fortunate enough to have access to bits of consoles from all regions. Armed with a stock-watch I went about trying to check the timing on the game, but the only "clock" I had access to was the watch (thanks in part to my own meddling).

E/U Goldeneye runs at the same speed irrespective of the region. This struck me as odd as the U version should be pushing 30fps with the PAL version running at 25. I also know there's some more interesting differences between the different regions consoles (noted at end of message). I keep on feeling like there's something I'm missing here.

The other possibility is that the watch isn't a good indicator of game speed - and I need to unlock Silo on hard for both copies to see how quickly the clock goes on the different consoles.

Ideas anyone?

=========From saturnu so we can trust this:=================
NTSC...

Colour sub = 3.579545 MHz
Vid Xtal = 14.318 MHz
RAM Xtal = 14.7 MHz

RCP = 60.852265 MHz
CPU = 91.2783975 MHz
RDRAM = 249.9 MHz


PAL...

Colour sub = 4.4336188 MHz
Vid Xtal = 17.7345 MHz
RAM Xtal = 17.7 MHz

RCP = 62.0706625 MHz
CPU = 93.1059938 MHz
RDRAM = 247.8 MHz

EDIT:
Setting the value stored in the reflected clock value ie. 81026984 03CB didn't appear to have any effect. No matter what I threw at it. I've tried tracking the tick rate but can't seperate it out from the standard running of the emulator yet . I tracked down the codes for keeping the player as a bomb in Mario Kart, and making bombs fire - so I'm sure I can track down the clock timing centre of Goldeneye!
_________________
No Mr. Bond, I expect you to be re-coded!

[SubDrag]

Do you still have an overclocked N64? The GE cycle counters are now known, you should be able to adjust to new rate (ignore the eye/intro being too fast, these only take hold ingame). The counters are used to count ticks (if a long time passes, will be more ticks).

Adjust by ratio of clock change, I imagine downwards (it's divided by this value, a tick is (cpu change + 5EB61) / BD6C3

800484B0 counter var
80006474: 3C010005 LUI $at, 0x0005 #
80006478: 3421EB61 ORI $at, $at, 0xEB61 #(*CONSTANT) 0005EB61

PAL 70005894

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

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

PAL 7F0C0020

PAL
E34EA
71A75

[eb1560]

Thank you for that information SubDrag. I did some tinkering with the values in your previous post - though the values in my own GE ROM are located at slightly different locations, it did the trick of normalizing a CPU-only overclock.

5EB61: if this value is increased the cadence (and timer) in the game will increase (double the value = "double the pace"). Using a lower value seems to have no effect. I guess if a 1.0x CPU multiplier is used, then this is what should be modified?

BD6C3: Increasing this value only, will normalize a CPU overclock according to the ratio of clock change.