Getting data into the Palm IIIxe is a challenge. First of all, it doesn’t have Wifi. Secondly, it uses its own data format *.PDB to store data. Which means not only do I have to find a way to sync the data over the serial port, I also have to be able to convert the data that I currently have into the compatible format.

As mentioned before in the previous post, pilot-xfer is my friend. It can help me sync data in a few ways into the Palm. Serial or network. Thank goodness that Palm at least had the sense to include Network syncing, but the pilot-link suite of tools is the one that made it possible to redirect a serial port to a network-ed system running a HotSync capable machine.

Once I had this setup, getting files in and out of my Palm was possible. Not easy, but definitely possible. As shared before, the productivity utilities that I use daily are as follows.

• iCal -> Datebk
• Contacts -> Addressbook
• ToDo -> Things3.0
• Memo -> Evernote

This means that somehow, I have to convert the data from these systems into the respective PDB files that can be understood by the Palm built-in apps. I started off with iCal and Contacts as these have standard formats that we can convert into and thus transform into records that can then be written out into PDB. I’m familiar with PERL, so I started hunting for PERL packages that would handle Palm PDB files. Exporting from iCal and Contacts on Mac is easy, so there isn’t much to worry about there.

Handling ICS to Datebk PDB conversion

The PERL package I used falls under the PALM package and the ICS file parse I used is iCal::Parser. A few key things to note. What PALM can support is definitely simpler compared to what iCal can handle. So it is very important to NOT lose any data during the transformation. Therefore, all un-mappable information would go into the NOTES field in the PalmPilot. Its also important to know that the iCal Parser that I am using handles all the conversion of ICS entries into parsable calendar objects. This makes it much easier for me to be able to not worry about things like repeated events etc and just focus on the mapping. This isn’t a coding tutorial, so I wouldn’t be providing code to show how I got it done. But ultimately, I made some decisions about how things should show up on Datebk, manipulated the strings (PERL is good for things like that), provide by the parser, and wrote it out into a PDB.

Needless to say, it took a while for me to settle on exactly how I would like the data to show up and the abbreviations I would use, but the end result, I think, is pretty concise and usable. The screen, being only 160×160 also mean I had to choose carefully what I wanted to show. It really drives home the need to only show exactly what is required and important, and how far technology has come.

Once the PDB file has been constructed, the next thing was to be able to move the file seamlessly to the networked HotSync machine for syncing. Making use of Dropbox to do this was no a no brainer. I previously had some Linux code that I wrote to be able to sync files, so I effectively just re-used those. I could have just used rclone to do the same. The flow below shows how the PDB file would move from the moment it has been constructed. As the files are very small, the cloud sync only really takes a moment.

Once the file is on the HotSync system, pilot-xfer and pilot-nredir does the rest.

Tada! 🙂
I now have my iCal available on my Palm.

Final bits on the conversion

Putting on the finish touches on this conversion process just requires me to now be able to automatically export the iCal entries using Apple Script, for all my calendars into a file, so that parsing script can then take over the conversion. It was at this point that I ran into some slight issues. I realised that I didn’t want to have my Mac handling the ICS file export and then running the conversion. This is largely because I didn’t want to have to re-install all those linux tools every time I change or upgrade my Mac. I wanted the tools to be on an OS whose tools are generally available as part of the system. I also wanted to ensure that all the other tools I ended up creating could follow the same structure. So I tweaked the process just a little bit….

At the end of this, I could export any parsable file into a target folder in DropBox, and it will be MD5 checked for any changes. Once a change is detected, it would then automatically (re)create an updated PDB file which would be placed in a HotSync folder. Connecting my Palm to the RaspberryPi, which has pilot-nredir always running in a while loop, would then automatically sync, install the latest PDB file into it.

Issues?

Not much… everything I have seems to translate pretty well into text. The one thing that I have to remember that this sync is ONE-WAY. It gets iCal stuff into the Palm, but not any changes in Palm back into iCal. This means that I can’t create, edit, delete entries on the Palm and expect it to carry across to my iCal.

HOWEVER, I find that short-coming ok. I use my iPhone to keep track of my calendars anyway. The Palm is really just a way for me to not have to whip out my phone just to check a calendar entry if I’m playing games on it.

At some point in the future, I might have to re-design the entire process if I want to be able to do a 2-way sync, but it might not be worth the trouble.

See Part 1