http://marex.hackndev.com/whinehack.prc try this, no idea if that's it though ;-) If it has version 1.2 written somewhere then that's it. ps. PalmTT is incompatible with this version since it has passive LCD (which doesnt whine at least for me anyway). Everything with active LCD should be fine (at least PalmZ71 is).

update - it is v1.2 so it's omap compatible somehow ;-)

You rock...I have NEVER been in a situation where I couldn't find something on the net, but you are obviously my better ;)

Thank you...now just to see if it works, LOL...

I am truly amazed...30 seconds of adjustments and the noise is gone...whoever wrote that program should be working for NASA...

Absolutely incredible!

Thanks again!

what device have you tested it on?

I've tested it on a Zire 71 and it works well.
I don't have to choose a hack level, but just change my divisor to 1

Is there anyway to save this setting (or any other) as the default which is activated when the app is started ?
Thanks.

Tested on Tungsten E, same situation as above, hack level doesn't matter, just the divisor. It saved the setting on the Tungsten, it hasn't whined once since...

I have a Tungsten E. Whinehack 1.1 and lower do not work at all, no matter what settings I use. The Whinehack 1.2 posted above DOES work, but now my Palm keeps crashing. It always crashes at the same times, just not consistently: only when it is changing the screen mode.

In particular, this is happening when MobiPocket is either starting or exiting back to the Applications launcher. Other programs do the same thing, crashing my Palm at startup and at shutdown, when the screen .

My Palm is (just now) freshly reset, with no hacks enabled whatsoever. Whinehack 1.0 forced a hard reset on my unit, so I can guarantee that nothing else is running now.

On my Tungsten E, setting the "Divisor" to 2, 3, or 4 has no effect on the whine. Setting it to 1 reduces the noise considerably, and setting it to 0 doesn't quite eliminate it completely, there is still a small buzz, but I have to get pretty close to it in order to notice that.

Changing the "Hack Level" to "I'm Too Young To Die" works, but only until some program changes the screen again. All three other choices eliminate the whine, except for a very brief whine for just a tiny moment when the screen changes again. And for ALL three, my Palm is unstable and needs to be reset repeatedly, just not quite predictably.

And if I try the "LCD registers" option, my Palm just locks up.

Is it possible to get a version of Whinehack where I can pick and choose which events trigger it? Or perhaps even a DA version so that I can activate it on demand with my DA launcher, without resetting the screen? Maybe even find a way to set it so that the "long stroke" from the Graffiti area to the top of the screen turns on Whinehack. I'm just brainstorming here, hoping to throw out ideas to the programmers.

The whining on my T|E is driving me crazy, but this constant crashing is even worse. With Whinehack disabled, my Palm is perfectly stable.

edit the source, compile yourself

The source is only available for Whinehack 1.1, which has NO effect on the whine on my Tungsten E. See http://sourceforge.net/project/showfiles.php?group_id=155828 for the only available files.

So there's nothing for me to edit and compile even if I DID already have any clue how to do that, having never done any Palm development before now.

Some further investigation with Plucker (which lets me pick the screen depth manually) seems to reveal that my Palm only crashes when the screen depth is changing to/from "16". Perhaps it is just a timing issue, if whinehack is being overzealous in updating the register before the palm has finished switching modes?

If anybody else is suffering with my same problem, where your Palm crashes when using Whinehack if an application changes the screen depth, I've got good news and bad news.

By using the freeware "Force16" hack under YAHM, I set ALL of my applications to run in 16-bit mode.

The good news is, now I can have Whinehack enabled to eliminate the noise, while at the same time NOT having my Tungsten E crashing several times a day.

The bad news is, NOT all programs work properly with a 16-bit screen mode. Some, such as Bejeweled and other games by Astraware, will ONLY run properly in 8-bit mode or else the screen's palette is all messed up. Some, such as Mulg, do NOT display correctly at all.

So this is NOT a solution to this problem, not completely. I still have a few programs that I use semi-regularly that won't work right except in 8-bit mode. But at least I can keep my Palm from crashing several times a day now.

Personally, I would have preferred a "Force8" application instead of a "Force16", as at least in theory ALL Palm software ought to work in an 8-bit screen depth without so much trouble, as it is compatible with more hardware.

As it turns out, my crashes are only ALMOST gone. There are still a few functions where the screen resolution reverts back to 8-bit, even with Force16 set to "All apps". In particular, my Tungsten just now locked up when I turned it off and enabling the screen lock. The screen was black but hadn't powered down, and so I didn't notice until after the battery had run down considerably.

So I still really need somebody's help. "Nearly" cured is certainly better than my previous "Totally screwed", but there's still a bit more to go.

Whinehack 1.2 source is available from the Subversion repository if you need it:

svn co https://hackndev.svn.sourceforge.net/svnroot/hackndev/whinehack/


You will need prc-tools and the Palm OS SDK installed to compile it.

Here's what it does on OMAP:

