darkness

Been a while.

I got a new Palm Tungsten C when I broke the screen on my venerable Palm Vx. It was out of warranty, and was going to be $100 to fix it. My company was kind enough to pick up the bill for a new PDA. Summary of the Tungsten C: keyboard, no graffiti area, Palm OS 5.2.1 (I think), Graffiti 2 (different from original graffiti — and I’m not sure experienced Graffiti users will like it), built-in 802.11b, 320×320 “trans-reflective TFT” color screen, 400MHz XScale (model 255 I think? Not 250 which is supposedly very buggy), built-in SD slot, no CF2 unfortunately. Overall I’m quite pleased. HotSyncing via wireless is nice when you want to install a bunch of software. I was unhappy that it didn’t have a CF2 slot, but felt somewhat better when I learned of SDIO, which allows using SD slots for more than just storage.

(I’m about to talk about Palm development. WARNING: I learned most of this piecemeal from other stuff posted around the Internet. I’ve so far compiled only a hello world program. I’m far from an expert. All of this is liable to be wrong. I have yet to actually fuck up my system. Don’t do much or any of what’s below as root would be my recommendation. I installed everything to a directory under my home directory, as a normal user.)

I decided that I might want to play with some Palm development. For example, it would be nice if TGSSH would allow me to move the cursor around in the input area with the four-way control on the Tungsten C. The vast majority of Palm development looks like it’s done in C or C++. I’m not a big C++ fan, though maybe I should brush up on it if only for the added marketability it would lend me. Anyway, I started with prc-tools. I wanted to develop ARM applications, and found they had ARM tools available for download. Alas, it looked like they were GCC 2.95 based and not the bleeding edge! So I decided to build prc-tools. (I actually started with an ARM-ELF-GCC HOWTO, but later learned that I’d need prc-tools for build-prc anyway.)

I downloaded the 2.2 sources from their SF project, but found no GCC 3.x patch, and found the other patches to be out of date as well. I then checked out the latest from CVS and found the patches for GCC 3.2.2, GDB 5.3, etc. I couldn’t get the damn thing to build on RH8, though. I suspect it might have been a matter of needing to re-run autoconf somewhere, probably in prc-tools, and making sure to run autoconf 2.13 and not 2.53. When you run autoconf in RH8 (and probably newer releases as well) you get autoconf 2.53. I tried this order of things, in general:

1. Download and unpack GCC 3.2.2, GCC 2.95.x (needed for m68k), binutils latest, GDB 5.3 (I think; latest release), and prc-tools from CVS.

2. Apply all four of the patches from prc-tools: one for each version of GCC, one for GDB, and one for binutils. The GCC 3.2.2 one applied to GCC 3.2.3 except for problems modifying gcc/version.c (IIRC). Ignore it or edit by hand (see the .rej file) if you really care.

3. Apparently it is recommended that tools like GCC, GDB, and binutils be built in a directory separate from their source. Whatever kids. You need to build and install, in order: binutils, GCC 3.2.3, GCC 2.95.x., and GDB. (Honestly, GDB is kind of optional in all this.) This “building in a directory separate from their source” is accomplished (using binutils for example) like mkdir binutils-obj; cd binutils-obj; /path/to/binutils/source/configure --target m68k-palmos; make all; make install. Note the --target that tells it you’ll be building tools to run on your current platform, but to work with binaries and such from another platform, m68k-palmos in the example. You need to repeat this process for each package with both m68k-palmos and arm-palmos, except for GDB which apparently supports only m68k-palmos. I did an rm -rf in my build directory after I did make install. Also note that both GCC configure scripts will require an --enable-languages=c,c++ kind of parameter. I used only c for mine. You’ll end up with nice stuff like m68k-palmos-gcc and arm-palmos-gcc.

4. In the prc-tools source directory, make a symbolic link named binutils pointing to your binutils source directory.

5. prc-tools, like the other packages we’ve built, supposedly likes to be built in a directory separate from its source. So along the same lines as above: mkdir prc-tools-obj; cd prc-tools-obj; /path/to/prc-tools/source/configure --target m68k-palmos; make all; make install. I suspect prc-tools will rebuild binutils, but it seems to be very unhappy if it is not allowed to do so.

6. Go grab a Palm OS SDK. The link given is probably for an OS 5 SDK only.

7. Run palmdev-prep. The prc-tools documentation might be of use here.

Based on a hello world for Palm OS out on the Interwebernet, I came up with:

// Include Palm prototypes, variables etc.
#include <PalmOS.h>

// Entry point for palm applications
UInt32 PilotMain (UInt16 cmd, void *cmdPBP, UInt16 launchFlags) {
  // Variable declarations
  EventType event;

  // Check the launch code
  if (cmd == sysAppLaunchCmdNormalLaunch) {

    // Write hello world to the screen
    WinDrawChars("Hello world!", 12, 20, 50);

    do {
      // Wait until something happens
      EvtGetEvent(&event, evtWaitForever);

      // Let the system handle the event
      SysHandleEvent(&event);

    // Quit if we have received an appStopEvent
    } while (event.eType != appStopEvent);
  } // cmd == sysAppLaunchCmdNormalLaunch
  return;
} // PilotMain

It works. I’m impressed.

One more little point of interest. OS 5 devices are all ARM AFAIK. They have this m68k emulation layer apparently, so they can take advantage of the plethora of pre-ARM applications available for Palm OS. That’s all well and good, but since I figured I was developing just for myself for now I might as well make ARM programs instead. Apparently this is not really supported. I have no crt0.o for arm-palmos. Apparently you normally just put in “ARMlets” for the performance-critical portions of an application. You do this, apparently, by compiling the ARM code separately, then including the resulting binary as a “code resource” in a Palm OS application. I suspect you could make what is basically an entirely ARM application by making a tiny m68k bootstrap that basically calls into the ARM code first thing. I’m no expert, though.

On other notes, since I’m keeping my personal configuration files in CVS these days, I also hacked up a shell script to install them. (Thanks again, Andy, for the help.) Then I put my .emacs into CVS. Now I’m running Emacs on my new RH9 box. I don’t think the machine is as fast as my Powerbook, but entirely usable. It’s not bad to have a full keyboard sometimes too. So I’m writing this entry from my RH9 box as well.

Only problem I encountered during the whole ordeal was adding a fucking item to my main menu (the thing that looks suspiciously like a start menu in Gnome — but isn’t, really!) to run emacs -f server-start --iconic. Turns out you have to follow some instructions for allowing users to add menu items in RH9. Silliness! killall gnome-panel rather than logging out and back in worked quite nicely.

Silliness!