I am a huge fan of the classic Palm OS. Yes, webOS was pretty cool, while it lasted (there's a Pre 2 on my shelf courtesy of the funkatronic Ed Finkler that I barely got to explore before HP killed the Palm line), but the original Palm OS was not unlike what you'd get if you miniaturized the classic Mac OS into a handheld form factor. Under the hood, you had very similar system designs and implementations, and Macs were well supported as development tools. Heck, they were even 68K systems, like the original Macs, and the switch to the ARM-based Palm devices was eerily similar to the Power Macintosh transition. The ARM Palm OS even had its own 68K emulator -- in fact, the normal state of the system was to be running 68K code!
Myself I started with a Palm m505 which I bought in medical school (new shortly after its introduction, a substantial expense to a starving student) for calculations and drug databases, at which it excelled. I also rapidly learned how to program it, using a remarkable port of the Lua programming language called Plua, and when I upgraded to a ARM-based Zire 72 everything easily transferred over to the new unit which is a testament to how well the sync and OS were designed. Both of these units still work, by the way, even though the m505's battery is shot and won't hold a charge anymore. Even after I got an original iPhone in 2007 I still used the Zire 72 for a number of years because it had better pharmacy apps and it could record video (the iPhone couldn't do this until the 3GS).
Parenthetically, however, if I were forced to pick the best Palm OS device ever made I would actually make a non-Palm selection: the AlphaSmart Dana wireless. If you'd ever wondered what a PalmOS laptop would wind up like, that's pretty much what the Dana is, with a wide 560x160 backlit greyscale LCD, a full and luxurious keyboard, two, count 'em, two SD/SDIO slots, up to 16MB of memory, built-in WEP 802.11b, an integrated USB cradle and even a USB port for a printer. It runs on rechargeable batteries (easily replaceable) or even AAs; mine has a nearly new rechargeable battery pack, a 1GB SD card (maximum supported) in one slot and a Palm Bluetooth SDIO card in the other. The keyboard is incredibly good. There are writers who cling to these things even now because they run for ages on a single charge, the built-in editor is quick and distraction-free, and when you've got your stuff typed, you simply plug it into your Mac or PC and "squirt" it into your word processor of choice: it emulates a USB keyboard! To this day my mother uses one for her notes at church because it runs longer than many laptops, it's light and durable, and when she comes home she can merely plug it into her Mac mini and dump everything into Microsoft Word. Its chief flaw -- and this is a big one -- is that the 33MHz Dragonball VZ CPU is an absolute slug. While it's more than adequate for its avowed purpose and very thrifty with power, heavy duty apps just drag on it even if you install an overclocker.
The biggest, baddest Palm of them all is of course the T|X ("TX"), with a 312MHz Intel PXA270 ARM CPU, 32MB of RAM, 128MB of flash memory (remember that earlier Palms kept everything in RAM, so battery failure was catastrophic), built-in Bluetooth and WiFi and a beautiful 320x480 (320x448 effective resolution) colour LCD screen. Although the earlier Tungsten T5 had 256MB of Flash and a 416MHz CPU, it was cursed by God with system bugs that updates did not completely fix, bad memory management, sluggish Bluetooth and no Wi-Fi. The TX can easily be overclocked to 520MHz (don't exceed this, though, or you'll have a nice doorstop for a day or two while the battery discharges!), it can take additional SD card space (there's even a third-party SDHC driver), and it has more advanced networking, an updated OS and an updated version of the Blazer web browser. By the way, hats off to Dmitry Grinberg for making both of those tools free. That's classy.
But I still like my Zire 72 (in the 72s form factor with the more durable silver paint job) better than my T|X for four reasons: first, the camera, which is pretty dire by today's standards but is still very handy; second, the extra side button (more on that in a moment); third, mini-USB is much easier to work with than that stupid Athena connector on the T5 and TX (though you can charge over USB with the Athena); and last but not least, the replaceable battery. The T|X battery is soldered in -- if you need to hard-power-cycle it, you'll either have to wait it out or cut the leads, and you'll need to get out your soldering iron to put in a new one. The Zire's battery can be (carefully) removed and replaced, however, greatly expanding its longevity. While it won't surf the web anywhere near as well as the T|X, no one's realistically using their Palm for that anymore, you can put nice big SD cards in it as well (and overclock it too because the Zire 72 uses exactly the same CPU as the TX, and the same 32MB of RAM, though no flash memory), and it has built-in Bluetooth also. If you really need WiFi, the palmOne 802.11b SDIO card will work, and the 320x320 screen is pretty decent. Right now, my Zire 72, Dana wireless and TX are all out in the commons area with their own charging stations and they each have their own little tasks they specialize in.
Which brings me to the point of this blog post. I am also a big fan of the Philips hue light system, which uses controllable colour LED bulbs for automated illumination. You can run it from a smartphone, but I centrally control mine on the secured internal network using huepl, a command-line tool I wrote for this purpose. (It works on 10.4, of course.) I have two hue base stations set up, one in my office, and one shown here out in the commons.
Last time Mom was over, Dad and I were working outside early while she slept in my guest room. She got up and found out she couldn't turn the lights on because she didn't have a device to talk to the central server. Never leave your mother in the dark. Ever. So for their next visit I decided I need to make a guest light controller.
While Philips makes a wall switch (interestingly using the kinetic energy of pressing its buttons to send a signal to the hue base station), a custom wireless solution would be more optimal and more flexible. However, I don't allow Wi-Fi on my secured internal network because I don't want someone sneaking into it one day -- it's a secured network for a reason to protect all these lovely old machines, not to mention my financial records. There's a shorter range way of getting into a network though:
Yep, that's a Bluetooth access point. Although theoretically another Class 1 device could try to talk to it from outside the house (if they figured out the pairing code), in practice it's going to be limited by most transceivers being substantially lower power. But more importantly, this specific access point, the Belkin F8T030, is particularly useful in this situation because with its default firmware it only offers the older Bluetooth LAN Access Profile, not the Personal Area Network (Bluetooth PAN) profile currently supported by 10.4+ and most current mobile devices. My Android phones and Macintoshes can only see the Belkin if they're right on top of it, and even then, even with the correct pairing code, they can't do anything with it or connect to the internal network through it. Only the Palm OS devices can -- because they speak Bluetooth LAP, not PAN.
You can flash the F8T030 to speak PAN as well, but I actually don't want that, in this application. By the way, the F8T030 runs uCLinux -- you can even telnet into it and get a shell prompt!
So that solves the connectivity end; now I have to get the Palm to talk to the lights. In this case I selected the Zire 72 as the light controller because I have a couple of them as spares lying around and as mentioned I can repair them to some extent. First thing was to configure it and pair it with the Bluetooth access point, which was pretty simple in PalmOS 5. However, rather than teaching the Palm how to speak the hue base station REST API (because I'd have to give it keys and keep those current), I decided to create a couple scripts on the internal interface of the web server and use EudoraWeb to control the lights through those scripts, like so:
This worked, but you can rapidly see some disadvantages. First, there's not a lot of room left to add more options without getting cluttered (admittedly my choice of the Zire 72 made this problem more acute). Second, running it through EudoraWeb means I don't have any real control over the interface. If the Bluetooth connection got wacky (say Mom didn't have the access point in a direct line of sight, or she pointed the Zire 72 in another direction), EudoraWeb would start throwing generic error messages or offering to switch to offline mode, which would likely drive her crazy and leave the Palm in an "indeterminate" state. And she'd still be in the dark.
So that brings us back to Plua, because I could at least put better error handling in. Plua has very simple built-in primitives for things like streams and TCP/IP sockets, so I moved the scripts to the internal gopher server to make the protocol simple and threw together a proof of concept. This first draft had some big buttons you could push like a remote. This seemed like a good idea and worked well ... except that if the Bluetooth connection failed or you turned the Palm off while the light app was running, Plua went haywire and didn't reconnect. (Obviously a bug, but I don't have any way of fixing that in the Plua runtime.) If you restarted the app, it worked and reestablished the Bluetooth link, but that was inconvenient.
Then it dawned on me: since the connection would be reestablished when the app restarted, move the selection interface into the Palm launcher with multiple separate apps for each light profile that just called the appropriate script on the internal gopher server and quit. Plus, I could have as many profiles as fit on the screen and generate them off a template. On the iMac G4 I wrote a script generator and cross-compiled four basic profiles (off, all on, all dim, corner only) in MacPlua and pushed them over to the Zire 72.
Now, whenever you start any of them (large enough to be pressed with a finger), the Bluetooth link is reestablished if it lapsed, and the correct script on the gopher server is invoked:
But wait: we can make it even easier for Mom. Remember that single side button for voice memos that the Zire 72 has? You can change it to anything, so I changed it to ... turn the lights on by calling that light profile app. Mom picks up the Palm, sees the big label on it saying "to turn lights on, press side button," sees the only side button the device has, presses it, the Zire turns on, the app starts, connects, and the lights come on. You can even find it in a dark room because of the charging light on the end table. See it in the photograph above?
It's like the best Mother's Day present I've ever gotten her. Totally. No doubt.
Here's the source code for the template so you can see how cool and easy Plua is. PalmOS in the house yo.
host = "gopher-internal"
port = 70
sel1 = "/auto/lights/on"
gui.title("Sending command to lights...")
eh, et, es = io.open("tcp:/"..host..":"..port, "rw")
if (eh ~= nil) then
eh:write(sel1.."\r\n")
-- Consume all data
while true do
ev = gui.event()
if ev == ioPending then
buf = eh:read(8192)
break
end
if ev == appStop then
break
end
end
eh:close()
-- Fall through to launcher
else
gui.alert("Can't access network: point Palm at desk")
-- Fall through to launcher
end
Speaking of the classic Mac OS, I discovered this surprising project last week. I'll just leave it here for your interest.
