External Memory and the Virtual File System
February 16, 2002
Updated September 7, 2002
Newer Palm OS PDAs come with memory expansion slots to store large programs and/or databases outside of RAM. There are five primary types used in Palm OS devices: Memory Stick (MS), Secure Digital (SD), Multimedia Cards (MMC), CompactFlash (CF), and Springboard. The following is a brief discussion of these technologies, and the Virtual File System (VFS) that makes them useful in a handheld.
External Memory Technologies
Memory Stick technology was created by Sony for audio-visual applications like digital cameras. A number of design features that seem non-optimum for PDA use follow from the original purpose. For instance, the PC File Allocation Table (FAT) Virtual File System on a MS uses either 8k or 16K block sizes for the minimum data storage unit. So, if I store a 1K file on a MS, it will take up 16K of space, with 15K of that being ďslackĒ. PCs do the same thing. On a PC, the block size is referred to as cluster size, and depends largely on the size of the disk and the file system. Under FAT32, a 60Gb drive will have 32K clusters. So, why does Sony use 16K blocks or clusters on a mere 64MB or 128MB MS? In a phrase, file system efficiency. The larger the clusters, the fewer entries in the FAT and the faster I can search the FAT for what I need. Since AV files are usually quite large, the tradeoff was highly in favor of larger clusters in that application. While still workable on a PDA, weíd all like to see 1K clusters so the slack space is minimized. In reality, the MS is best used by storing large files on it and keeping the smaller files in RAM or FlashROM. What you don't want to do is keep a large number of very small files on the card, as that will run you out of space very quickly for little gain in available RAM. While this discussion centered on the MS, it holds true for all of the solid-state memory cards.
Technically, a MS is a package that includes flash memory and a controller. The onboard controller allows any flash memory modules to be used so long as it interfaces with the serial protocol. Data is passed through a bi-directional, half-duplex serial interface between the MS and the PDA, using a 10-pin connector. Transfer rates are 1.8 MB/sec. for writing and 2.45 MB/sec. for reading. Not all the pins are used for data transfer, leaving room for expansion to non-memory devices like cameras, GPS, etc. The MS package is 50mm(L)x 21.5mm(W) x 2.8 mm (H). There are also newer types of MS on the market. One is the MS Duo, which is just a smaller MS (20 x 31 x 1.6 mm), and the MagicGate MS which has copy protection capabilities for digital music. Each MagicGate MS has a unique ID, and requires software on the PDA that can decrypt that information if it is copy protected. The largest memory available in MS at this writing is 128MB, but we should see 256MB this fall.
Secure Digital (SD) was jointly developed by Matsushita Electric (Panasonic), Toshiba, and SanDisk. It was designed compliant with the Secure Digital Media Music Initiative (SDMI), which is another form of digital copy protection, and to be more resistant to electrostatic discharge than older technologies. Unlike the MS, SD is an open format and a number of companies make them. As MMC was designed for AA battery powered devices, SD was designed for AAA battery powered devices, and hence draws even less power. Like MS, these cards can do much more than store information. Sporting a 9-pin serial interface, itís theoretical transfer rate is 10MB/second with four data lines, making it theoretically the fastest of its breed. Before you burn your other cards, though, you ought to know that its actual transfer rate in PDAs with one data line is about 2.5 Mb/sec. In practice, it is noticeably faster than an MMC. The SD size comes in at 32mm(L) x 24mm(W) x 2.1mm(H)ónearly identical to the older MMC cards. This, and the fact that seven of the SDís nine pins are the same as the MMC pin-out, is why the two can interchangeably share a single memory slot in newer PDAs. Again, the SDís real purpose and claim to fame is compliance with the SDMI copy protection scheme. Largest memory available at this writing is 128Mb, but 256Mb is rumored to be imminent.
MultiMediaCard (MMC) was jointly developed by Sandisk and Siemens in 1997, and designed for minimum power consumption as required by devices operating on two AA batteries. The original target devices were mobile phones and pagers. It comes in at 32mm(L) x 24mm(W) x 1.4mm(H), sporting a 7-pin serial interface. Sustained transfer rates are about 1.7 Mb/sec reading and 0.4Mb/sec writing. Although MMC supports a variety of protocols, PDAs only support the SPI interface. The largest MMC cards at this writing are 128MB.
CompactFlash (CF) cards were invented by SanDisk in 1994 to store audio/visual information in the new, smaller devices. The Type I cards are the widest and thickest of the external memory cards at 36.4mm(L) x 42.8mm(W) x 3.3mm(H), and have a built-in controller. Type II is even thicker at 5.5mm, but are not generally used for basic memory cards. CF uses a 50-pin interface with sustained transfer rates at about 3.5 Mb/sec, and it is available in huge memory sizesóup to 512MB at this writing. CF can also do much more than memory storage, as evidenced by IBMís 1GB MicroDrive, which fits in a CFII slot. Interestingly, CF cards are PCMCIA compliant as well, even though they only have 50 pins vs. 68 for PCMCIA, with use of a passive adapter in a Type II or III slot. Handera (formerly TRG) is the only Palm OS platform that uses these as far as I know.
Springboard cards were promoted by Handspring for its Visor series of Palm OS PDAs, and are only used on Handspring products as far as I know. They differ from the above in that they don't use a file system API. While they are still flash memory, that memory is mapped into the main memory of the handheld rather than being organized as a file system like other technologies. They are still meant to store read-only programs and databases, so can be considered like an extended FlashROM on a card. Programs on the modules are visible/available to all programs on the device just as if they were in RAM and can be executed directly from the card (i.e., don't need to be copied to RAM to execute), but the program's databases must be in RAM to be modified. In a twist, just as VFS devices must have a special utility (like PiDirect) to use their memory cards as virtual memory, Springboard handhelds must have add-on utilities (like PiVFS) to treat their memory modules as VFS if needed. Remember that Visors only have OS 3.x at best, so don't have native VFS support. The lack of file-system overhead and direct connection to the parallel CPU bus should make Springboard memory faster than serial VFS access on other cards. Springboards can also contain their own (very small) batteries for power. The vast bulk of Springboard modules are not memory cards per se, but stuff like modems, games, network cards, etc. Handspring recently announced that they are dropping their Visor PDA line in favor of its Treo PDA phone line, so the future of Springboard modules is in question at this writing.
Virtual File System
External memory card designers decided to stick with the file management scheme from the PC world. This was both a blessing and a curse. The blessing comes in with the compatibility and flexibility inherent in the FAT system. The curse comes with the same limitations and suboptimal space usage for small files on a large medium. Please read the first paragraph on Memory Sticks above for the details.
Flash memory cards can generally be thought of as electronic floppy disks with an extra limitation. Data on the cards is basically read-only, just like the Flash in your PDA. JackFlash and FlashPro make the Flash accessible for storage, but you canít directly change the databases stored there. The obvious way around that is to copy them into RAM for change, then copy them back to the card when done. This is exactly the way VFS-compliant software like WordSmith 2.1.3 and MiniCalc 4.6 work. In fact, WordSmith throws up informational boxes during the process so you can see what is going on.
The other thing that you generally cannot do is run applications directly from the card. This should make sense, because the analogy to the PC is direct. You donít run programs on the floppy or hard disk either. The OS copies the necessary parts into RAM first, and then executes them. Weíre so used to that, we think of the entire process as a whole as program execution. When the PC OS is done with the program, it releases the memory for other tasks. In PDAs, RAM is a critical resource for most of us, but we need to ensure that we have enough free to execute the largest program we run off of our cards along with its databases.
Starting in Palm OS 4.0, VFS routines were built into the system. The default launcher see the programs on the card in the /Palm/Launcher/ directory, loads apps off the card, executes them, and then deletes them from memory when they are done. The problem is that the OS doesnít know anything about, nor do anything with, the applicationís required databases. If the data is in Random Access Memory (RAM) there is no issue, but if itís on the card, youíre out of luck. Several freeware and shareware programs tackle this problem for us in different ways. PowerRun by YAMADA Tatsushi copies both the application its data into RAM, execute the app, then copy the changed database back to the card and delete the app and database from RAM. For large databases, however, that can be a painfully long process, and they donít work with hacks or programs that contain alarms. It works only with a targeted directory on the card, not multiple directories or the entire card. A big advantage is that applications it controls appear in third-party launchers even if those launchers donít support VFS. As the documentation carefully points out, you need to think about what you want to keep on the card vs. RAM, carefully considering frequency of use and loading times.
PiDirect II by Portable Innovation Technology Ltd and MSMount by Tatsuo Nagamatsu use a fundamentally different approach that both speeds its operation compared to the above programs, but also imposes a potential limitation. They set up a virtual memory scheme where, just as with Windowsí swap file, it tells the OS that the area it controls on the card is really part of RAM. Consequently, they don't necessarily load an entire database in to RAM to gain its use, but only load the section needed by the calling application. So, for instance, in a dictionary program like Noah Lite with the full 5Mb database, when I look up a word PiDirect doesnít load the entire 5Mb dictionary into RAM. It simply loads the parts Noah needs to find my word, which takes a few seconds vs. a minute or more. It will work with applications as well as databases, but apps generally need to be fully loaded into RAM to run. You probably already see the limitation. Although the app or database fragment in RAM is deleted upon program completion, nothing gets copied back to the card. Hence, PiDirect and MSMount only work with applications and read-only databases. Any data you want to change must reside in RAM. Still, the vast improvement in load times for that data over the other approach above make this the ideal approach if you primarily work with very large, read-only databases like dictionaries, technical/medical references, etc. MSMount is freeware, but generally less stable and has less configuration options than PiDirect II. PiDirect II also includes an integral file manager to transfer stuff in/out of its directory.
Third party launchers have also joined the VFS fray. These are generally more efficient than the indigenous launcher at copying files off the memory card. Some like Launcher III put shortcuts in RAM so that programs on the card appear in non-VFS aware applications. Both MegaLauncher and Launcher III have the built-in ability to copy or move files to/from the card. Iím sure that in time, such third-party launchers will also do the job of PowerRun. Youíd think that the OS would already do that, but I digress.
Memroy Cards and Hotsync Conduits
This section was graciously contributed by Bryan Nystrom, Chief Technical Officer for Natara Software, Inc.:
"Additional information or warnings for your page:
Applications which are moved to external storage cards
that have associated conduits will no longer have their
conduits run during a HotSync operation. This is because
HSM first scans all the applications (their creator IDs,
actually) in RAM and FLASH ROM to determine if an
associated conduit should be kicked off. Since HotSync
doesn't bother to look on external cards, the applications
are not seen, and HSM doesn't think it needs to run the
conduit since it doesn't think that there is an associated
app. In our case (Natara Software), copying DayNotez to a
memory card means that the DayNotez conduit will not be
run during a HotSync since HotSync manager doesn't see the
app on the main device anymore.
"Of course, there are some exceptions to this. First, HandEra devices have a modified HotSync app on them which DOES scan external cards. Second, moving an app such as DateBk5 to a memory card doesn't mean that the calendar will not be hotsynced. This is due to the fact that DateBk5 is a replacement for an app in ROM/FLASH, and the creator ID for the datebook conduit is still seen in the main memory of the device. And third, some 3rd party apps have gone to lengths to create very small "stub" applications which can remain in main memory and take up little of the RAM space and proxy in for the main application living "off line". These stubs generally are "do nothing" pieces of code which are setup with the same creator ID as the conduit is looking for."
I present the way Iíve elected to approach expansion memory and VFS, not because Iím an expert (Iím not), but just to illustrate one approach to the situation. I bought the biggest MS I could getó128Mbóbecause you can never have enough storage. I have only one MS that always sits in my CLIE, and I think of it as my solid state hard drive. I use MegaLauncher and keep all my applications that are on the MS in the /Palm/Launcher/ directory for access by ML, which does a nice job of loading them quickly. I keep all my large read-only databases in the PiDirect directory and access them through its virtual file system, even if their native apps are VFS-aware. They load much faster this way. All my editable databases remain in RAM. I donít keep any large programs on the card because of the long load times, but keep all my large databases there to make efficient use of the file structure. I also use BackupBuddyVFS to keep an up-to-date backup of my entire RAM on the card, running incremental updates every night.
The FlashROM Wildcard
The old standby for memory augmentation is the unused FlashROM (or just flash) where the OS is stored. Programs like JackFlash by Brayder Technologies format the unused flash and make it available to store programs and read-only databases. The amount freeable for that purpose varies with the PDA and OS version, but can be up to 1.4Mb+ in OS 4.1. Not every PDA uses FlashROM, so see my primary Palm OS page for an incomplete list. FlashPro only supports Palm Computing devices, and according to Handera thatís about all it will ever supportóno Sonys, etc. Brayder has taken a more inclusive approach and supports most everything, including the newest devices as they are marketed. These programs are well worth the registration fee to gain the extra storage space. The biggest advantage that the flash has over an external card is access speed. The flash speed is virtually indistinguishable from RAM, while the card is anything but.
I wrote this partly as a learning exercise for myself. There are so many issues now in PDAs that were just a dream even a few years ago. Itís just flat hard to keep up. I hope that some will find all this useful. If anyone finds an error, please let me know from here. I know that I left the SmartCard out of the discussion, but thatís because it has no Palm OS application at this time. So, enjoy the computing power in your hand/pocket. I do!