GP32 What's The Difference Between These Two Speeds?


Puck2099

Certified Guru
Joined
Oct 22, 2004
Messages
422
Location
Madrid, Spain
Website
www.gp32wip.com
Hi,

I've been working to fix a graphic problem that GP32 BLU+ users have with my Lady Killer.

I've noticed that changing my "overclocked" 133 Mhz speed from my function:
GpClockSpeedChange(132000000,0x24001,2);
to this one (I think it's Mr. Mirko or ThunderZ one):
GpClockSpeedChange(132000000, 0x3a011, 3);
solves the problem.

Do you know what's the difference between them?

By the way, I've had the same problem using Mr. Mirko's 102 Mhz speed but I haven't been able to find a working one...

Thanks
 
The third parameter is the clock divider. 0 is everything runs at cpu clockspeed, 1 is timers etc run at 1/2 cpu, 2 is memory and timers run at 1/2, and 3 is memory at 1/2 and timers at 1/4. Thats the main difference you've got there.
 
woogal posted on Apr 14 2005 at 11:36 AM said:
The third parameter is the clock divider. 0 is everything runs at cpu clockspeed, 1 is timers etc run at 1/2 cpu, 2 is memory and timers run at 1/2, and 3 is memory at 1/2 and timers at 1/4. Thats the main difference you've got there.

Second parameter is relevant or it's dependent of first and third ones?

Could a timer divider cause syncronization problems in BLU+?

Thanks
 
Last edited by a moderator:
Puck2099 posted on Apr 14 2005 at 10:41 AM said:
Second parameter is relevant or it's dependent of first and third ones?
You usually have a choice of options for the second parameter (you find them using pllset) but I think the only difference is some work and others cause a crash. My guess is the timer clock is the cause of your problem because I've got a feeling it also controls the lcd refresh speed (could be wrong here though). It could be possible that you are just running too fast and you need to drop the cpu clock. It's happened to me before when I was clocking fairly high and accidently had a very inefficient bit of code. I had all kinds of problems that I couldn't understand, but when I spotted and fixed the inefficient code (which allowed me to drop the clockspeed), all my problems went away.
 
Last edited by a moderator:
rlyeh posted on Apr 15 2005 at 10:57 AM said:
by mistake i found that 132000000, 0x3a001, 3 works incredibly fast but inestable, any ideas about this? :)

edit: by fast i mean i earned 20 fps on fCPC32 simply by changing this :)

Thats interesting because 0x3A001 would break the guide line rules suggested in pllset.exe. It says that P should equal 1, so the value should be 0x3A011.

I've just checked a few of the settings in mr.mirkos sdk and the setting for 144Mhz breaks this rule as well

case 144: { CLKDIV=0x28001; MCLK=144000000; CLKMODE=3; break;}

Could explain why this speed is so good.

Does anyone that actually understands all of this ( ie Mr Spiv ) know why P should equal 1?
 
Last edited by a moderator:
i've been testing lots of configurations by my own, and skipping what pllset says, and I've found this setting which rule!

132000000, 0x38001, 3

its stable and it *boots up noticeably* the speed at least for all my emulators }:)

Reesy, can you test those settings in your DrMD please? It would be nice to test it in other intensive application :)

edit: i've noticed the sound is now more 'pitchy', does this mean i've overclocked the cpu clock? or its just the bus? is the first param to the gpclock function useless then? my emus are running bloody fast and im not sure yet if i'm @ 132 mhz or not :) anyone?
 
I tried that cpu setting, it throws the timing of my emulator right off. But...and this is a bloody big but. If I disabled all of the timing control on my emulator and run it with this cpu setting it runs it runs at the same speed as 176Mhz....very nice. I just need to fix the timers when using this cpu setting and it should be great.
 
Well I've fixed the sound in DrMD for this cpu setting, and I'm getting 62fps in sonic 1 at 132Mhz. I wish I understood what was going on here, I guess I need to send out a beta to a few people that can NOT overclock their GP32's. For example people that can not go any higher than 132Mhz on their GP32's, if the setting works on their systems then its all good. Anybody interested?
 