#define LCD_TIMING2 0xfffec00c

...

/* it is OMAP */
reg = (UInt32*)LCD_TIMING2;
irq_off();
*reg = (*reg & ~0xff) | ((divisor+2) & 0xff);
irq_on();

And here's the various hooks that get reigstered on different violence settings:

if (hack_level >= HEYNOTTOOROUGH) {
err = SysNotifyRegister(card, db_id, sysNotifyLateWakeupEvent, NULL,
sysNotifyNormalPriority, NULL);

err = SysNotifyRegister(card, db_id, sysNotifyDisplayChangeEvent, NULL,
sysNotifyNormalPriority, NULL);
}

if (hack_level >= HURTMEPLENTY) {
err = SysNotifyRegister(card, db_id, sysNotifyAppLaunchingEvent, NULL,
sysNotifyNormalPriority, NULL);

err = SysNotifyRegister(card, db_id, sysNotifyAppQuittingEvent, NULL,
sysNotifyNormalPriority, NULL);
}

if (hack_level >= ULTRAVIOLENCE) {
err = SysNotifyRegister(card, db_id, sysNotifyIdleTimeEvent, NULL,
sysNotifyNormalPriority, NULL);
}

So perhaps not hooking "sysNotifyDisplayChangeEvent" may help.

Try whinehack-1.2-no-disp-change-hook.prc (patch).

That seems to help some, but it's not quite perfect. So I figured I'd try taking it a step further...

So I grabbed the prc-tools* and pilrc* rpm packages, and went hunting for the SDK. Various FAQs and so on apparently need to be updated, because the SDKs that USED to be available at palm.com have all moved elsewhere. Anyway I've now got "sdk-5r3" installed.

I've now got my copy of Whinehack to ONLY kick in during the "Idle" event. This means that my Tungsten E may be whining for slightly longer when programs start/end but if it helps make it stable then that's a tradeoff I can live with. In theory, I figure this should make for far fewer lockups, because now I know for sure that the registers aren't being updated while the Palm is in the middle of doing anything else.

While running an app "Stylus Pilot", I found there was now a long lag between screen updates. So I poked into Whinehack's source to search for anything making longer delays, and found that it appears to be when the "load_pref()" function gets called via "call_arm()". So I changed all the "call_arm(load_pref())" to simply "call_arm(0)" and now the response is MUCH faster.

I guess when the PrefGetAppPreferences() gets called, there's a delay as that info gets pulled in from the flash memory. So by taking out that extra lag, hopefully my palm will be that much more stable.

I don't see a way to have more than one choice of "Divisor" when I'm doing it this way, so this particular change is ONLY for units that need a "0", not without having five different versions of Whinehack, one for each divisor.

I'll keep y'all updated in a couple of days once I know if there are any more problems.

My Tungsten E still locks up sometimes. With Force16 running to help prevent the screen from changing depths, it crashes much more infrequently.

However, I will now see an occasional screen glitch, where it seems like the whole screen gets shifted to a new position. ie. the upper-left corner of the screen is somewhere in the middle of the screen, with everything wrapping around the edges. The digitizer has not moved, and I can still select things if I can make a good guess as to where I'm supposed to click. But the Palm will now soon crash, and I cannot find any way to restore the screen's correct position. I suspect this may have much to do with my unit's crashing, as it would seem the memory pointer to the start of screen memory has changed.

I've been poking through some Palm docs trying to find a way to respond to each specific event differently. ie. set the registers one way for one event (the default value), and another way for another event (the quiet value). I was hoping to do something like

if (cmd_PBP->notify->notifyType == sysNotifyDisplayChangeEvent) {
/* do one thing */
} else if (cmd_PBP->notify->notifyType == sysNotifyIdleTimeEvent) {
/* do something else */
}

but I guess I've got the syntax wrong, my compiler just tells me

whinehack.c: In function `PilotMain':
whinehack.c:230: warning: dereferencing `void *' pointer
whinehack.c:230: request for member `notify' in something not a structure or union
whinehack.c:232: warning: dereferencing `void *' pointer
whinehack.c:232: request for member `notify' in something not a structure or union
make[1]: *** [whinehack.o] Error 1

Anyhoo, while poking through some online docs to try and find the correct syntax etc, I read this:

http://www.access-company.com/developers/documents/docs/palmos/PalmOSCom...

IMPORTANT: {snip} When you close a library or unlock a resource, you must first unregister for any notifications. If you don't, the system will crash when the notification is broadcast.

From the context, I can't tell if that is supposed to apply to registering an application or to registering a shared library. But I did see this bit of code in the main whinehack.c for the call_arm() function:

MemHandleUnlock(arm_code_handle);

Could, then, this be what is causing my crashing? If it is, then would the cure be to SysNotifyUnregister() everything before unlocking the memory, and then re-register for the notifications again once all is done? But as I'm hardly an expert Palm developer, I have to wonder if it is even SAFE to register for a notification while in the middle of that notification. Hmm...