In an effort to save Palm OS, work has been started on an open source clone of the operating system. The author aims to make the clone OS binary and source compatible with Palm OS 5 wherever possible while still moving the OS forward with features like memory protection and multi-tasking. The project is at its infancy (it does not have a website yet), but the person behind it is asking for help.
But as the author clearly states, this might not be ready yet for public consumption (the “OS”) is just a library at the moment.
More importantly, as cool as this may get, I only see limited support as I do not know that many people willing to risk their PDAs to such a venture.
Besides hobbyist, what use is a PDA with no sync ability and no software?
That’s an awesome project, but its certainly not going to be easy.
Didn’t Palm end up buying the intellectual property from BeOS? If Palm has essentially shelved PalmOS, what incentive do they have for holding BeOS?
It would be an interesting interview with the President of Palm to ask them about their original intentions of buying BeOS, and what their current plans are for it. Maybe a discussion could get them to open source BeOS. Or even just parts of it.
Editors, what say you?
Whatever Be IP Palm owned they transfered to PalmSource when it was spun off in 2003. PalmSource was purchased by Access last year, so Access now owns the BeOS IP.
I would speculate, given that almost all of the former Be employees have left PalmSource and Access is concentrating on a Linux platform, they have no plans for the former Be IP.
Which is probably OK. BeOS was a cute OS for a multimedia player, but I’d hate to think of anyone trying to make it work for anything else.
One of the reasons that yT (YellowTab, builders of ZetaOS) folded was the royalties Palmsource and later Access expected for each copy of Zeta sold.
Access can’t be stupid about the sourcecode. Nobody should forget that. They are not “giving up on it” – or at least seem happy to make others pay a pretty penny for it!
I would think it would be easier to port an existing OS that already supports the CPU (Linux or BSD??), and then at that point work on an emulation layer. I think projects are already at work for Linux, like http://palmtelinux.sourceforge.net/
I suppose once you have a working OS, you could get POSE would work fairly easy for the pre OS5 apps. And for Native OS5 apps, its just a matter of an API emulator like Wine.
The key advantage of their approach is that it uses much less resources (which are scarce on low resource devices). This in turn provides more portability.
There’s likely also an impedence mismatch (http://en.wikipedia.org/wiki/Impedance_mismatch) between Linux and the Palm. Linux is more designed for the desktop or server environments, and while you could (as others have) try to write code to resolve the mismatch, it’d likely never work as well as something specificially designed for the system.
It’s a bit of a philsophical difference. Compare http://www.rockbox.org/ (which is ported to many different MP3 players) with http://www.ipodlinux.org/ (which needs to be ported to other MP3 players). iPodLinux may potentially become better and more portable than Rockbox, but Rockbox rules at the moment.
Except that they are talking about running on 68K devices. In other words, they aren’t creating a PalmOS 5 clone but a PalmOS 4 clone.
PalmOS 5 is a Palm-proprietary kernel running on ARM running the PACE 68K emulator. Some of the builtin apps seem to be ARM native code with a ARM-variant of the Palm API. Some 68K apps also run native code chunks.
The better way to do a PalmOS replacement is ignore the 68K devices and build the 68K emulator on an OS running on the ARM. Instead of writing protected-memory, multi-threading kernel from scratch, using Linux kernel makes a lot of sense. The Palm ARM devices are plenty fast enough to run Linux. In fact people have already gotten Linux to run on them.
I am the author of this little clone.
The focus on 68K devices is only temporary. All Palm OS apps start out in a 68K stub so even a completely ARM native application requires the 68K emulation layer to get started. Thus starting with ARM devices would require both a working 68K emulator and endian swapping stubs for all the syscalls before even the simplest of applications can be run. I’m also more familiar with the 68K family of processors and hardware based on them than ARM devices so the hardware specifc pieces of the code will be easier for me to write. ARM support will come eventually along with other architectures like x86 and SuperH.
As for the reasons for not starting with an existing OS or kernel, I have several. The first is that this is currently just a hobby project for me and as such is supposed to be interesting. On a personal level, writing an OS from scratch is infinitely more interesting than tacking a compatability layer on an existing kernel. I’m also not intimately familiar enough with any exisitng kernel to make such a compatibility layer work natively without spending a lot of time digging around in kernel sources.
The Linux kernel isn’t particularly skinny either and with a Palm OS compatability layer thrown in, the built-in flash of a lot of these Palm OS PDA is going to get awfully tight, particularly if a few basic applications are to be included in ROM as has been customary with Palm OS devices.
Of course, a lot of the work done for this project could be carried over to a project similar to what you propose and if someone wants to do that I don’t have a problem with it.
As for the Zire 31, it should be theoretically possible to run this OS on that device once it’s ready. I hope to support booting this new clone off of an SD card from whatever Palm OS version is built into the ROM. It won’t be a perfect solution for long-term use since the device will start back up in standard Palm OS if you do a hard reset or let the battery run down, but it will be good for trying it out without the risk of bricking your device and it could also be useful for devices like the Zire 31 that don’t have a flashable ROM.
An open-source Palm clone could be quite fun to play with. With the source code available, it would be possibile to make an ARM port, for example, which would be a great hobbyist project for someone seeking to use the Nintendo DS as a PDA (actually not a bad idea, given the low cost of the hardware it it’s high quality)
I’d like to see this succeed, I doubt I can upgrade the OS on my Zire 31 since it wasn’t intended to be possible with that model, but at least others with Palm OS 5 devices will be able to upgrade their OS if this project succeeds.
There are a few OS 6 Devices, like Palm’s LifeDrive if I’m remembering the name correctly.
There are a few OS 6 Devices, like Palm’s LifeDrive if I’m remembering the name correctly.
There are no shipping OS6 devices, and Palm never shipped an OS6 (called “cobalt”) device. LifeDrive, like all recent Palm devices prior to the 700W, runs OS 5 (called “garnet”).
Only one company, GSPDA, ever announced a Cobalt device. It was slated for the end of 2005 but has not yet shipped. I would guess it will never ship, now that Access owns PalmSource and has focused the PalmSource effort on ALP.
I would think it would be easier to port an existing OS that already supports the CPU (Linux or BSD??), and then at that point work on an emulation layer.
Or AROS.
http://www.aros.org/introduction/ports.php#aros-m68k-pp
It might just be possible to save both Amiga and Palm 🙂 But is PalmOS really in that much trouble?
BTW, LifeDrive runs PalmOS Garnet, not Cobalt.
http://www.palm.com/us/products/mobilemanagers/lifedrive/specs.epl
Palm seems not to allow users to update the OS on any devices they have for sale, either (I called & asked a few days ago). Shame…
…interesting. But why don’t help Haiku instead ?
They can make a portable version !
http://www.haiku-os.org/
that after Palm bought the remains of BeOS, that we’d have BeOS ported to the Palm platform… if even in the BeIA incarnation.
Talk about a missed opportunity.
Hmm.. come to my mind kernels like newOS, L4, Syllable, or VSTa. All them (except Syllable) are very modern microkernels, NewOS and VSTa are more innovative than the others, L4 is very stable, and i believe that code of Syllable is easier to read.
http://newos.org
http://os.inf.tu-dresden.de/L4/
http://syllable.org/about.php
http://vsta.org/
PalmSource spent 4 years and a lot of money trying to convert PalmOS 5 Garnet into a multitasking OS. In the end they failed. Only one vendor ever tried to develop a PalmOS 6 Cobalt device and they never managed to ship.
There is a serious chicken-and-egg problem for anyone trying to “save” PalmOS: 68k aps.
If you support them, then you are backed into a corner that makes designing for multitasking undoable.
If you don’t support them, then you have no legacy software to run.
The real problem is that the PalmOS APIs and programming model are so specific to the original battery-backed-ram, single-address-space, single-tasking model that they don’t generalize to a multi-tasking multi-address space model.
Palm/PalmSource killed PalmOS by preserving the 68k aps rather than providing an effective transition path that convinced PalmOS developers to update those aps to native aps for Garnet. That made Cobalt unsustainable and PalmOS on Linux a very bad idea.
If you support them, then you are backed into a corner that makes designing for multitasking undoable.
I don’t see why. Old apps don’t need to be aware that they’re running in a multi-tasking environment and I don’t see anything in the current API that would prevent multi-tasking.
The real problem is that the PalmOS APIs and programming model are so specific to the original battery-backed-ram, single-address-space, single-tasking model that they don’t generalize to a multi-tasking multi-address space model.
Care to provide some specific examples? Apart from applications that call other applications with SysAppLaunch and pass data structures containing pointers to data in their memory space (and this isn’t incredibly common) I don’t see where there should be a problem. The OS already has a concept of memory ownership for resource tracking purposes and because the OS has been single-tasking there isn’t a lot of IPC going on that could potentially be problematic from a memory protection point of view. Also, while these issues present some challenges for memory protection I don’t see how they are at all an obstacle to multi-tasking.
There are of course some limitations from the API (apart from the complete lack of multi-tasking or multi-threading) in the Data and Resource manager and in the support for multiple screen resolutions. The design of the former makes it difficult to efficiently store Palm databases on a non-memory mapped storage medium because there’s no good way to tell when an application is done reading a record (apart from doing some nasty hack involving MemHandles anyway). This isn’t a huge deal since databases in legacy applications aren’t likely to be ridiculously large since they generally have to fit in device RAM anyway and you can still flush all the records from RAM when the database is closed.
Palm/PalmSource killed PalmOS by preserving the 68k aps rather than providing an effective transition path that convinced PalmOS developers to update those aps to native aps for Garnet. That made Cobalt unsustainable and PalmOS on Linux a very bad idea.
The problem with Garnet wasn’t that old 68K apps still ran, it’s that it wasn’t really designed to do more than that. ARMlets are a dirty hack at best and betweenn the messy ARM support and the lack of modern features like multi-tasking and multi-threading leads to nasty hacks that weren’t likely to be compatible with Cobalt. This wouldn’t have been so much of a problem if PalmSource hadn’t taken forever to release Cobalt as there would be fewer of these nasty hacks out in the wild. So add together the compatability problems with “hacky” OS 5 apps, the crappier than OS 5 level of 68K compatability and the jump in ROM size and it’s no surprise Cobalt went nowhere. Palm on Linux was even more of a dud. It didn’t solve any of Cobalt’s main problems and just served to confuse the market.
If you do know of any problems in the API that would make multi-tasking impossible that I’ve missed I would like to hear about it so I can plan ahead on how to deal with it. I’m not an expert on every syscall in PalmOS and it’s certainly possible I missed something important.
App launching, the find interfaces, data manager’s assumptions about non-volatility, lack of resolution independence, inconsistant interfaces for things like 5 way nav, and so forth don’t give you a smoking gun, but taken all together, they add up to ‘paint into a corner’.
It’s not that it’s “impossible” to add multi-tasking to the mix, but rather, that to do so in any reasonable way will result in a system that’s prohibitively slow.
The problem with Garnet wasn’t that old 68K apps still ran, it’s that it wasn’t really designed to do more than that.
I agree. I think we’re just saying the same thing in different ways in this case.
By the way, have you given any thought to what language(s) you’re going to write this all in?
It’s not that it’s “impossible” to add multi-tasking to the mix, but rather, that to do so in any reasonable way will result in a system that’s prohibitively slow.
I disagree, but I suppose we’ll know for sure soon enough.
By the way, have you given any thought to what language(s) you’re going to write this all in?
C for the kernel at least. I thought about using C++ but given all of the C structs exposed by the API there aren’t a lot of places I could use its features effectively.
I’ve actually already started writing it. The memory manager is largely done until I add memory protection, and a good chunk of the data and resource manager is done as well. I also have an implementation of SysAppLaunch, but I haven’t gotten a chance to test it yet
“It’s not that it’s “impossible” to add multi-tasking to the mix, but rather, that to do so in any reasonable way will result in a system that’s prohibitively slow.”
I disagree, but I suppose we’ll know for sure soon enough.
I look forward to seeing how you solve the problem of the semantics of find in a multitasking environment.
Best luck.