Program to check CPU speed, is it really capped at 222Mhz?
Program to check CPU speed, is it really capped at 222Mhz?
Now that homebrew programming is possible on firmware 1.0, it is
now possible to check the actual speed of the CPU.
So has anyone done it? What is the actual speed of the CPU?
A simple loop in low assembly or C can actually check the
time or run loops and see how fast the CPU is.
If a program is accessing the CPU directly, and not via Sony's
library calls, then you can actually determine if it is the max speed (333mhz), or if the firmware lowered the clock at bootup to 222Mhz.
If no calls are made to the firmware (like the init calls into the firmware
bios), before doing the loop and timing check, you can determine
what the actual speed is before or after library calls.
Maybe there is an undocumented address providing a cpu speed
setting, and all you need to do is to call it, and this function may be
released in later firmware as a cpu speed function call. but if it
boots up at 333mhz, then nevermind.
now possible to check the actual speed of the CPU.
So has anyone done it? What is the actual speed of the CPU?
A simple loop in low assembly or C can actually check the
time or run loops and see how fast the CPU is.
If a program is accessing the CPU directly, and not via Sony's
library calls, then you can actually determine if it is the max speed (333mhz), or if the firmware lowered the clock at bootup to 222Mhz.
If no calls are made to the firmware (like the init calls into the firmware
bios), before doing the loop and timing check, you can determine
what the actual speed is before or after library calls.
Maybe there is an undocumented address providing a cpu speed
setting, and all you need to do is to call it, and this function may be
released in later firmware as a cpu speed function call. but if it
boots up at 333mhz, then nevermind.
Hi,
Yes I was thinking that too. Actually as no timer ability as been found yet except the VBL waiting routine, the only approximately correct way of doing this would be to have an assembly routine (or a C program where the assembly has been checked)
(I dont know the MIPS assembler yet so please forgive me) :
start:
mov counter, #300 000 000
loop:
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
....
(like this for lets say 100 instructions)
counter = counter -1;
cmp counter
jne start
end :
fillScreen with colors to signal end of test.
The points are :
- The code avoid the pipeline to be broken : long segment of code without jump. (a for-loop in C break the pipeline, moreover a compiler can optimise empty loop or useless register usage)
- The code must fit in the cache : have memory hit ONLY the first time it execute.(so it does not count due to the number of execution)
- The code must not do memory access except loading itself in the cache for execution.
- The "unrolled" code section use a very simple instruction where the timing is well known (nop ? mov r0,r0 ?)
Then, we should have a correct measure of the CPU speed.
Personnally I would run the test to loop for 2 to 3 mn.
In this loop, I wrote 300millions x 102 (103 ?) instructions, at one clock cycle per instruction. This should give a very good estimate of the clock speed. (gee I have to learn assembly tonight :-) !!!)
Regards,
romain.
EDIT : Where this 222 Mhz is coming from ???
Yes I was thinking that too. Actually as no timer ability as been found yet except the VBL waiting routine, the only approximately correct way of doing this would be to have an assembly routine (or a C program where the assembly has been checked)
(I dont know the MIPS assembler yet so please forgive me) :
start:
mov counter, #300 000 000
loop:
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
xor r0,r1
....
(like this for lets say 100 instructions)
counter = counter -1;
cmp counter
jne start
end :
fillScreen with colors to signal end of test.
The points are :
- The code avoid the pipeline to be broken : long segment of code without jump. (a for-loop in C break the pipeline, moreover a compiler can optimise empty loop or useless register usage)
- The code must fit in the cache : have memory hit ONLY the first time it execute.(so it does not count due to the number of execution)
- The code must not do memory access except loading itself in the cache for execution.
- The "unrolled" code section use a very simple instruction where the timing is well known (nop ? mov r0,r0 ?)
Then, we should have a correct measure of the CPU speed.
Personnally I would run the test to loop for 2 to 3 mn.
In this loop, I wrote 300millions x 102 (103 ?) instructions, at one clock cycle per instruction. This should give a very good estimate of the clock speed. (gee I have to learn assembly tonight :-) !!!)
Regards,
romain.
EDIT : Where this 222 Mhz is coming from ???
222mhz comes from sony officialy stating the PSP is clocked at 222Mhz even though the cpu max is 333Mhz.
I am not sure how true it is but i have hear from a psp coder that suposetly the bios clocks the cpu even slower when executing stuff from the memory stick. I am not sure how true this is though.
I am not sure how true it is but i have hear from a psp coder that suposetly the bios clocks the cpu even slower when executing stuff from the memory stick. I am not sure how true this is though.
-
- Posts: 4
- Joined: Fri Jun 10, 2005 12:23 am
- Location: http://www.fast-bb-dir.tk
- Contact:
Ugh. I may be wrong, but im pretty sure I read about this from some magazine article.
The 222 cap is not in the firmware or psp itself.
The cap is CODED INTO THE GAMES. Before the games are released they are ran by sony, if they go past 222, they are not aloud to put the game out on retail.
EDIT
So the actual running of the psp(Music,Video) they will run at a full 333, if they would even take that much processing power to do ;).
Point being, if you run a program to determine the clockspeed, its going to be 333. So dont waste your time.
The 222 cap is not in the firmware or psp itself.
The cap is CODED INTO THE GAMES. Before the games are released they are ran by sony, if they go past 222, they are not aloud to put the game out on retail.
EDIT
So the actual running of the psp(Music,Video) they will run at a full 333, if they would even take that much processing power to do ;).
Point being, if you run a program to determine the clockspeed, its going to be 333. So dont waste your time.
i bet it works like on the GP32. the sdk has a function which can change the speed of the CPU. so i guess when they say its capped at 222 MHz, it means that the developers are restricted to use this function with max. 222 MHz. they can use lower clockspeeds like 100 MHz as well if their game doesn't need more. or for example do their normal game calculations at 222 MHz and switch to 10 MHz while waiting for the vertical retrace then switch back to 222 MHz again.
infj
I'm assuming the cap isn't the actual CPU but the framerate? Say it's ran at a fixed 60fps framerate ('hard cap') and the CPU doesn't go over 222 ('soft cap') to achieve this, it would pass?Skye wrote:Ugh. I may be wrong, but im pretty sure I read about this from some magazine article.
The 222 cap is not in the firmware or psp itself.
The cap is CODED INTO THE GAMES. Before the games are released they are ran by sony, if they go past 222, they are not aloud to put the game out on retail.
Who knows, maybe later PSPs will come with a heavier battery standard (2700mAh instead of 1800, a 50% increase) and Sony will allow 333 (also a 50% increase compared to 222).
Sony has publicly stated that there is a library function to set CPU Frequency as well as bus frequency divider. This function will only allow the CPU Frequency to be set from 1-222mhz at the present time even thought the hardware is capable of doing 1-333mhz.
I assume that they did this for two reasons, to avoid coders being sloppy on new HW and to conserver power.
In response to Saotome's post: there will be some (most likely non-trivial) penalty for changing the clock speed as it affects the CPU, GE, BUS and I'm guessing the ME so it wouldn't be used like you suggested. Yes games can run at a lower clockspeed if they don't need more in order to conserve battery life but I am as yet unaware of any titles that do so.
I assume that they did this for two reasons, to avoid coders being sloppy on new HW and to conserver power.
In response to Saotome's post: there will be some (most likely non-trivial) penalty for changing the clock speed as it affects the CPU, GE, BUS and I'm guessing the ME so it wouldn't be used like you suggested. Yes games can run at a lower clockspeed if they don't need more in order to conserve battery life but I am as yet unaware of any titles that do so.
Hum... I am not sure that the console run at full speed (333) by default.
(even 222)
If you take the GP32, it can go up to 133 or 166 but it start at 66 mhz.
Considering the battery energy as wealth, you care about it and you dont want to waste it.
I think it is really to the game to handle it : like when you are in the menu, you can drop to 30 Mhz. Even if there IS a penalty it is unlikely for the user to feel it.
Now for making a really powerfull emulator, one really need the full cpu speed of the PSP. Thats why I wanted to be really sure before going into optimizing stuff like Snes9x.(dont want to write a full cpu or audio emulation in ASM if I can get the hard to draw half of the graphics in some month and if the clock speed is increased by 100%)
I started to make the CPU test I stated before, but the assembler is so different from ARM (and I could not find really good tutorials about mips) I was a bit confused and could not make it work correctly. (infinite loop or exit right away). But beeing REALLY busy with my job I couldnt afford more time.
(even 222)
If you take the GP32, it can go up to 133 or 166 but it start at 66 mhz.
Considering the battery energy as wealth, you care about it and you dont want to waste it.
I think it is really to the game to handle it : like when you are in the menu, you can drop to 30 Mhz. Even if there IS a penalty it is unlikely for the user to feel it.
Now for making a really powerfull emulator, one really need the full cpu speed of the PSP. Thats why I wanted to be really sure before going into optimizing stuff like Snes9x.(dont want to write a full cpu or audio emulation in ASM if I can get the hard to draw half of the graphics in some month and if the clock speed is increased by 100%)
I started to make the CPU test I stated before, but the assembler is so different from ARM (and I could not find really good tutorials about mips) I was a bit confused and could not make it work correctly. (infinite loop or exit right away). But beeing REALLY busy with my job I couldnt afford more time.
Seems like there are new emulator releases with this CPU adjustment option.
Just look over at www.psphacker.com.
I'm not gonna try this yet though.. :)
Just look over at www.psphacker.com.
I'm not gonna try this yet though.. :)
the clock speeds can be set with the scePowerSetClockFrequency function...
http://forums.ps2dev.org/viewtopic.php?t=2093
http://forums.ps2dev.org/viewtopic.php?t=2093
Can someone please confirm the results of doing this? Very tempted to give it a go, but I don't want to zap my 1.0 PSP. Being in Blightly, I've got no warranty or other recourse other than buying a new unit.
Sorry, bit paranoid that Sony sets the CPU at 222MHz for some reason other than battery life.
Sorry, bit paranoid that Sony sets the CPU at 222MHz for some reason other than battery life.
Hi,
The PSP is far more public than a console like the GP32.
It is true that in the case of the GP32 you could damage your hardware.
If a setup of the clock speed would have been dangerous for the hardware, Sony would not have authorized such API at first. I believe so.
It is not overclocking :-).
Even if setting badly the clock multiplier could be dangerous, they would probably check the value by software and do not execute the command.
And even if it is dangerous (like having the life of your LCD or RAM dropping by 50%) people will notice it only in a while... in between I bet all emus working on PSP will do use these APIs and roll back to less dangerous values if something goes wrong (and it is really proven).
Regards.
Vampire > Thanks for the link !
The PSP is far more public than a console like the GP32.
It is true that in the case of the GP32 you could damage your hardware.
If a setup of the clock speed would have been dangerous for the hardware, Sony would not have authorized such API at first. I believe so.
It is not overclocking :-).
Even if setting badly the clock multiplier could be dangerous, they would probably check the value by software and do not execute the command.
And even if it is dangerous (like having the life of your LCD or RAM dropping by 50%) people will notice it only in a while... in between I bet all emus working on PSP will do use these APIs and roll back to less dangerous values if something goes wrong (and it is really proven).
Regards.
Vampire > Thanks for the link !