GP32 What's The Difference Between These Two Speeds?

[Puck2099]

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

 

[woogal]

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.

 

[Puck2099]

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

 

[woogal]

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.

 

[rlyeh]

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

 

[mr.spiv]

Why don't you calculate your clock settings yourself. Take this source http://www.cs.helsinki.fi/u/jikorhon/conde...2/dl/pllset.zip and compile it (the binary is for OSX). There is a selection guide printed out every time you run the tool. :blink:

 

[Reesy]

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?

 

[rlyeh]

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?

 

[Reesy]

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.

 

[WhiteFalcon]

Wow, is there really still so much space for exploration?

......

Or is it only a dead end? :huh:

 

[Reesy]

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?

 

[Horscht]

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.

 

[woogal]

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.

 

[Drag]

What is that second parameter, exactly?

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.

 

[Reesy]

What is that second parameter, exactly?

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.

 

[rlyeh]

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.

 

[Horscht]

im working on a 67 mhz setting which runs apparently like a 166 one

​

:blink:

 

[trooper]

I never cease to be amazed.

Trooper

 

[Drag]

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!

 

[mr.spiv]

What is that second parameter, exactly?

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

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: