Cpu/lcd-tweaker

[god_at_hell]

Does the line reappear with both versions?

In version 1.0.1 the LCD gets a ~75hz refresh, in 1.0.1 only ~60hz ... when you only tried V.1.0.1, try the other one.

The two versions can run on both firmwares, the only difference is, that the 1.0.1 Version can't change the timing on the 1.0.0 firmware ... the rest is working. If you have a 1.0.1 Firmware, you can in fakt use the version you like the most .

If the line doesn't reappear with V.1.0.0 i could make a personal 1.0.1 Version for you, where the LCD gets a refreshrate of ~60hz.

 

[Wonder Boy]

Does the line reappear with both versions?

In version 1.0.1 the LCD gets a ~75hz refresh, in 1.0.1 only ~60hz ... when you only tried V.1.0.1, try the other one.

The two versions can run on both firmwares, the only difference is, that the 1.0.1 Version can't change the timing on the 1.0.0 firmware ... the rest is working. If you have a 1.0.1 Firmware, you can in fakt use the version you like the most .

If the line doesn't reappear with V.1.0.0 i could make a personal 1.0.1 Version for you, where the LCD gets a refreshrate of ~60hz.

​

Yeah, I believe that the line does not appear finally with V.1.0.0 ... but only I believe, because I have my eyes tired and I'm not sure 100% if still this appears united to some edge of the screen (left or right), but as I say, believe that no.

This means that my LCD is defective and does not support more of 60hz (cannot work in 75hz like a correct LCD)? ... I ask it, because it means less quality (or clearness) in my screen... right?

Somebody more has this same problem?

...and yeah, my personal 1.0.1 with 60hz version would be interesting, thank you, but my screen will lose quality when working only in 60hz and not to be able to do it in 75hz as it would have to be :-(

 

[Ninjia^]

Don't upgrade on a 64Mb card, Quiest. You'll brick your unit, I'm afraid (1.0.1 removes 64mb support half-way through the firmware update, which rather messes you up if that's what you're using)

​

Well I updated my firmware including the boot image with a 64Mb Kingmax card and I know a few other have updated with 64Mb card aswell. Where did you get this information Tobriand?

 

[Tobriand]

Well, to be fair, I haven't looked at the code... but I know I read through a thread by one guy who seemed to brick their GP2x precisely by upgrading on a 64mb card. Whether or not it's definitely the case (and it might not be entirely wise to take my word as authoritative), upgrading on a 64mb card certainly warrants a LOT more caution than on larger capacities...

EDIT: Was posting in response to Sam (concerned about being taken as authoritative when I'm not)... still maks sense in this context though. The original thread is definitely still around, although considering the sheer number of threads about bricking 2xes, I doubt I'd be able to find it

 

[greven]

With the firmwre 1.01, as ED said, 8890 seems to be very adapted.

 

[god_at_hell]

but 8890 is out of the program (the last two digits won't be used anymore ...because it was a mistake )

btw ... the NEW Version is out.

Get Version 1.1 here.

Changes since last version(s):

- merged to one version
- using commandline-options
- cleaning up the code (indend was really necessary)
- fixed some issues
- added output
- removed "disable_940t()", because it doesn't do anything.

 

[Tobriand]

Very cool

Unfortunately, I can;t get it to run anything after it executes itself in a script; as far as I'm aware (albeit I don't have much knowlege of Linux batch-esque scripts), this:

#/bin/sh
/mnt/sd/cpu_speed.gpe 1 1 200 > /mnt/sd/output.txt
cd /mnt/sd/drmd
./DrMDx.gpe
cd /usr/gp2x
./gp2xmenu

Ought to work. But it doesn't - it definitely changes the LCD settings, but after that, no matter what's in the file, it goes back to the menu (even if I remove the scripted instruction to re-load said menu). I seem to recall reading a thread that gave me the impression a program typically reloads the menu on exit, though, so I wonder if it's simply doing that automatically on the command line as well as on the manual mode, thus precluding the script? Just a thought...

Many thanks for your work on this tool, though... auto-scripting or no, it's *very* cool .

 

[god_at_hell]

yep ... it's in the program ... I yust looked. It's a piece of code in the minimal-lib of rlyeh ... i'll do a quick fix tomorrow .
NOTE: The Program is behaving right ... i should go back to the gp2x-menue .. (otherwise you would be stuck when you exit from the menue). I'll do a cmdline-mode, where no menue-reload takes place.

 

[EvilDragon]

BTW: RobBrown, god_at_hell, hermes/PS2reality and vimacs:
Just talked to Anna from GPH about your program - I shall tell you BIIIIG THANKS
Saves them lots of hardware mods

 

[god_at_hell]

ok .. i was wrong. I can delete the lines and it'll be ok .
I yust made a new version (1.1b) and uploaded it ... now you should be able to run any program after cpu_speed.gpe if you use a GPU-Script.

get it here.


EDIT: AAaahh... sorry ED ... now I blasted up your link to the file-archiv .... ...

 

[Tobriand]

Wootage - as expected, the script now works perfectly. Thanks for all the modifications, god_at_hell

 

[nubie]

Don't upgrade on a 64Mb card, Quiest. You'll brick your unit, I'm afraid (1.0.1 removes 64mb support half-way through the firmware update, which rather messes you up if that's what you're using)

​

Well I updated my firmware including the boot image with a 64Mb Kingmax card and I know a few other have updated with 64Mb card aswell. Where did you get this information Tobriand?

​

Same here, I updated to 1.0.1, worked fine for two weeks.

Bricked my unit; happened on low batteries, with no firmware messing, very weird :blink:

 

[god_at_hell]

hm ... i have to correct what i said earlyer ... the menu-loading is necessary. Without i my gp2x crashes quite often, but commandline works fine *g*.

I'll do a fixup and poste it here.


EDIT: Fix is now complete ... The version has changed to 1.1c.
Now the commandline-mode and menue-mode don't use the same exit-funktion anymore.

May upload to the file-archiv needs to be approved ... in the meantime get it here.

 

[falcomadol]

Same here, I updated to 1.0.1, worked fine for two weeks.

Bricked my unit; happened on low batteries, with no firmware messing, very weird :blink:

​

Check it a couple times giving a minute or two between boot attempts. The long boots are usually related to fsck (log appears in /sd), but I have also had at least one occasion where the system boots to confetti and sits there. I had much fear when it failed on a reboot as well. Gave it a couple minutes and it booted fine again (well, after a long fsck boot).

===

---
#/bin/sh
/mnt/sd/cpu_speed.gpe 1 5 230 > /mnt/sd/output.txt
cd /usr/gp2x
./gp2xmenu
---

It might be a good idea to add a sync line to this script before returning to the menu. There isn't an explicit way to do a safe shutdown of the gp2x, so every file write should be accompanied by a sync, and I suspect that the system will not sync itself on a stdout/stderr redirection write based on other scripts that are floating around.

 

[codesmith]

The long boots are usually related to fsck (log appears in /sd), but I have also had at least one occasion where the system boots to confetti and sits there.

​

Really? If a boot cycle takes longer than about a minute, I just switch off assuming there was a deadlock somewhere. Man, if I did that with my linux desktop (power cycle in the middle of an fsck) it would've been sooo fried by now. Looks like I've been living on the edge :blink:

What's the recommendation? if it takes long to boot, just let it finish on its own?

 

[god_at_hell]

@falcomadol: You don't need to pipe something to a file ... the you don't need a sync. But for piping it's a good idea.

NOTE: If you're in the menue and only want do change some LCD-settings, exit with [start]. If you use select, the CPU-timing get an update and it seems, that it sometimes freezes the GP (although it still runs ... you can send something to it using the serial-cable). If yu use [start] , the change of a system-freeze will be very low.

 

[Mr. Anderson]

note: with "nasty ghost-lines" i ment the diagonal lines which tend to drift over the display on some timing-values ... i think i used the false term for that

​

I like to address them "the holy waves of destruction", oh well I guess you can just call them moving diagonal lines instead <_<

 

[falcomadol]

The long boots are usually related to fsck (log appears in /sd), but I have also had at least one occasion where the system boots to confetti and sits there.

​

Really? If a boot cycle takes longer than about a minute, I just switch off assuming there was a deadlock somewhere. Man, if I did that with my linux desktop (power cycle in the middle of an fsck) it would've been sooo fried by now. Looks like I've been living on the edge :blink:

What's the recommendation? if it takes long to boot, just let it finish on its own?

​

Well, I checked out some of the startup scripts today using sterm (was looking for the script that mounts the sd, didn't find it). It does a number of things that could be pretty time consuming, including the occasional fsck, and clearing temp files etc. Deleting small files from flash media can take a while. Also, as some people have pointed out, it loads quite a lot of things that may be unnecessary (networking components primarily).

I'd like to have someone else who is more knowledgeable about linux boot processes check out all of what is starting up and happening on boot, but I can at least print copies of the rc files (will do in an edit).

I would give it a minute or so. If it really has frozen up, you'll see a visible crash on your display, it won't just be frozen. It could be anything from coredump data to just the image kind of dissolving. Basically, if it crashes, you'll know it, it's not just a lock up. I don't know what the effect of power cycling during fsck on flash media is (if any?).

=== edit

Found the mount for the sd media. It's in /etc/profile (yes, I'm an idiot).

 

[TelcoLou]

Um, I seem to get random freezes ... I'll select 250 or 266 mhz, press 'select' and the app freezes.

It happens when I try to change the LCD timing as well, intermittantly ...

Maybe it's an SD compatability issue? I have a Patriot 1GB stick, which also randomly freezes during boot-up ...

:lol: perhaps I made another useless post ...

 

[god_at_hell]

nah ... it's something about the cpu-clockchange-code.

as i wrote earlyer ... if you only change the LCD-settings, quit with [start] and not select.

only use the menue for testing ... for daily use make a gpu-file