Gp2x Delfault Runing 298mhz !!!


Still on the old fw and 280 too.

My thought was that someone applied a clockspeed change in one of his games/emus/apps that got saved, like you can save the clockspeed with this program. So if you would run that program, the speeds got highered to 280 and stayed there, and the people who didn`t run that certain game/app/emu stayed at 210.

Well, can`t be the case anymore, since it just was an old version of the program and it is not the actual clockspeed value that gets displayed.
But I just wanted to share my theory anyways :p
 
OK, we'd better put this one to bed NOW!

The results from Hermes_PS2R's program are invalid, because of a bug in the code.
Code:
void set_FCLK(unsigned MHZ)
{
   unsigned v;
   unsigned mdiv,pdiv=3,scale=0;
   MHZ*=1000000;
   mdiv=(MHZ*pdiv)/SYS_CLK_FREQ;

   mdiv=((mdiv-8)<<8) & 0xff00;
   pdiv=((pdiv-2)<<3) & 0xfc;             /* <-- should be << 2 */
   scale&=3;
   v=mdiv | pdiv | scale;
   MEM_REG[0x910>>1]=v;
}

unsigned get_freq_920_CLK()
{
   unsigned i;
   unsigned reg,mdiv,pdiv,scale;

   reg=MEM_REG[0x912>>1];
   mdiv = ((reg & 0xff00) >> 8) + 8;
   pdiv = ((reg & 0xfc) >> 3) + 2;         /* <-- should be >> 2 */
   scale = reg & 3;
   MDIV=mdiv;
   PDIV=pdiv;
   SCALE=scale;

   i = (MEM_REG[0x91c>>1] & 7)+1;
   return ((SYS_CLK_FREQ * mdiv) / (pdiv << scale))/i;
}
Because of this bug, the PLL is not getting set correctly, and the clock frequency is not getting read from the PLL correctly.

ALL GP2X's run at 200MHz by default. Hermes_PS2R's program is wrong.

Also, for those people who have found that the LCD changes when the clock speed has changed, this is because the LCD clock is derived from FPLL, so changing FPLL changes the LCD clock. Simple! The LCD clock should be re-set whenever FPLL is changed.

Here's my routines to do the same thing as Hermes_PS2R is doing, but (afaik) these ones work correctly:
Code:
static unsigned int CalcPll (unsigned short pll)
{
   unsigned int temp1, temp2;

   temp1 = 7372800 * ((unsigned int)(((pll >> 8)&0xff)+8));
   temp2 = ((unsigned int)(((pll >> 2)&0x03f)+2)) * ( 1 << ((unsigned int)(pll & 3)));
   return temp1 / temp2;
}

unsigned int sdk2x_GetFPLL (void)
{
   return CalcPll (MSP_FPLLVSETREG);
}

unsigned int sdk2x_GetUPLL (void)
{
   return CalcPll (MSP_UPLLVSETREG);
}

unsigned int sdk2x_GetAPLL (void)
{
   return CalcPll (MSP_APLLVSETREG);
}

unsigned int sdk2x_SetFPLL (unsigned short FpllSetReg)
{
   int i;
   unsigned int imask;

   imask = MSP_INTMASK;

   /* Mask ALL interrupts */
   MSP_INTMASK = 0xFF8FFFE7;
   MSP_FPLLSETVREG = FpllSetReg;

   while (MSP_CLKCHGSTREG & 1);

   MSP_INTMASK = imask;

   for (i=0;(i<10000000) && (MSP_FPLLVSETREG != FpllSetReg); i++);

   return CalcPll (MSP_FPLLVSETREG);
}

If you're interested, I've modified the old pllset.c program to handle the MMSP2. You can get it from my site.
 
Robster posted on Dec 9 2005 at 09:23 PM said:
If you're interested, I've modified the old pllset.c program to handle the MMSP2. You can get it from my site.


but we can't use it directly without compiling right? :D
 
Last edited by a moderator:
Robster posted on Dec 9 2005 at 11:23 PM said:
OK, we'd better put this one to bed NOW!

The results from Hermes_PS2R's program are invalid, because of a bug in the code.

I was expecting something like that.
 
Last edited by a moderator:
Yeah, could anyone correct Hermes clockspeed changer and compile a gp2x version, please?

Oh, and make it to let us clock it to 266, that should be stable, and we can enjoy SNES and NeoCD a bit more...
 
ah, my spanish is not great but seems that hermes realised his bug, and said that he can't overcklock stable over 210mhz :/ (divx crashes)


wich seems quite weird considering it's way under the theoric limits of the chip :huh:
 
mebe when he applies the OC the 920T that runs the divx decoder doesnt like it? i have no idea
 
well i kept working on my spanish :D

according to hermes, from what i understoo , it would be too easy to assume that the higher frequency would be guilty for the stability issue, the system seems rather to suffer from some kind of collapsing due to the frequency changing itself , while the chip seems technically able to go over 300mhz (stable or not)

so he says the important is that his routines are working, so i suppose he'll make a fixed version soon, and then we'll be able to try to find what's causing these crashes under 266mhz :)
 
Quiest posted on Dec 9 2005 at 11:05 PM said:
Yeah, could anyone correct Hermes clockspeed changer and compile a gp2x version, please?

Oh, and make it to let us clock it to 266, that should be stable, and we can enjoy SNES and NeoCD a bit more...
Isn't it up to each emulator to set the desired CPU frequency themselves?
 
Last edited by a moderator:
With the "merge" executable I tried clocking down to 60HHz and then running DrMD. It seems to be going at fullspeed... so I kinda doubt that it worked.
 
Back
Top