Beta Hotfix 4 Beta 3 Released!


The CPU Speed settings script I use is still working.
Could it be MiniMenu changes the CPU Speed when you launch programs even if your current clock speed is higher?
That definately shouldn't happen.
 
Yeah MiniMenu always sets the clock to what it has in it's configuration now, so running any CPU clock tools before running a game will have no effect. Not sure it's a bug or a feature.
 
One thing I would like to see in this hotfix is a change in the /etc/localtime symlink. I recently ported the application Anki, which has a sync function based on the date and time that doesn't work with the way the Pandora's first run wizard presently sets the timezone.

Here are my instructions for fixing the timezone from my Anki thread in the Beta Testing forum:
You will need to reset your timezone and date. I live in America's Eastern time zone (GMT-5) and I had to set my /etc/localtime symlink from GMT-5 to New_York then reset the date to get Anki to start syncing. This is a problem with the Pandora's first-run wizard. Your /etc/localtime symlink should point to a CITY in your time zone, not to its GMT+/-# value.

To set the clock properly for syncing, first see what timezones are available
Code:
cd /usr/share/zoneinfo
ls
Find your continent in that list, then cd to it and see available cities.
Code:
cd America
ls
Find a city in your timezone. Now replace the localtime symlink with the city you found.
Code:
sudo ln -sf New_York /etc/localtime
Sometimes this setting doesn't stick. To make it permanent for sure, set the TZ environment variable add it to bashrc:
Code:
export TZ=America/New_York
echo "export TZ=America/New_York" >>~/.bashrc
Your timezone is now set properly, but now you have to reset the date. To do this, use the "date" command. The parameter must be in MMDDHHMMYYYY format
Code:
sudo date 082322342010
Now restart your Pandora. Anki should not complain about your clock anymore when you sync.
If you could make a script that automatically changes the /etc/localtime symlink to point to a city in the currently selected timezone then reset the date to the current local time as previously configured, that would be a great addition to the hotfix.
 
notaz said:
Yeah MiniMenu always sets the clock to what it has in it's configuration now, so running any CPU clock tools before running a game will have no effect. Not sure it's a bug or a feature.

That's a bug, it shouldn't happen in my opinion :)
 
Last edited:
I will just start using ovr files, which are a good idea but didn't seem to work for me in the past, but do now.

Still, it would be kind of pointless to put cpu speed shortcuts in minimenu by default if using such settings don't do anything.
 
I don't know if anyone else has experienced this, but I can't get the new hotfix to execute. I double click it, it does nothing. It doesn't show up in the "start" menu either. I redownloaded and tried several times.

The last update that I installed was hotfix 2

Do I have to run this from the terminal?
 
Another issue i noticed in some more time since updating; definitely noticing 'hitches' in emulation. In both mame4all and snes9x4d the emu runs full speed except for a hiccup that occurs every few/several seconds. Didn't do that before in either program.
 
Yep, notaz found and fixed that one already :)

Looks like I'll put out a HF4B4 tonight... damn, I thought we could go final :D
 
I've noticed that as well.. thought it was just due to me buggering something up on my Pandora ( I do tend to abuse it a bit with my hacks, after all! ) but when I tried a test rootfs on an SD with this hotfix on and nothing else; it did much the same thing :(

I had it happening in Sqrxz! making it somewhat more trickier than normal ;)
Curiously, the music continues unhitched, and seemingly the logic too, but the graphics definitely pause; as I've ran into things without noticing till it's updated after the pause.

[edit]
blaah.. double ninjad while I was making sure I spelt Sqrxz! correctly, and testing it again to get a decent bug report!
 
Ah, a bug from when I converted to using skins from directories instead of assuming a skin, etc. It actually colours it black, then uses trhe background image for the area and darkens it a couple times ... but I'd changed a few skin conf items around, so it was using the wrong image the wrong way, and so not doing anything there. So we were both right :)

I've just checked in a fix, so it should use the same artwork it normally does, so the skin should be able to do something useful with it there.

jeff
 
notaz said:
DaveC said:
Does this only work globally or can it easily be integegrated into apps? So for example if one would want 2X mode to use NNI, and for fractional use the filter in the same app?
It's global but apps can change it when they want to, similar like CPU clock. If you have HF4b3 installed, start up terminal and type:
Code:
sudo /usr/pandora/scripts/op_videofir.sh none
Then run ginge or psx4all or whatever.
How would I make it so if I run Ginge for example through minimenu it would automatically configure the filter, then run the app without having to go to the terminal, type all of that, then go back to the menu then load the app?
 
Last edited by a moderator:
You'd only have to do it once you know, not every time you ran the program.. unless you want to use the different filter for something else. Someone could make a startup script.
 
But, if you put a file on the root of the pnd at the appdata called cpuspeed, you can configure :rolleyes: the speed of the cpu on a per application level, and just during the execution.
Couldn't be done the same with the filters?

A file that says what filter to use.
And when used, it would ask, "The * application recommends using the filter *. Do you want to use it: Yes, No, Always, Never."
 
Pleng -- looks like the latest beta for hf4 has the latest mmenu in it, which should fix up the background image behind the select menu; thanks for pointing that out :)

(and for everyone else .. I added an option so that mmini can be told not to screw with the cpu speed at all, on exiting mm; ie: so you can have it do it, or not. It might be cool to have a per-app setting, but the system already supports that via ovr files, so one of these days I'm going to write an ovr-file-editor to do that. We also removed the option ofr 'set cpu speed within mm itself', since some weird system problems were showing up when overclocing really high .. and we really don't want people to hang themselves by blowing up their menu by running too high :)

jeff
 
You know, we can put a 'preferred filte' option into the ovr files even .. then once we have an ovr editor (if we like the whole ovr file thing at all, that is :), then we coudl have libpnd switcfiltered when an app is launched.

Hmrf.

jeff
 
Well, one thing I was planning for HF5 was a tweaking script where you can tweak settings like selecting default filter, set OPP limit, select min / max overclock settings, etc.
 
EvilDragon said:
Well, one thing I was planning for HF5 was a tweaking script where you can tweak settings like selecting default filter, set OPP limit, select min / max overclock settings, etc.

add an option to change the cpu change delta, a change rate of 1 drives me nuts trying to hit even numbers.
 
Last edited by a moderator:
Pickle said:
EvilDragon said:
Well, one thing I was planning for HF5 was a tweaking script where you can tweak settings like selecting default filter, set OPP limit, select min / max overclock settings, etc.

add an option to change the cpu change delta, a change rate of 1 drives me nuts trying to hit even numbers.

I would even say that in a certain range teh delta should be 10.
It takes forever to go from 200 to 600. And in that range I see no reason to not change the speed steps of 10. After that a stepsize of 2 or even 1 is acceptable.
 
Last edited by a moderator:
Back
Top