I'm not talking so much about the devices, as the whole experience. The exquisite UI, the distraction-free atmosphere, the lack of ads and dark patterns like tracking, the elegant simplicity, the efficient Graffiti language, and, yes, the reprogrammable physical buttons.
Now that Pebble is coming back why not bring Palm back too? I miss my circa 1999 PalmPilot so bad. I even had a gigantic ugly wireless modem for it that I used to check e-mail.
Very nice to see new PalmOS apps being written, and good job on your strategy game.
I co-authored Warfare Incorporated, an RTS originally on Palm devices, if anyone remembers that. We had to pull out all the stops to get the perf and get it small enough to fit.
My favourite PalmOS game! The OS 5 version is well done in that it properly adjusts to any screen resolution, including ones that no device ever shipped with. I often use it to test rePalm builds on new hardware. The OS 4 version was not as well done, so i had to patch it to support Dana widescreen and HE330 HVGA. Patched versions are here: https://palmdb.net/app/warfare-inc
For Dana, it was a simple binary patch. For HE330, a separate hack is needed that I had to write that 'enables Warfare'. Thus I called it "Kissinger"
I have to shamelessly show off my personal webpage, which is designed to be a rough emulation of how I remember palm OS looking back in the day, at least when you load it on a phone. https://gowder.io --- took me way too long to hack together the CSS for this in like 2017 :-)
I have dreams of porting the old Strategic Commander game to newer devices. Someday I hope it rises to the top of my todo list. I logged hundreds of hours on that game playing with my friends and brother.
Taking turns via IR blaster or pass-and-play was amazing in an era without wifi or cellular data. No account signups or anything, just point your devices at each other and you had a game going. And without continuous connectivity, asynchronous play was the default way games worked, so it worked great.
Damn, this brings back some nostalgia. As a kid I had my dad's old Pilot as well as a Sony Clie. I had so many free shareware games (shout out to classic PopCap).
Yes, nostalgia. This teleported me mentally back to the 1990s as I love seeing the old things resurface, that pattern and cycle thing that always holds true.
I recall sitting in board meetings playing games between other tech members as we had written simple games using the earliest means of direct connect device communication well before this was common. With the introduction of the Palm VII having the first mobile cellular smart device available and being a payment processor to large dotcoms at the time we of course we would also move into mobile payments on that Palm VII. This was yet another idea well before its time but it was fun working through the engineering issues of doing payments over cellular as well as satellite long ago. I still have NIB Palm VIIs with NIB payment cradles on my tech shelf of history, maybe some day I will dig them out again to play for inspiration and curiosity.
Whoa, did not expect to see a Sony Clie reference today. I had one in college! I loved taking notes with a folding keyboard, listening to music while playing games on the shuttle bus, and taking pictures with my friends. Oh man, memories.
Space War was great! Briefly in high school a few of my friends and I all had Palm OS devices.
I taught myself to crack palm apps and games, and with Space War I modified the strength of my ship. The IR multiplayer had no validation of parameters so I pranked my friends in an IR multiplayer match by one-shotting them all and zooming across the whole map in one turn! Great times.
I think I mentioned it in an earlier blog post, Space War was actually the big inspiration to make this game hex-tile based. Happy to see I'm not the only one that remembers that game! (found it: https://quarters.captaintouch.com/blog/posts/2025-05-06-2025...)
It's the whole idea of 'apps' before smartphones became a thing.
It's also the simplicity of how these worked, forget multitasking, just focus on one thing at a time.
No subscriptions! Either the applications were free or it's a one-off fee/shareware kind of thing.
And it's ofcourse nostalgia, I made my first game for Palm OS over 20 years ago, it was nice to revisit it and get familiarized again with how the whole build system worked.
"I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction."
Uhm, the context menu on words was a thing on the ZMachine (v3) port for the Game Boy too.
I launched Tristam Island under a Chinese Game Boy Colour clone and some rewritable USB cartridge. The games where playable enough with patience.
On smartphones, FDroid for Android had the Anysoft keyboard with a swipe option, it works great, much better than typing. There's also some grafitti 'keyboard' input at FDroid, but I prefer the swiping one as it's far superior.
On the old T9 phones, OFC a Frotz port exists for J2ME, but I didn't try it.
When you become good at using Palm graffiti, it's not too bad. I remember playing through all of the _Hitchhiker's Guide to the Galaxy_ game on a Palm IIIx while commuting on the bus between Boulder and Denver back in 1999 or so, and being amazed that I could play an actual computer game on a handheld device.
There were many keyboard accessories for Palm OS devices!
I had a foldable one with (almost?) full-sized keys that I really enjoyed using. It connected via infrared, which was a bit strange but made it compatible with different generations of device connectors.
Mobile app developers, if you haven't read Zen of Palm, I highly recommend this piece of art. You can download the PDF for free. Nothing beats Palm for its simplicity, responsiveness, and (perhaps subjectively) ease of use, even to this day.
Unfortunately that link to the Zen of Palm PDF is broken (at least from my work machine). I couldn't find it in the Internet Archive either. Any suggestions?
The amount of energy and creativity. I had an orange Handspring Visor. By default it did not have any networking. It had a cradle that you would sync up with your desktop, but the desktop software could pull stuff from the Internet. So indirectly, the Handspring Visor could access content from the Internet that had been previously retrieved. There was an amazing app that was kind of like Yelp. You could enter your location by specifying two cross streets, and then you could search businesses and read reviews. I used this PDA to manage my calendar and my contacts. With a limited amount of email. In the year 2000 I was using this thing exactly the way we all use our smart phones today. And the games were so much fun. It was truly a machine that could do anything.
Developing for is was a fun challenge. I had a device that had 4MB of memory total. This was RAM, Data, and application space. I created an "app" that had plugins. When you ran the HotSync is asked which plugins you wanted to "install", then based on which ones were installed it copied over the data you needed.
I loved the documentation. It might be the only SDK documentation I read with joy. It just clicked with me.
Gremlins. I liked this program as well. I don't recall if it was a simulator only or if it ran across on device. You could tell it to just wreck havoc on your app. I would set it up to run over the evening or weekend and I would just fix any bugs that occurred during that time. It would click every button, add weird text to all input boxes, just smash everything. It found many issues for me. When I came back over the weekend and there were no issues, I shipped my app. I still had users running it up until 2010.
It was probably nowhere near as good as I remember, but I remember it being damn near perfect. I lovingly kept my Trio(s) well into the age of the touchscreen smartphone.
I loved that you could freely beam apps from one device to another via the infrared port. I remember sharing apps with my friend and my mom at one point, sending and/or receiving.
I dis-recommend this HLE, as I do all HLEs -- lack of bug-for-bug compat will eventually rear its ugly head. Use cloudpilot - a real emulator of the real hardware running real unmodified ROMs right in your browser.
Last year I tried to extend Retro68 to support Palm OS and made quite a lot of progress, but in the end it ended up being too much work and I abandoned the attempt. I suppose now is as good a time as any to mention that it exists (in a very ugly state with lots of unsquashed commits) in case anyone wants to pick up the mantle.[0] At the least, it has an up-to-date and functioning copy of the Palm OS Emulator which, unlike cloudpilot, retains the debugger code so you can actually debug apps with it.[1] (I also reverse-engineered the dana HAL; this is as far as I know the only open-source version of POSE which supports that hardware.)
The thing that blocked me from being able to make any more progress was a bug in GCC that causes it to ICE generating PC-relative code[2], and I absolutely could not understand GIMPLE nor the GCC internals quickly, nor could I commit any more energy to trying to learn them. (Generating PC-relative code is essential for Palm OS because, unlike Mac OS, code sections are in read-only memory and cannot have relocations, so this mode being broken means it can’t really work.)
It is fair to say that I have no idea how close to actually working things actually are in that fork since GCC/binutils are an absolute nightmare[3] and I am no compiler engineer. Retro68 has some scary-looking hacks to deal with exception handling which wouldn’t work as-is with Palm OS, at the least. (Retro68 is also itself quite a pile of hacks which were clearly made without a good understanding of how GCC works, and without any apparent care to making sure it is easy to rebase atop newer versions of GCC.)
If I were to restart the work again I would probably just have GCC do the bare minimum of emitting code with whatever relocations it can, and then just make Elf2Mac rewrite machine code. Elf2Mac is itself fairly clearly an attempt to avoid having to touch binutils as much as possible, since it redoes a lot of the work that libbfd normally does, which makes sense, because working on GCC/binutils is just awful.[4]
[1] I tried to make the debugger work with the modern GDB remote protocol instead of the Palm-specific protocol which requires the ancient prc-tools version of GDB, but GDB is also broken <https://sourceware.org/bugzilla/show_bug.cgi?id=32120>, so that never worked very well. GDB’s remote protocol also does not support receiving symbols from the remote on-demand for whatever reason—it only allows to receive an ABI-compatible binary with DWARF symbols, which makes it next to impossible to get symbols out of the ROM, which uses MacsBugs format. Working with DWARF also sucks.
[3] Just as a tiny example: never in my life have I ever considered that someone would solve the “tabs versus spaces” debate by making the rule “two spaces per indent, unless it is eight spaces, in which case use a tab”. What IDE even supports this??
[4] To be clear, I don’t mean to denigrate all the hard work that has been done over decades to create these tools. The GCC toolchain is a triumph and I am sure that my relative intelligence has something to do with why I struggle with it, compared to all the compiler people who happily work with it every day. Nevertheless, it is a forty-year-old codebase, and everyone seems quite content to continue to work more or less within constraints that made sense in the 1980s, and perhaps not so much in 2025.
Is your POSE 64-bit fixed or still 32-bit? ISTR running into this problem trying to compile the original from source and have yet to find the round tuit.
It is 64-bit fixed (along with a bunch of other show-stopper bugs in the ancient FLTK code, and I got rid of the bizarre UI they they used only for *nix and replaced it with the UI they used for Windows). There were a couple 64-bit safety issues in the prc compiler too which I also fixed.
Good to hear (I have my own 64-bit fixed pilrc but POSE was the missing piece). What do you mean by the Windows UI, though? Likely I'd compile this on my MacBook.
When opening POSE without a previous session, on Windows it would open a reasonable window with some buttons (New, Open, Download, Exit). On *nix, they instead decided to open a blank window that said “Right click on this window to show a menu of commands”. (And then, due to programming errors and bitrot, actually trying to use the context menu would access invalid memory and crash.) So I replaced that bad UI with the less bad one from Windows. :-)
Yes, I saw that, it would have been really great if the source code had ever been released, instead I had to start from scratch…
My implementation does not require editing SDK headers and the goal was to support multiseg. If I had stopped at 32k single seg it would probably have been working. But I never got quite as far as being able to e.g. test libgcc, so who knows.
Click the second link. The source code is there. First comment. I only didn’t release it initially because I was really busy and sorting out a clean reproducible process to build it took too long. As soon as I was able to, I posted it.
And I have since made it not require any SDK changes.
Oh, how frustrating. I have no idea how I missed that since I feel like I spent quite a while looking for some later update that included the source. Well, thank you for making sure to release it! I did rewrite most of the Retro68 CMake code too, perhaps for similar reasons, so I can understand how that could have been a problem. At least the newer versions of GCC do not have race conditions in their Makefiles, unlike prc-tools-remix. :-)
The work I did was intended to eventually merge and live alongside the existing stuff in Retro68 instead of just blowing it away, with the hope that nothing like this would ever happen again to anyone else, but of course I failed to actually finish the work.
I never submit to OSS. It is the same as editing wikipedia -- every time I try, it is a political mess and nonsense galore. (My reasoning: If you are paying me for work, you are welcome to criticize, request amendments, etc. If you are not paying me for work, you thank me profusely for the free work I offered and take it...or don't. I am uninterested in your opinions in that case, or requests for changes unless they are bugs). Anyways, I never had goals of upstreaming anything. I was just trying to help others who wanted a working toolchain. My patches work well. People (not just me) have used them. There are also patches to PilRC i released that add some more bitmap compression modes and fix bugs with multi-depth fonts.
I'm not talking so much about the devices, as the whole experience. The exquisite UI, the distraction-free atmosphere, the lack of ads and dark patterns like tracking, the elegant simplicity, the efficient Graffiti language, and, yes, the reprogrammable physical buttons.
A PalmOS watch would be a really nice counterpoint to the hegemony of Apple Watch.
But that's about as likely to happen as an SGI Irix laptop.
I've been porting it to various devices, eg: https://x.com/dmitrygr/status/1980508960538099856, https://www.hackster.io/news/def-con-32-s-raspberry-pi-rp235...,
and possibly soon: https://x.com/dmitrygr/status/1978263373012717592
I co-authored Warfare Incorporated, an RTS originally on Palm devices, if anyone remembers that. We had to pull out all the stops to get the perf and get it small enough to fit.
For Dana, it was a simple binary patch. For HE330, a separate hack is needed that I had to write that 'enables Warfare'. Thus I called it "Kissinger"
Here is your game running on a Fisher-Price Pixter with my rePalm project on it: https://x.com/dmitrygr/status/1977255077501939726
Taking turns via IR blaster or pass-and-play was amazing in an era without wifi or cellular data. No account signups or anything, just point your devices at each other and you had a game going. And without continuous connectivity, asynchronous play was the default way games worked, so it worked great.
It's easy to get it going in an emulator, but I'm surprised games of that type never caught on, in their own right.
https://x.com/dmitrygr/status/1980508960538099856
(Dmitry is something else)
I recall sitting in board meetings playing games between other tech members as we had written simple games using the earliest means of direct connect device communication well before this was common. With the introduction of the Palm VII having the first mobile cellular smart device available and being a payment processor to large dotcoms at the time we of course we would also move into mobile payments on that Palm VII. This was yet another idea well before its time but it was fun working through the engineering issues of doing payments over cellular as well as satellite long ago. I still have NIB Palm VIIs with NIB payment cradles on my tech shelf of history, maybe some day I will dig them out again to play for inspiration and curiosity.
Stay Healthy!
This game reminded me of Space War
https://palmdb.net/app/space-war
I taught myself to crack palm apps and games, and with Space War I modified the strength of my ship. The IR multiplayer had no validation of parameters so I pranked my friends in an IR multiplayer match by one-shotting them all and zooming across the whole map in one turn! Great times.
No subscriptions! Either the applications were free or it's a one-off fee/shareware kind of thing.
And it's ofcourse nostalgia, I made my first game for Palm OS over 20 years ago, it was nice to revisit it and get familiarized again with how the whole build system worked.
"I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction."
From looking at my old hoarded palm files I think that the interpreter was PalmPilotFrotz, still available on the if-archive: https://ifarchive.org/indexes/if-archive/infocom/interpreter...
On smartphones, FDroid for Android had the Anysoft keyboard with a swipe option, it works great, much better than typing. There's also some grafitti 'keyboard' input at FDroid, but I prefer the swiping one as it's far superior.
On the old T9 phones, OFC a Frotz port exists for J2ME, but I didn't try it.
I had a foldable one with (almost?) full-sized keys that I really enjoyed using. It connected via infrared, which was a bit strange but made it compatible with different generations of device connectors.
Mobile app developers, if you haven't read Zen of Palm, I highly recommend this piece of art. You can download the PDF for free. Nothing beats Palm for its simplicity, responsiveness, and (perhaps subjectively) ease of use, even to this day.
I wrote a series of blog posts about it nearly two decades ago, and later translated some parts into English: https://dingyu.me/blog/zen-of-palm-1-preface
EDIT: Disregard, found it: https://archive.org/details/zen-of-palm
Developing for is was a fun challenge. I had a device that had 4MB of memory total. This was RAM, Data, and application space. I created an "app" that had plugins. When you ran the HotSync is asked which plugins you wanted to "install", then based on which ones were installed it copied over the data you needed.
I loved the documentation. It might be the only SDK documentation I read with joy. It just clicked with me.
Gremlins. I liked this program as well. I don't recall if it was a simulator only or if it ran across on device. You could tell it to just wreck havoc on your app. I would set it up to run over the evening or weekend and I would just fix any bugs that occurred during that time. It would click every button, add weird text to all input boxes, just smash everything. It found many issues for me. When I came back over the weekend and there were no issues, I shipped my app. I still had users running it up until 2010.
https://github.com/migueletto/PumpkinOS
I would like to get a Palm or similar PIM device again, to actually use.
Are there any devices like that, made by any company, these days?
I don't mind it having no net connectivity, in fact I'd prefer that, as long as it has a way of doing backups and restores, and installing apps.
I had searched somewhat, but so far did not find any, or maybe any at a suitable price.
Edit: It would be a plus if it could run a light version of Python too.
I had installed an app called Pippy (a Python for Palm) on my model V, but it used to crash all the time, so I stopped using it.
The thing that blocked me from being able to make any more progress was a bug in GCC that causes it to ICE generating PC-relative code[2], and I absolutely could not understand GIMPLE nor the GCC internals quickly, nor could I commit any more energy to trying to learn them. (Generating PC-relative code is essential for Palm OS because, unlike Mac OS, code sections are in read-only memory and cannot have relocations, so this mode being broken means it can’t really work.)
It is fair to say that I have no idea how close to actually working things actually are in that fork since GCC/binutils are an absolute nightmare[3] and I am no compiler engineer. Retro68 has some scary-looking hacks to deal with exception handling which wouldn’t work as-is with Palm OS, at the least. (Retro68 is also itself quite a pile of hacks which were clearly made without a good understanding of how GCC works, and without any apparent care to making sure it is easy to rebase atop newer versions of GCC.)
If I were to restart the work again I would probably just have GCC do the bare minimum of emitting code with whatever relocations it can, and then just make Elf2Mac rewrite machine code. Elf2Mac is itself fairly clearly an attempt to avoid having to touch binutils as much as possible, since it redoes a lot of the work that libbfd normally does, which makes sense, because working on GCC/binutils is just awful.[4]
[0] https://github.com/csnover/Retro68/tree/palmos
[1] I tried to make the debugger work with the modern GDB remote protocol instead of the Palm-specific protocol which requires the ancient prc-tools version of GDB, but GDB is also broken <https://sourceware.org/bugzilla/show_bug.cgi?id=32120>, so that never worked very well. GDB’s remote protocol also does not support receiving symbols from the remote on-demand for whatever reason—it only allows to receive an ABI-compatible binary with DWARF symbols, which makes it next to impossible to get symbols out of the ROM, which uses MacsBugs format. Working with DWARF also sucks.
[2] I believe it was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786
[3] Just as a tiny example: never in my life have I ever considered that someone would solve the “tabs versus spaces” debate by making the rule “two spaces per indent, unless it is eight spaces, in which case use a tab”. What IDE even supports this??
[4] To be clear, I don’t mean to denigrate all the hard work that has been done over decades to create these tools. The GCC toolchain is a triumph and I am sure that my relative intelligence has something to do with why I struggle with it, compared to all the compiler people who happily work with it every day. Nevertheless, it is a forty-year-old codebase, and everyone seems quite content to continue to work more or less within constraints that made sense in the 1980s, and perhaps not so much in 2025.
I did that 5 years ago and published it on reddit in /r/Palm:
https://old.reddit.com/r/Palm/comments/fu5870/announce_new_g...
and then
https://old.reddit.com/r/Palm/comments/p81m58/announce_new_g...
My implementation does not require editing SDK headers and the goal was to support multiseg. If I had stopped at 32k single seg it would probably have been working. But I never got quite as far as being able to e.g. test libgcc, so who knows.
And I have since made it not require any SDK changes.
The work I did was intended to eventually merge and live alongside the existing stuff in Retro68 instead of just blowing it away, with the hope that nothing like this would ever happen again to anyone else, but of course I failed to actually finish the work.