Fargo Heap Resizer
(C) 2005 Frantisek Dufka
version 0.14, 2005-10-9
- initial release, works for T and T2
version 0.15, 2005-10-28
- suport for Zire71 (1MB original, 1.96MB extended)
- can be enabled automatically on soft reset
- size on start/end labels is computed from real values
- scrollbar addded
- text field is now editable to allow clipboard operations on OS >5.4 devices.
This program enlarges dynamic heap on Tungsten T and T2 devices from
800KB up to 1.8 MB and since 0.15 also on Zire71 from 1MB to 1.96MB. Memory for new heap is taken from storage memory.
Unlike with other heap extending solutions this should be safe and
transparent for all applications. Original storage memory protection is
untouched and only memory used for new heap is made writable. Also no
OS function is patched. In theory this is bullet-proof.
- So far works only on T|T, T2 and Zire71
- Not unlimited at all, 1.8MB is maximum for T and T2, 1.96MB for Zire71. This is of
course not enough for running Doom but enough to play music
on background while doing something useful or for playing some game
that need a bit more heap memory than available (Legacy) or to see
bigger pages in your web browser.
- As the heap is resized on the fly and already allocated and locked
memory cannot be moved, new space is added in one or two separate
memory chunks. This means that the free space is not continuous.
Typically after program is run on T or T2 you end with 3 free blocks -
800kb,600kb and 200kb. This may cause some programs that need
big chunks of continuous memory (e.g. one 1MB block) to fail even if
there is enough free memory. You can use included
ShowMemDA to see free space and largest continuous block.
Execute the program as soon as possible after soft reset.
Check at least one checkbox and press 'Resize heap now' button. You can
use 'System info' for more details before or after resizing operation.
Change is permanent until next soft reset. After performing soft reset
original memory layout is automatically restored and allocated storage
memory is freed by operating system (unless it is enabled automatically on each reset).
If it works fine, you can set it to extend heap automatically on each reset.
If you have problems later, use no-notify reset (hold page up and reset your device) to prevent it from starting.
Included ShowMemDA is my Desk Accessory to show free memory and largest
free block. Use DA launcher and choose Memory Info to get current
This program is free for personal use. I wrote it to solve my problem
with Legacy game by Redshift and just shared it for other
users. However, it took me some time and required pretty advanced skills.
If it works for you and brings new life to your device, you can send me a
$5 is a good choice like anything below or above this :) You can also use https://www.moneybookers.com if you don't use Paypal.
Program works by mapping allocated block of storage memory above and
below original dynamic heap space via MMU unit of the CPU and then
tries to resize heap memory structures to
accomodate new memory space. To describe it in simple words - the
memory is cut from storage area and pasted around original dynamic heap.
There is only 800KB of unused address space below original heap
beginning and 200KB after heap end on T and T2 so unless storage ram
space is moved (which probably needs nontrivial ROM modification) 1.8MB
is the maximum. Maybe I can get additional 200kb by moving the LCD
framebuffer. On Zire71 there is space only below orginal heap.
Program is device specific but can be modified for other OS5 devices
with low dynamic memory. Maximum size depends on memory layout of
No OS system function is patched and only specific allocated block of
storage space is made writable in new memory mapping. In theory this
means no data corruption
is possible. New heap should be as safe as original unextended heap
[*]. If device does not hang or reset itself on heap extension
operation all the magic is done and it should just work.
New memory is automatically available to all programs and operating
[*] On T2 this is not entirely true if heap is resized on heap end.
There is SD/MMC buffer for reading from card directly after heap end.
This buffer needs to be skipped and prevented from being used as free
memory. Two solutions are used for this:
1. shortening last allocated block on heap end by 4 bytes to have space
for chunk header that marks SD buffer as nonmovable allocated memory.
2. Last allocated block is extended to include SD buffer.
Both solutions are a bit dangerous. First can cause heap corruption and
soft reset if those 4 bytes are really used and overwritten but
advantage is that the SD
buffer is never freed. Second solution can make the buffer free if last
block is ever freed but leaves the last block data alone. In fact both
solution seem to work fine as those
4 bytes seem to be not used and last block is never freed too.
Currently method 1 is hardcoded as it causes immediate soft reset in
case of problems which
is better than corrupting data on your SD card silently by
overwriting the SD
buffer. If you care about extra safety you can uncheck heap end
on T2. I have it enabled for months on my T2 without any ill effects
but of course YMMV. On T|T there is no such buffer so it is safe and
T|T owners get
additional 4KB of space on heap end.
Igor Nesterov for YAHM dev kit and tip about HALMemoryRegions
Greg Parker for Peal
mobile-stream.com for their unofficial SDK, I found most things before
it was released but the SDK was still big help.
Michal Hrusecky for countless tests and resets on his T|T
- fix linked master pointer tables in original dynamic heap (trivial,
not needed if FHR is executed relatively soon after soft reset)
See About dialog in menu.
Q: Why Fargo?
A: Fargo 1 and 2 are internal codenames for T and T2, see
As I added support for Zire71 in 0.15 the name is a bit misleading now. I should probably stop adding new devices or think about better name.
Q: Will you add support for my device?
A: Maybe, if it is easy. Do as it says, press 'system info' and
send me output. Use stylus to select text and copy it to clipboard via
command bar. If it crashes completely then it may be hard to add
support for you device.
UPDATE: I have received many reports for various devices. Most devices made by Palm cannot be extended since dynamic and storage heap is located next to each other. The only devices that could be extended without limits are Treo650 and Tapwave Zodiac. However it is currently not implemented due to lack of time and low motivation. Also Tungsten E can be extended by 900Kb but there seems to be similar problem with SD card like on T2. Unfortunately it is impossible for me to figure out details and find a workaround without having the device in hand.
Q: What is the limit for my device?
A: Depends on memory layout. There needs to be unused virtual address
space around original heap so there is space to grow the heap. If palm
engineers wisely decided to put heap and other memory regions next to
each other, nothing can be done.
Q: What is the difference between UDMH and FHR?
A: They are designed differently and they work differently. UDMH
patches Memory Manager system calls to simulate dynamic heap in
storage memory. Every allocation request for dynamic heap is rerouted
to storage heap and a lot of magic is done to keep it working. Storage
and dynamic heap data are mixed together which means that your storage
data are not safe because they can be overwritten by bad software (This
is just an educated guess, I haven't seen UDMH sources as it is paid).
FHR really resizes original dynamic heap and leaves the rest
to PalmOS, no system call is patched and in theory no additional data
can be overwritten. The price for safety and stability is that FHR is
limited by memory layout of the device and it is static - i.e
dynamic heap cannot grow and shrink on demand like with UDMH. The only
way to release memory taken by FHR is soft reset.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.