By Sam Denton (sam.denton@maryville.com)
Copyright 1999, Sam Denton
FlashPack is an add-on application to TRG's FlashPro product that allows you to schedule automatic back-ups to flash memory of the essential databases contained in your Palm Organizer. In the event of a hard reset, battery emergency, or any other disaster that would otherwise leave you with an empty Palm Organizer, FlashPack will help ensure that the data you need is preserved. Back-ups may be scheduled either daily or weekly, and any or all of the databases associated with the seven built-in applications will be backed up.
You can install FlashPack via the Install Tool or equivalent software. You must have TRG's FlashPro installed for FlashPack to function correctly. For more information on FlashPro, visit TRG's web site (http://www.trgnet.com/cat-flashpro.htm).
There is never any need to delete older versions of FlashPack before installing a new version. If you decide to back-migrate, however, it is best to delete the current version prior to installing an older one. Those versions that support automatic update of the flash copy of FlashRestore will always strive to keep that copy matching the RAM version.
NOTE: Versions of FlashPro prior to 1.02 had a bug in the API that can cause a crash in some versions of PalmOS 3.0. Having a newer unit apparently fixes the problem. If you encounter this problem, contact TRG for the latest version of FlashPro.
Version 1.03 of FlashPro (available as of May, 1999) includes the following improvements:
The first item is required by anyone HotSync'ing to a Macintosh. The last item will allow FlashPack to avoid getting 0x0206 errors when trying to backup databases whose application is currently running.
Version 1.04 of FlashPro (available as of May, 1999) includes the following improvements:
Version 1.04a of FlashPro (available by special request) includes the following improvement:
To use FlashPack, first select which databases you wish to have backed-up to Flash memory. You can back them up immediately by selecting the "Backup Now" item from the menu.
FlashPack creates a backup of itself in Flash memory called FlashRestore. Aside from the difference in names, there is no difference between the two programs; however, only programs residing in RAM can write to flash memory. For this reason, FlashPack presents a different screen when it is executed from flash memory.
To schedule periodic automatic back-ups, use the menu to access "Preferences".
If a "Hard Reset" occurs, you will hear an alarm beep while the PalmOS initial screen is being displayed. This lets you know that FlashRestore has survived the reset. You should now run FlashRestore and let it recover the databases that have been backed up. The most recent copies of all backed up databases are restored.
Hint: While the AMD Flash memory chips are rated to last for 10,000 write operations, modifying Flash frequently will really drain your batteries. I normally keep a weekly backup cycle, and only change to daily when I'm on a trip or otherwise unable to perform daily HotSyncs. And whenever I enter a lot of data that I would really hate to lose, I run FlashPack and select the "Backup Now" menu item.
In the upper section of the screen, you will see a list of databases titled "What to back up". The databases are "DatebookDB", "AddressDB", "ToDoDB", "MemoDB", "MailDB", "ExpenseDB" and "NetworkDB". A check mark indicates which ones will be backed-up.
FlashPack has the following menus.
To schedule periodic automatic back-ups, click on either the "Daily" or "Weekly" buttons at the bottom of the screen. Choosing "Daily" will schedule a back-up every day at the indicated time. Choosing "Weekly" will schedule a back-up within the next 24 hours and then every 7 days thereafter.
Whenever data is moved between RAM and flash, a progress screen is displayed. The upper section describes what is being done, while the lower section shows a tracking bar.
In the upper section of the screen, you will see a list of databases titled "What to restore". The databases are "DatebookDB", "AddressDB", "ToDoDB", "MemoDB", "MailDB", "ExpenseDB" and "NetworkDB". Only databases for which backups exist will be listed. If you do not wish to restore certain databases, you may uncheck them here.
In the lower section of the screen, you will see a button labeled "Restore". Tap this button to restore all checked databases.
FlashRestore has the following menus.
FlashPack should be compatible with all Palm Organizers that support TRG's FlashPro. This includes the following:
NOTE: FlashPro (and therefore FlashPack) is not compatible with the Synapse™ Pager Card from PageMart. The Pager Card uses an INTEL flash part that is not program compatible with the AMD flash part used on TRG's and 3Com's memory boards.
NOTE: FlashPro works on the Symbol as long as you never run the Symbol flash utility. TRG learned this when talking to some Palm engineers, after "porting" FlashPro to the Symbol (there is a low-level memory manager difference TRG had to work around). The Symbol Flash Utility (or some versions of it, anyway) has a bug that may corrupt flash if used in conjunction with FlashPro. In the worst case, this will prevent the device from booting and require the OS to be re-flashed. Even if it appears to work, there may be other strange side effects of using the programs together.
Other than the above exceptions, please let me know if FlashPack doesn't work on your Palm Organizer.
FlashPro is supposed to keep an eye on the voltage levels and abort if they drop too low, which in turn causes FlashPack to pop-up a message explaining the problem and cancel the rest of the back-ups. Once in a blue moon, though, the voltages seem to drop faster than expected, and FlashPro writes garbage to flash memory before everything crashes. I will be changing FlashPack to watch the voltages. If this does happen, however, it is my understading that the "right" thing to do is to first put in fresh batteries and then perform the TRG reset sequence (reset+memopad). This should erase both flash and RAM.
Unfortunately, this will cost you both the flash and RAM copies of your DB. Until I get the battery watch implemented, I strongly urge you to use new batteries before leaving town.
Mea Culpa! I assumed that FlashPro would tell me if there were a problem, but instead it apparently just hangs. Adding a check for this is now a top priority.
Update! This should now be fixed, but there may be marginal cases. Let me know if this continues to happen.
Individual file copies should take about the same amount of time in FlashPack as in FlashPro. Multiple file copies, however, will take longer in FlashPack. This is due to the fact that the API can only process a single file at a time. When FlashPro moves a group of files, it uses RAM buffering and only flushes to flash when it has to. FlashPack, using the API, must flush the buffers after every file. This accounts for the slower performance.
Here is the semi-official word from TRG:
The thing to watch out for is moving an enabled Hack into Flash (or from Flash to RAM). If the hack gains control of the processor during the move, it is likely to crash the Palm, leaving the flash or RAM database system in an invalid state.
You also don't want to defrag with enabled hacks in flash.
FlashPack neither moves Hacks in and out of Flash nor performs defragmentation, so you should be safe.
Older versions of FlashPro set the backup bit of the copy of any DB copied to flash. This did not bother the Windows version of the HotSync program, but it caused the Macintosh version to crash and could have played havoc with other synchronization software. Starting with version 1.03, FlashPro insures that the backup bit of files in flash are cleared. The backup bit of the RAM copy was and still is left unchanged.
When FlashPro copies a DB to flash, it exactly copies the three timestamps as well. FlashBack checks the modification timestamp of the RAM copy and the flash copy prior to performing the back-up to flash. If the two times are identical, the flash copy is left as is. Under normal circumstances, the modification timestamp is set whenever a change is made to a DB, so this will catch changes to the DB and make sure that they are backed up. The modification timestamp is also set whenever a HotSync is performed, so FlashPack will sometimes make a back-up when one isn't really needed. This will only be an issue if a DB isn't modified for a prolonged period and HotSyncs are being done at least as often as FlashPack schedules back-ups. It is possible to set the modification timestamp of a DB under program control, which could cause FlashPack to miss a back-up, but I assume that anyone doing such a thing has a good reason. I know of no other programs that set any of the three timestamps.
If you get this message with FlashPro 1.04 or earlier, please contact TRG for version 1.04a or later before contacting me. Older versions of FlashPro returns this error code if there isn't enough contiguous free flash to complete the operation. If you think you have enough free flash, try running the defragmentation utility in FlashPro and see if that helps.
Fixed in FlashPro 1.04.
FlashPack has some funky ideas about what Weekly means. Everytime you change the back-up time, a backup is scheduled for the next occurance of the trigger time. Only then does the "Weekly" setting take effect. (Older versions of FlashPack did this when any change was made, not just the time settings.) Also, changing to "Never" will still cause one more backup to occur. This is because doing it "better" would require complicated programing, and I've had a lot of other things to work on instead. But, since someone has complained, I'll try to do better in the next release.
The current version of FlashPack is free. As improvements are made, a registration process may be implemented.
This software is provided without warranty. I will not take responsibility for any form of damage or loss that occurs when/by using this software.
One of the reasons why FlashPack is free is so I don't have to feel guilty about ignoring some really fine ideas indefinitly. Sometimes it takes me weeks just to get around to fixing some pretty critical problems.
This software can be distributed freely as long as all files remain intact and unchanged. Please let me know if it will be included in printed matter, floppy or CD-ROM before its publication.
It was a deliberate decision to not save and restore the "Saved Preferences". This ensures that when you do a HotSync, the conduits know that you've experienced a hard reset and react accordingly.
Older versions of FlashPro didn't tell FlashPack when the amount of Flash memory is too small to hold a DB, so you need to check for yourself. Here's how:
If you find other problems, please let me know.
I'm considering the following functions:
Right now, FlashPack pretty much ignores the internal structure of the DBs that it backs up. This is good in that it simplifies FlashPack considerably, but it does preclude other interesting ideas, such as incremental back-ups and data compression. For that reason, both of those are on my long term goal list.
If you have any other suggestions, please let me know.
I look forward to hearing from you. Please visit my web page or email me.
Thank you.