HOLY.......................

WTF?

SOMEONE TRY! SOMEONE? ANYONE?

come on! someone must have a 132 only GP32.

EDIT: probably only a few people read these forums. We should ask in the general talk.
 
rlyeh posted on Apr 18 2005 at 11:01 AM said:
i've been testing lots of configurations by my own, and skipping what pllset says, and I've found this setting which rule!

132000000, 0x38001, 3
Just tested this in gpquake. On my gp32 I can get 160 stable, and 166 for about 10 seconds, but this setting gives me either a white screen or a reboot :(. I think it's safe to say we're pushing things too far and this won't be stable for a lot of people.
 
Last edited by a moderator:
What is that second parameter, exactly? o_O

Also, does this 'magical 132Mhz' setting kill the batteries really quickly, or no?
If magic 132Mhz uses up as much battery power as regular 132Mhz, then that'd be great: high speed without the high speed battery consumtion. :)
 
Drag posted on Apr 18 2005 at 08:58 PM said:
What is that second parameter, exactly? o_O

Also, does this 'magical 132Mhz' setting kill the batteries really quickly, or no?
If magic 132Mhz uses up as much battery power as regular 132Mhz, then that'd be great: high speed without the high speed battery consumtion. :)

Thats what I'm hoping, we'll have to wait and see how everybody gets on. I've put a beta of DrMD in the beta section of this board if anyone wants to try it out.
 
Last edited by a moderator:
Just tested this in gpquake. On my gp32 I can get 160 stable, and 166 for about 10 seconds, but this setting gives me either a white screen or a reboot :(. I think it's safe to say we're pushing things too far and this won't be stable for a lot of people.

yep
funny thing is i see these settings impacting the performance like a 180 mhz clock or something close, but the gp32 which is executing these tests cannot reach 172 mhz with common methods...

im working on a 67 mhz setting which runs apparently like a 166 one... we'll have to see if this one is more compatible

hope all this wont be useless after all

stay tuned


note for newbies: these settings will be probably a strange way to set up, maybe safer, a higher clock setting on your gp32 some day. mr_spiv says it pushes the gp32 to 192 mhz, but the thing is my gp32 cannot reach 172 mhz, so here's the fun. note that batteries at this setting will drain like a 192 mhz setting.
 
So what would the benefit of using magic 132Mhz instead of 174Mhz be?

Or did you just say? (magic 132Mhz pushes the GP32 to 174Mhz stabilly, even when the GP32 normally wouldn't be able to get that fast via regular convention)

But does no one know for sure what that second perameter is? This experimenting is really exciting! :)

Edit: Oh ok, it got explained in Reesy's thread over in beta testing. Still dunno what that second parameter is supposed to be. No matter, it's still interesting! :D
 
Drag posted on Apr 18 2005 at 08:58 PM said:
What is that second parameter, exactly? o_O

Also, does this 'magical 132Mhz' setting kill the batteries really quickly, or no?
If magic 132Mhz uses up as much battery power as regular 132Mhz, then that'd be great: high speed without the high speed battery consumtion. :)

The second parameter is used to pass values to MPLL and UPLL registers, which define the values for the internal prescalers. Those then define how the actual "FCLK" i.e. the output CPU MHz gets derived from the base 12MHz clock. The third parameter then defines how HCLK and PCLK are derived from the FCLK. There's a bunch of rules that define the ranges of the values of the "second parameter"... but as we know GP32 seems to be like Russian AK-47 i.e. what ever you feed to it or whatever are the conditions it works <_< Or should it be like Russian roulette.. good for those who survive and bad for those who don't :p

Anyway.. as these "experimental" values select a faster FCLK, HCLK and PCLK, batteries are consumed faster accordingly. :blink:

Spivvvvy


btw.. the manual still states your are not supposed to force HCLK or PCLK above 66MHz :rolleyes:
 
Last edited by a moderator:
Back
Top