Pumpkin OS: x64 port/re-implementation of PalmOS(pmig96.wordpress.com)
pmig96.wordpress.com
Pumpkin OS: x64 port/re-implementation of PalmOS
https://pmig96.wordpress.com/2021/09/08/pumpkin-os/
52 comments
PalmOS was so much more usable than PocketPC EVER was. PPC was just insanely broken on so many fronts I was ASTONISHED by it when I -- foolishly, as it turns out -- bought a late model HTC in about 2009.
Among other things, you couldn't even use IMAP with the native mail client. I mean, seriously. In 2009.
Among other things, you couldn't even use IMAP with the native mail client. I mean, seriously. In 2009.
Indeed. At the time I was a rabid purchaser of PDAs and I wished desperately to get Palm OS with PPC hardware. Probably every color PDA Palm ever built had an LCD that buzzed like an angry hornet. Palm ergonomics were next-level, though. The Lifedrive is probably the best-feeling device of any kind I've held in my hand.
My only venture into WinMo was an ATT/HTC 8525, which was really a nice piece of HARDWARE, but the software use utterly useless.
The best Palm device I ever had was a Treo 650, which I actually ended up using on and off for a long time b/c it worked SO WELL, and the screen wasn't terrible.
(As long as we're talking about interesting hardware: the Danger "HipTop" device was pretty great from a form factor POV, but was hamstrung by lack of real desktop connectivity as I recall.)
The best Palm device I ever had was a Treo 650, which I actually ended up using on and off for a long time b/c it worked SO WELL, and the screen wasn't terrible.
(As long as we're talking about interesting hardware: the Danger "HipTop" device was pretty great from a form factor POV, but was hamstrung by lack of real desktop connectivity as I recall.)
On the other hand if I remember correctly, it had a very primitive C programming environment, with memory handles, that had to be locked down before any kind of pointer could be used on them.
Yes, but if I remember correctly, was the programmer’s responsibility to save the state on every user input to prevent data loss on prc exit.
Exactly like Android :)
Very cool, but I can't help wondering what this would look like if it ran on an ARM development board (like the Raspberry Pi, which has a massive third-party touchscreen ecosystem).
I'd imagine it would look something like this:
https://pmig96.wordpress.com/2021/04/29/palmos-on-raspberry-...
https://pmig96.wordpress.com/2021/04/29/palmos-on-raspberry-...
That is a LOT more interesting than the original post, TBH. Many thanks!
Ha, gotta love the Nintendo DS stylus!
Wow! PalmOS, that's a blast from the past! I have fond memories of using that.
Very cool. It would be cool if they pivoted to target ARM, or even better RISC-V, to target handheld devices.
I was into the Palm OS “scene” in the early-2000s. The hardware maker spun off its OS division into its own company in early-to-mid 2000s.
The thing that drove me to fits was that Palm OS 6 (Codename Garnet) was apparently ready to roll, according to all the news reports at the time, but it never made it into a device. The damn thing had bits of BeOS in it! You end up wondering what could have been if Palm (the hardware maker) did end up adopting Palm OS 6.
I imagine some practical concerns, maybe around SDKs, licensing costs or power consumption were the driving Palm to keep version 5. This was never reported on, however.
You knew the writing was on the wall when Palm released Treos with PocketPC.
The thing that drove me to fits was that Palm OS 6 (Codename Garnet) was apparently ready to roll, according to all the news reports at the time, but it never made it into a device. The damn thing had bits of BeOS in it! You end up wondering what could have been if Palm (the hardware maker) did end up adopting Palm OS 6.
I imagine some practical concerns, maybe around SDKs, licensing costs or power consumption were the driving Palm to keep version 5. This was never reported on, however.
You knew the writing was on the wall when Palm released Treos with PocketPC.
They used T|T3s internally to develop it. I have one: https://www.reddit.com/r/Palm/comments/cjx9d9/palmos_61_coba...
There was also a small run of phones made, which you'll never ever find in the wild, but I know someone who has one: https://photos.app.goo.gl/kZuGkhQSDzH9Q8ni6
There was also a small run of phones made, which you'll never ever find in the wild, but I know someone who has one: https://photos.app.goo.gl/kZuGkhQSDzH9Q8ni6
This is nice closure for me after all these years!
> You end up wondering what could have been if Palm (the hardware maker) did end up adopting Palm OS 6.
Android? A lot of BeOS people went to Android so the similarities in some parts of the SDK are staggering.
Android? A lot of BeOS people went to Android so the similarities in some parts of the SDK are staggering.
Is it ever likely that something like this could work on legacy Palm hardware like my beloved Palm Prē?
That was WebOS which did make it to open source.
https://www.webosose.org
https://www.webosose.org
Is there a build of this for the HP Touchpad?
I can't find that but there is a way to get Android 9 on one.
I’d pay for a community maintained palm pilot with a dot matrix or e-ink display that had similar battery life and an open source palm OS.
Working on it: http://dmitry.gr/?r=05.Projects&proj=27.%20rePalm
I'm not affiliated with this project but I'll plug https://palmdb.net
There's also the subreddit and a discord channel with a very active community of palm developers/collectors
There's also the subreddit and a discord channel with a very active community of palm developers/collectors
I wonder if the m5paper[0] (esp32 based) is beefy enough to run this.
[0]: https://shop.m5stack.com/products/m5paper-esp32-development-...
[0]: https://shop.m5stack.com/products/m5paper-esp32-development-...
Fond memories of running around San Francisco around the year 2000 with my orange translucent Handspring Visor. Sure, it had no radios, but you could put in in a cradle attached to your computer and sync up info from the Internet. There was an app with a built in map and database of restaurants. It was a lightweight, fun-to-use, productivity tool. Brought it everywhere, to all my work meetings, diligently took notes and kept my contacts organized and up-to-date. Good times.
The Visor was a neat device on account of the Springboard slot. There was an attachment, the VisorPhone, which turned the Visor into what you'd easily recognize today as a smartphone. To boot, PalmOS on the Visor had a working TCP stack, so you could dial out (literally dial out - there wasn't even GPRS on it!) and send/receive e-mail, browse the Web, and so on.
The Visor, a foldable keyboard, and a Nokia phone was my office! Best days ever.
I also have fond memories my mom and dad got me a palm for my birthday because I was big into computers even when I was a child. One birthday we even had fun destroying a IBM XT. In retrospect I wish we had kept the IBM XT as they are going for 400 right now. I got a keyboard for that palm and played games on it and stuff. My uncle got me into computers and I never looked back.
I long for the day when our current mobile OSes work half as well as Palm/Treo devices did in the 90s and early 2000s...
Quite seriously, neither iOS nor Android are even remotely as good at easy, right now interaction and usefulness as Palm was nearly 30 years ago. That is especially true for contact management/phone apps!
Quite seriously, neither iOS nor Android are even remotely as good at easy, right now interaction and usefulness as Palm was nearly 30 years ago. That is especially true for contact management/phone apps!
>Quite seriously, neither iOS nor Android are even remotely as good at easy, right now interaction and usefulness as Palm was nearly 30 years ago. That is especially true for contact management/phone apps!
I guess I wonder what you think is missing or worse than Palm?
I don't have any experience with Android, but on iOS I don't miss ANYTHING -- I find the always-on OTA sync ALONE to be an enormous advantage. The device is fast, responsive, and just-works in a way that nothing did 20 years ago. Palm desktop sync was good for 1999, but it still had issues that came up (esp if you depended on Outlook) that I have never seen with iOS OTA sync.
I guess I wonder what you think is missing or worse than Palm?
I don't have any experience with Android, but on iOS I don't miss ANYTHING -- I find the always-on OTA sync ALONE to be an enormous advantage. The device is fast, responsive, and just-works in a way that nothing did 20 years ago. Palm desktop sync was good for 1999, but it still had issues that came up (esp if you depended on Outlook) that I have never seen with iOS OTA sync.
I'm just glad my device doesn't factory reset when I forget to plop it on the charging dock after class. Although my Zire 21 did a good job of making me a backup junkie so I could recover easily from those charging accidents.
It is cute. The main issue (which the creators of the previous PalmOS HLE - "styletap" inevitably found), and that any Wine developer will tell you about at length, is that in any HLE, compatibility as per official API docs is only 10% of the work. The remaining 90% is bug-compatibility. The long tail of that ... it is almost infinite in length.
Eg:
"DmNewHandle()" - seemingly a simple API in PalmOS - will take NULL as first parameter in PalmOS 2.0+, but will not in 1.0+. Applications written for 1.0 will expect entirely different behaviour. PalmOS 2.0+ will detect such applications and offer them that behaviour. This is not documented anywhere.
Or, "TxtPrepFindString()". In PalmOS 3.5 and later its prototype is "UInt16 (const UInt8 * , UInt16, UInt8 * , UInt16)", while in 3.3 and before, it is "void (const UInt8 * , UInt16, UInt8 * )". Once again this is not documented, but each app needs to see what it expected of the API it was compiled with. And unlike Android/iOS there is no per-app manifest indicating which SDK version it was built with.
And: some SysTraps over time were entirely replaced with incompatible functions at the same SysTrap number. PalmOS 2.0 changed PsrClose into SysLibLoad. PalmOS 3.0 changed PsrGetCommand into SndPlaySmf and PsrSendReply into SndCreateMidiList. PalmOS 3.1 changed PsrInit into IntlDispatch. A proper HLE will need to somehow detect OS version the app targets to provide the proper functionality when one of these SysTraps is made... Doable, but not trivial... (When working on RetroFix, I came up with A solution. Since these 4 calls are only reasonable in a certain order, an app is flagged as "1.0 app" if it calls PsrInit. But how to tell that apart from IntlDispatch? IntlDispatch takes a "selector" in D2, and at the time of PalmOS 1.0 SDK, writing the selector into D2 was REQUIRED to be the very preceding instruction to the trap, using a MOVEQ instruction. At the same time, PalmOS ABI will not preserve D2 across calls, so if you are calling an API that does not take a D2-selector, writing D2 would be pointless as it is about to be destroyed. So, I check for a MOVEQ to D2 register in the previous instruction to where the trap is.)
This goes on almost forever. This is why an HLE (of anything, not just PalmOS) is a project with no"completion date.
Eg:
"DmNewHandle()" - seemingly a simple API in PalmOS - will take NULL as first parameter in PalmOS 2.0+, but will not in 1.0+. Applications written for 1.0 will expect entirely different behaviour. PalmOS 2.0+ will detect such applications and offer them that behaviour. This is not documented anywhere.
Or, "TxtPrepFindString()". In PalmOS 3.5 and later its prototype is "UInt16 (const UInt8 * , UInt16, UInt8 * , UInt16)", while in 3.3 and before, it is "void (const UInt8 * , UInt16, UInt8 * )". Once again this is not documented, but each app needs to see what it expected of the API it was compiled with. And unlike Android/iOS there is no per-app manifest indicating which SDK version it was built with.
And: some SysTraps over time were entirely replaced with incompatible functions at the same SysTrap number. PalmOS 2.0 changed PsrClose into SysLibLoad. PalmOS 3.0 changed PsrGetCommand into SndPlaySmf and PsrSendReply into SndCreateMidiList. PalmOS 3.1 changed PsrInit into IntlDispatch. A proper HLE will need to somehow detect OS version the app targets to provide the proper functionality when one of these SysTraps is made... Doable, but not trivial... (When working on RetroFix, I came up with A solution. Since these 4 calls are only reasonable in a certain order, an app is flagged as "1.0 app" if it calls PsrInit. But how to tell that apart from IntlDispatch? IntlDispatch takes a "selector" in D2, and at the time of PalmOS 1.0 SDK, writing the selector into D2 was REQUIRED to be the very preceding instruction to the trap, using a MOVEQ instruction. At the same time, PalmOS ABI will not preserve D2 across calls, so if you are calling an API that does not take a D2-selector, writing D2 would be pointless as it is about to be destroyed. So, I check for a MOVEQ to D2 register in the previous instruction to where the trap is.)
This goes on almost forever. This is why an HLE (of anything, not just PalmOS) is a project with no"completion date.
Plus MotionApps Classic is technically also HLE. Plus Garnet VM for ARM, which may be the same anyway. Apparently HLE of PalmOS is reasonably easy for the initial 99% of apps at least, since we do have a number of "successful" implementations already.
Not sure if anyone really cares about the 1% of appls which wouldn't work on OS5 anyway.
Not sure if anyone really cares about the 1% of appls which wouldn't work on OS5 anyway.
GarnetVM was written by people with access to the source code of the OS. Not quite as hard :)
BEAT UP MARTIN
EAT UP MARTHA
EAT UP MARTHA
Ah, I remember my Newtons fondly. It was really, really great for the era -- a far smarter device than the Palm, but also much bigger and MUCH more expensive.
They justifiably took a hit for the efficacy of the v1 HWR, but v2 was really, really great. I used the MP2000 model daily for about a year and a half before finally migrating to Palm.
Funnily enough, I found that with a Newton I could actually take meeting notes on the device, but the small size of the Palm made that task really unpleasant despite the high-speed possible with Graffiti. The screen was just too small. OTOH, the seamless sync with Outlook was the killer app there.
They justifiably took a hit for the efficacy of the v1 HWR, but v2 was really, really great. I used the MP2000 model daily for about a year and a half before finally migrating to Palm.
Funnily enough, I found that with a Newton I could actually take meeting notes on the device, but the small size of the Palm made that task really unpleasant despite the high-speed possible with Graffiti. The screen was just too small. OTOH, the seamless sync with Outlook was the killer app there.
I had a Newton and a very similar experience. I loved the Newt and used it for a year and a half (I bought it used) but ended up migrating to Palm for compatibility. The Newt just got too hard to use once I no longer had a Mac with a serial port. I upgraded to a Palm (a Visor IIRC) that had a USB cradle.
I had the same issue with note taking on the Palm vs the MP2000. I never internalized Grafitti so writing notes for me was painfully slow. On the Newt I could take notes at normal writing speed.
The danger (for those who never experienced old PDAs) is they had to sync with a wired connection before Bluetooth. The internal state of the device could have content that didn't exist on your computer. All kinds of problems on the device could make it lose its internal state erasing notes, contacts, or whatever other data between the last sync and then.
I had the same issue with note taking on the Palm vs the MP2000. I never internalized Grafitti so writing notes for me was painfully slow. On the Newt I could take notes at normal writing speed.
The danger (for those who never experienced old PDAs) is they had to sync with a wired connection before Bluetooth. The internal state of the device could have content that didn't exist on your computer. All kinds of problems on the device could make it lose its internal state erasing notes, contacts, or whatever other data between the last sync and then.
I learned Graffiti on the Newt, actually; everyone pretty much bought it to use on the v1 rev of the NewtOS because of how iffy the HWR was. Using G meant you had a floating input window and an insertion point, which made it usable.
Even on v2, with the VERY good native HWR, I still had Graffiti on the Newton for editing. On a screen full of text, popping up the G window allowed for easier text entry w/o messing with existing text.
So when I went to Palm, I knew Graffiti very very well.
Sync for me was super stable for Palm, but one thing that really hurt Apple was that they more or less IGNORED the desktop. On Windows -- where I lived at the time -- all you could do was back your Newton up. It wouldn't sync to Outlook or a native desktop tool or anything, which is precisely the wrong choice. Palm's easy, simple sync was deadly to the Newton. I'd drop it on my cradle when I came in every morning and hit the sync button before getting coffee.
Even on v2, with the VERY good native HWR, I still had Graffiti on the Newton for editing. On a screen full of text, popping up the G window allowed for easier text entry w/o messing with existing text.
So when I went to Palm, I knew Graffiti very very well.
Sync for me was super stable for Palm, but one thing that really hurt Apple was that they more or less IGNORED the desktop. On Windows -- where I lived at the time -- all you could do was back your Newton up. It wouldn't sync to Outlook or a native desktop tool or anything, which is precisely the wrong choice. Palm's easy, simple sync was deadly to the Newton. I'd drop it on my cradle when I came in every morning and hit the sync button before getting coffee.
> Sync for me was super stable for Palm, but one thing that really hurt Apple was that they more or less IGNORED the desktop.
Apple definitely ignored the desktop with the Newton. At the same time I think that just reflects different philosophies between Apple and Palm with respect to PDAs. Apple saw the Newton as it's own device while Palm saw it as a loosely tethered satellite device.
This difference I think contributed to Palm's success over the Newton. The Palm's more limited scope allowed it to be much smaller and cheaper than the MessagePads and (as you point out) required it's desktop integration to be much better.
Had WiFi been available (802.11b spec, not the pre-spec versions) by the time the MP2000 came out it might have been able to survive as it's own non-desktop platform. The necessity of wired connections and the lack of good desktop sync was a huge drawback for Newts. With the Network Connection Kit they had cool networking capabilities.
Apple definitely ignored the desktop with the Newton. At the same time I think that just reflects different philosophies between Apple and Palm with respect to PDAs. Apple saw the Newton as it's own device while Palm saw it as a loosely tethered satellite device.
This difference I think contributed to Palm's success over the Newton. The Palm's more limited scope allowed it to be much smaller and cheaper than the MessagePads and (as you point out) required it's desktop integration to be much better.
Had WiFi been available (802.11b spec, not the pre-spec versions) by the time the MP2000 came out it might have been able to survive as it's own non-desktop platform. The necessity of wired connections and the lack of good desktop sync was a huge drawback for Newts. With the Network Connection Kit they had cool networking capabilities.
What's weird is to consider how unusual in the whole history of Apple for it to get the market so fundamentally wrong, as they did with the Newton's connectivity. The platform was sound (if expensive); if they had realized that sync was the future, it still would've had an uphill battle vs Palm's ubiquity and low price, but they'd have had a shot.
I think it's important to remember this was Sculley's Apple which was not at all good at judging market viability. I think the problem with the Newton platform, as it actually shipped, was sort of designed (and priced) for the jet setting executive. There was no real content creation, "office" capability, or even long-form input. It was an electronic briefcase with a built-in secretary. The Newton didn't synchronize with desktop PIM apps because executives had people to do that for them.
The Palm Pilot was designed for people that actually have work to do so it synchronized with the software on the desktop they used. It was also priced to be affordable by someone that didn't have the corporate black AmEx in their wallet. It was a handheld extension of their PIM software with a calculator.
The Palm Pilot was designed for people that actually have work to do so it synchronized with the software on the desktop they used. It was also priced to be affordable by someone that didn't have the corporate black AmEx in their wallet. It was a handheld extension of their PIM software with a calculator.
>I think it's important to remember this was Sculley's Apple which was not at all good at judging market viability.
Oh, 100%. My comment is really more about "they've been so good for so long..." than anything else.
BTW, though, the Newton DID sync with the Newton Desktop in v1. It wasn't as nice as the Palm desktop, or sync with Outlook, but it was usable. Then they dropped it for v2, which was just dumb, dumb, dumb.
Oh, 100%. My comment is really more about "they've been so good for so long..." than anything else.
BTW, though, the Newton DID sync with the Newton Desktop in v1. It wasn't as nice as the Palm desktop, or sync with Outlook, but it was usable. Then they dropped it for v2, which was just dumb, dumb, dumb.
That was the Newton, not Palm.
That was the Apple Newton.
Looks like it's still stuck in the NSA/Microsoft walled garden. Might as well be using Windows.
looks like it runs on linux, just not released yet
Runs on "linux" (aka NSA/Microsoft Windows) isn't the point here. The source code isn't available outside of the NSA/Microsoft walled garden, seemingly anywhere.
The weirdest thing about PalmOS architecture was how they never really ported it to ARM processors, so on ARM devices it just ran 68k code via an emulation layer. (I believe there was a way to load ARM-native blobs which allowed some ability to take advantage of the faster CPUs in the later devices.)
Evidently an ARM-native version of PalmOS (PalmOS 6, based on beOS of all things) was eventually released, but somehow it never made it onto any real devices.
Evidently an ARM-native version of PalmOS (PalmOS 6, based on beOS of all things) was eventually released, but somehow it never made it onto any real devices.
Not true. Large parts of PalmOS 5.x were ARM. I documented a lot of it here: http://dmitry.gr/?r=05.Projects&proj=27.%20rePalm
Why not release the source _now_ ? Somehow I'd bet something will happen or the author will lose interest and the source will never be released...
This look awesome and will have to look into playing with it! However, I was a tad bit disappointed that it wasn't Halloween themed with the name and the time of year we are coming upon.
They were also damn sexy: http://www.palminfocenter.com/images/TX_front_yahoo_S.jpg