Hi:
I've divided the article into two parts, the first explanation and the second examples. Here's the first. Comments and suggestions please!
Tom
Divining NVFS and Palm Memory Problems
Solutions including Uncache and UDMH
Precautions
While the T/X is quite stable out-of-the-box, with no third party applications installed, such a limited install set would be the equivalent of owning a rocket ship to go to the corner store. Presumably you are reading this article because you would like to extend the capabilities of your NVFS Palm device. The beauty and the strength of the Palm comes from both its developer and user community. There are hundreds of Palm applications, many free and many shareware, with trial downloads but for a fee. Most are NVFS aware but some are not. Some interact well together others take some tweaking. You're going to be pushing the envelope, so BACKUP.
There's an incredible piece of software by Alex Pruss, free, called NVBackup. The most recent version is 1.21 and is available at:
http://sourceforge.net/project/show...ckage_id=186018
NVBackup, for NVFS devices, will backup your entire Palm to your sd card, with both complete and selective restores available. Take the twenty or thirty minutes needed to backup your Palm before you start on ambitious software experimentation. I didn't have all of the right sofware installed before I tried out some software and ended up in a reset loop. Thirty minutes later I was back in business thanks to NVBackup.
Alex Pruss is one of the incredible independent developers that writes software to solve problems that Palm neglected. Please support his software, perhaps using Palm Gear last as the charge the highest premiums, available at:
http://www.zlthemes.com/ www.palminfocenter.com http://handypalmstuff.sourceforge.net/ www.palmgear.com
Including, Fontsmoother, Mykbd Atomik Keyboard and MySkin along with other freeware programs.
At the end of this article there are links to many threads, mostly from
www.1src.com. Most of this article was lifted verbatum from a variety of threads, over a fairly long period of time. You will see references to a few users bricking their devices using very early beta versions of some of the software we are going to discuss. Rest assured that all of the software is now stable and has been for quite some time and will not brick your device.
Skipping ahead, all of the software covered deals with problems with NVFS memory. These are solutions trying to deal with the legions of problems that Palm left behind. Just backup before you play. As one of the 1src users put it:
“I never, ever worry about having to remove an app after I've tried it because I just use NVBackup first, then try out the app & if I don't want to keep it - just restore!! That ensures that all of the files are gone and everything is back exactly where I left it.”
Lastly, leave at least 20MB free on your NVFS partition; that way things are very unlikely to go bad on you.
Most recent Palm devices ship with the NVFS File System, Non-Volatile File System. These would include: Tungsten T5, Treo 650, Tungsten E2, LifeDrive, TX, Treo 700p, Treo 680, Treo 755p etc,
NVFS Palm devices have 10MB of working memory, Dynamic Heap, and 20MB of data memory, DB Cache. Roughly 7MB of the 20MB of DB Cache is locked and reserved for OS use, leaving roughly 13MB for applications to reserve for their own use Data memory (DB Cache) pre-caches data from NVFS so that it can be read by the CPU at a reasonable speed.
The DB Cache is where all data is stored for manipulation by currently active software on NVFS devices. The OS automatically flushes the cache whenever the 13 available megabytes fills up. The danger of letting Palm deal with the DB Cache is it will flush whenever the memory is filled, including the middle of your document or prior to saving. A good rule of thumb is: don't flush the DBCache while an application might actually be reading from it or writing to it. There's no way to (safely) flush locked data but flushing when turning off guarantees that you'll get the most stable possible flush, as opposed to taking your chances with the flush routine provided by the OS.
Solution: OffFlush 2.0 by Alex Pruss
OffFlush 2.0 available at:
http://www.1src.com/freeware/fileinfo.php?id=1526
OffFlush flushes the DB Cache when you turn off your Palm and memory is getting low. The DA that comes with it lets you trigger this manually whenever you know it is safe to do so. Older apps like DBCacheTool would also do this at app launch time, but could cause data corruption, soft resets, and even bricked devices.
This is a stable version of Off Flush that has the check box to enable the program to flush the cache only when you use a button to turn off the pda, if your cache is also below the limit that is set. This ensures that the cache will not flush with auto off and possibly interupt a process.
The button used to turn off the pda does not have to be the power button. It can also be a hard button that has been mapped to power off. It has not been tested with "turn off" apps.
Due to the inherent dangers of messing with NVFS memory, by the aware and unaware, by those that backup and those that do not, the developer Alex Pruss is no longer actively supporting OffFlush. That being said, myself and many other Palm users consider it to be essential utility. Highly recommended!
Older software not designed with this architecture in mind sometimes assumes that all its dataspace is ALWAYS available. Applications set a lock bit for data they require, and unlock that data when they're done with it but any that don’t deal with NVFS correctly or get flushed when the cache fills up can produce strange results.
If some app (say, Blazer) decides to lock a section of DB Cache permanently for its own use, and decides (like Blazer) to reserve a small section in the middle of the cache, you now have two 6MB pieces of DB Cache to work with instead of one 13MB piece. Not a problem for regular apps, as they rarely have records larger than 6MB. However, emulators and other demanding applications have large files they need to cache, and those files won't fit in a 6MB piece of memory. Since Blazer is being greedy and insists it needs to keep that bit of memory for the OS to function correctly, there is not enough physical memory available to store the data you need to cache, resulting in an error. The only way to release that locked memory is to purge the entire OS from memory and reload it. We call this a soft reset.
DBcache is like a large trough and Blazer and other programs grab spots right in the middle while another programs have to settle for available memory on either side of offending programs like Blazer. More demanding programs launch only to find another program has locked a spot and it can't get enough contiguous memory.
On NVFS devices, the cache gets cleared whenever a program requests more cache space than is currently available in a contiguous block -- this is what causes those long Blazer load times. Unfortunately, any time a program requests a chunk of DBCache as Protected, that chunk can't be flushed without a reset -- this eventually results in severely fragmented DBCache, with lots of free cache, but all in unusable tiny chunks.
Dmitry Grinberg, an outspoken young developer/student, has released a variety of freeware and paid applications that fill in holes that Palm left behind via his website, PalmPowerups,
www.palmpowerups.com.
PalmPowerups, has two solutions that deal with this problem, one freeware application that just deals with the Blazer problem and one paid application, UnCache for $5.95, dealing with Blazer and most other applications
UnCache
www.palmpowerups.com $5.95
Data flagged as locked in the cache causes fragmentation and limited available cache. Anything locked in cache is locked until the app that locked it unlocks it. UnCache/MemUnfragment keep data from being pre-cached to the DB Cache. Preventing code from loading until needed keeps the cache defragmented and as large as possible. UnCache prevents apps from pre-loading data into this area at soft reset, so it is available for the software you actually use.
MemUnfragment only addresses Blazer problems by blocking the reset alert so that Blazer doesn't know to request that chunk of memory. By the time you launch Blazer after the reset, it is likely that some other app has already used that problematic chunk of memory, meaning Blazer has to find a more reasonable chunk to lock -- also, blazer requests a LOT of DB Cache as well, and so will trigger an OS-based DB Cache flush if it can't get enough
MemUnfragment does only one thing: it keeps Blazer from getting the reset signal. The result is that Blazer doesn't load into the DBCache at reset. If this looks curiously similar to the description of what UnCache does, that's because UnCache is basically MemUnfragment with the ability to turn the reset signal on and off for ALL of your apps, not just Blazer.
Known Side Effects
Both Uncache and Memunframent, prevent clickable links/file associations from working in Blazer for some users.***In the “Can't Have Everything” department, I can't fill in urls in Blazer as I use Grafiti One. Moral of the story, a small price to pay.
***See the Configuration Examples section for setup suggestions..
The Dynamic Heap and UDMH
www.palmpowerups.com $9.95
NVFS Palm devices have 10MB of working memory, Dynamic Heap, used for executable software code. "Not Enough Memory" is almost always due to low Dynamic Heap. When you have more than one app running at the same time, the available heap will become very small. Also, when an app has memory leaks, there can be parts of the heap that are allocated but never released back to the OS.
UDMH lets the working memory steal space from the data memory on devices with limited working memory (heap). UDMH tricks applications into thinking there is more DH by swapping things in and out of NVFS (the palm tx has 101 megs of NVFS out of then box), there by effectively increasing Dynamic Heap.
UMDH is very useful for any apps that require a huge chunk of memory, such as game emulators, TCPMP, video apps and others.UDMH can also clean up after this issue by releasing the memory itself when you quit the app that allocated the memory.
LJP, a game emulator, requests a larger chunk of DB Cache than is available, so the OS performs a flush. However, as I mentioned before, it needs a large chunk of CONTIGUOUS cache, which it sometimes doesn't get even when the total free cache is large enough (due to locked bits of cache). UDMH is essential for applications with demanding memory needs.
***See the Configuration Examples section for setup suggestions..
WarpSpeed $9.95
www.palmpowerups.com
WarpSpeed: silences screen whine. It's really the only app that does this in a safe manner. However, some people have found that they never HEAR screen whine until after they've messed with WarpSpeed. I've found that over/underclocking a device can make screen whine progressively worse; WarpSpeed corrects this by fixing it back to virtually nil. Of course, this is WS's secondary feature. The primary one is to set your processor speed on a per-app basis. On my T|X, I generally have the bus speed and CPU speed turned down, except for programs that require more power, like TCPMP, LJP, Blazer, etc. The end result is that I can use my Palm for 8 hours straight (reading eBooks while listening to music in the background, mostly) on a single charge.
There are two (OK, more, but for this discussion two) clocks inside a Palm device that keep everything synchronized... the Bus clock, and the CPU clock. Think of the Bus as a schoolbus; it transfers the data (schoolkids) between locations in your Palm device. The clock keeps the driver on time. If you speed up his clock, he drives faster so that he stays on time, delivering those kiddies to their various locations quickly and efficiently.
However, if you speed up the clock too much, the bus could break down, or the door could open and close too quickly for any kids to actually make it onto the bus before it leaves the stop Slow it down too much, and you get a huge backlog of kids waiting to get on the bus; eventually, they have to go home before they've even got to school. Not a good thing.
Using this analogy, the CPU (central processing unit) is the school; kids come in, are processed by the school, and leave in an altered state (more educated, hopefully). With a fast bus, a lot of kids can be delivered to the school in a short amount of time; if the school can process the kids fast enough, this increases productivity. Increasing bus speed therefore increases the school/CPU speed.
However, you can set a multiplier -- I'm kind of stuck on how to fit this into the metaphor at the moment, but think of it as multiple classes. If the school has enough teachers and so can increase the school's clock speed (CPU speed) without the teachers burning out teaching so many students, you can have a student delivered by the bus, pushed through 2 classes, and back out to be delivered home in the time that it used to take for them to be delivered, go to one class, and go home again.
Back to the real world.
BUS speed affects ALL the hardware in your Palm. Speeding it up will cause the bus to poll BlueTooth/WiFi/IR/USB/RAM/Card/etc. more frequently, as well as the CPU. The hardware is designed so that the CPU scales up automatically as you increase the bus speed, which gives you your CPU:BUS speed (which is basicly the CPU speed). Adjusting the CPU speed multiplier value allows you to set how many times the CPU cycles for each poll by the system bus.
The long and short of this is: each device has its own maximum and minimum workable values for the BUS and CPU:BUS settings. Going beyond these will cause either the CPU or the bus to lock up, requiring either a reset of the device (if the CPU locks up), or a power off and reset (if the bus locks up). The reason for this last situation is that the reset button is also on the bus, so if the bus stops polling the reset button, pressing it won't do any good. Powering off resets the bus speed to the default, allowing you to press reset again.
Generally, you want the CPU and BUS speeds to be as low as possible for each application you're running. This saves battery power. Some applications require more processing power or they don't work properly -- for instance, TCPMP and LJP run much smoother at 510MHz than at 312MHz.
By "unclock" I presume you mean underclock -- set the clock speeds below their default values. The Treo is a slightly more complex beast to underclock than other Palm devices, as it contains components that require a minimum bus speed to be available at all times so the phone circuitry can operate. Drop below that value, and whenever your phone tries to ring, or some other circuit kicks in, the signal can get blocked at the bus, causing a data jam, and the seizing up you're talking about.
For example, USB 2.0 requires 48MHz to operate and Bluetooth requires 24MHz. If you're saturating the bus (high CPU multiplier, lots of data streaming in from other devices on the chain), the speed will have to be higher to handle traffic from all the hardware.
AdobeReader can be very CPU intensive (bad software: I recommend PalmPDF as a replacement), so if anything, you would want to overclock it a bit to get a speed increase.
One word to the wise: ALWAYS test your device by turning on all the hardware you can and pumping your screen brightness to full -- then slowly increase your bus speed until the device freezes, make a note of the last working speed, then decrease and do the same. Then, do the same thing with the CPU multiplier -- this way, you'll find your max and min values for each, and in the unlikely event that you lock up the bus, having everything turned on to max will cause your battery to drain quickly, after which you can charge for a minute or so and have everything start up again normally. After this, NEVER go beyond those values when adjusting your clock speeds.
Because there is hardware and software running in the background, you will find that the max and min values vary depending on what's running. Turning off hardware or background software (using UnCache) can allow you to go beyond the bounds discovered in the previous paragraph, but stability might still be an issue, especially if things get turned on again while in that danger zone. Likewise, installing new software after finding these boundaries might cause instability that wasn't there before. Surprisingly, some software actually improves things, by interfering with other software, thus freeing up space on the bus/in the cpu.
Back to WarpSpeed itself.
WarpSpeed can set a default System speed, as well as Application speeds and a Current speed.
System settings are the settings that the device will be set to as soon as your Palm boots, and it will keep these settings unless they are changed manually, or by launching an application that has custom settings. When leaving a customized application, the settings will revert to the System settings.
Application settings become active when that application launches, and are changed when the next application launches. If the next application has custom settings, those new settings are used. If it does not have custom settings, the System settings are used.
Current settings are settings changed on the fly, not saved in the WarpSpeed prefs. They stay active until you launch a new application (I think; Dmitry, comment on this if I'm wrong).
You can also set WarpSpeed to save settings across a reset, or turn off on a reset -- useful if you've made the System or Preference settings something that locks up the device -- I recommend having them turn off on reset while you're first finding the limits of your specific device.
I hope this answers most of your questions.
Is there a way to set clock and bus speeds to default TX speeds? I can't remember what the original speed of the TX is.
1. bus=208 cpu=312
I recently purchased UnCache.. Wow, everything is much faster and I'm very pleased! Someone mentioned a way to do like automatic soft reset at a specific hour (like at night, cron+reset app?). I cant seem to find this info again so if anyone could refresh my mind that would be great! Maybe uncache could have the option to perform a soft reset on schedule?
Values that are safe for pretty much all TXes are 194MHz through 520MHz
Best way to run it safely:
If you have a program that needs to be overclocked, go into that program, and start incrementing the CPU and Bus counters one bit at a time until your LD locks up, then step it back one setting. This will be your LD's maximum setting (you might still find it randomly locks up from time to time; drop it down a few more to increase stability). You should be able to have an initial jump up to around 500MHz and then work up from there.
If you want to underclock, turn all your communications protocols on (especially BlueTooth) and then run a bluetooth program; while it is running, start to decrease the numbers from the default. You can probably start by jumping down to somewhere around 200MHz and then going down from there.
Note that Bus speed tends to cause more lock up problems than CPU speed; the final MHz doesn't matter so much for stability as does the amount that you're under/overclocking the bus AND the amount that you're over/underclocking the CPU.
Each Palm is different, which is why WarpSpeed gives you so much control; you need to tune it to what your specific device can handle.
Linear Mode
