StarGrid: A new Palm OS strategy game
quarters.captaintouch.com
quarters.captaintouch.com
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.
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
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 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
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.
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.