Palm OS 5 Interview With David Fedor of PalmSource
There's a lot of excitement in the Palm User Community and Developer Community about the release of the next generation of devices running Palm OS5 on ARM processors, and there are also a lot of questions.
We're very pleased to have David Fedor, the Director of Developer Architecture and Disclosure and one of the most senior programmers at PalmSource Inc., here to enlighten us and answer questions about Palm OS 5 and the future direction of the Palm OS.
The Palm OS 5 Interview With David Fedor of PalmSource
By: Dan Royea PalmEvolution.com
December 21, 2002
There's a lot of excitement in the Palm User Community and Developer Community about the release of the next generation of devices running Palm OS5 on ARM processors, and there are also a lot of questions.
We're very pleased to have David Fedor, the Director of Developer Architecture and Disclosure and one of the most senior programmers at PalmSource Inc., here to help provide some answers. Thanks for taking time out of your hectic schedule for this David!
David Fedor (DF): Glad to talk with you. It is always fun to read PalmInfocenter, for the news and reviews as well as the rumors!
PalmInfocenter (PIC): Heh, maybe we'll dispel a few false rumors and misconceptions today!
Let's start with a few OS5 basics. Up until now, all Palm OS devices have used a processor from Motorola's Dragonball "68k" line. Why the switch to ARM?
DF: A few reasons. The processors based on ARM Ltd.'s architecture have a great reputation for providing a superior amount of useful processing power for the required battery power, so it fit well with our philosophy of building really useful products at lower cost and complexity than others seem to aim for. Plus, ARM processors come in a great range: from small, targetted and efficient to astoundingly feature-rich, so our Licensees can make products with as wide a range of benefits.
In this situation you get the benefits of standardization but also of competition: everything is compatible since it is based on the ARM architecture, and yet there are major silicon vendors battling it out, adding in unique features and keeping prices low. Thus, Licensees have a lot more flexibility to find the perfect chip to power a new device which might be aimed at a different market niche than their previous devices were.
PIC: How are the relationships between the various companies structured?
DF: Our Licensees are superb at making devices, yet nobody knows the chips as well as their makers. So we link up the chip creators with our Licensees in a program called "Palm OS Ready". We all work together so that Palm OS can run optimally on the various chips, and take advantage of their unique strengths. (Shameless plug for the Palm OS Ready partners: current members are Intel, Motorola, and Texas Instruments, along with MediaQ and ATI Technologies who focus on the graphics capabilities.)
So the Palm OS Ready partners write the lowest level software to make Palm OS run best on the individual ARM chips... creating the foundation best suited for the product in question while also sticking to the OS's standards. Then Palm OS and the Licensees build on top of that solid ground. Effectively, the Palm OS Ready partners make the standard Palm OS run well on a particular chip, and then the OS Licensee makes it special by selecting or creating the software and addon hardware which result in a unique product.
PIC: So in technical terms, the Palm OS Ready partners write the >Hardware Abstraction Layer (HAL) and the Licensees create the Device Abstraction Layer (DAL)?
DF: Basically, yes. We do provide lots of reference code for each of these layers, and it isn't a completely black and white matter, but yes. Plus, the names and capabilities of these layers have changed over time and will change more in the future.
PIC: We know that the three main "Palm OS Ready" ARM chips at present are the Texas Instruments OMAP, the Intel XScale and Motorola's Dragonball MX lines. Can you describe some general differences between the chips' capabilities? Some apparently have integrated DSP to "share the load" for multimedia?
DF: Well, Intel, TI, and Motorola have each developed their own flavors of ARM CPU's, and each has chosen to make different tradeoffs between cost, power consumption, clock speed, integrated features, and external accessory support. All three have excellent products, and the details and relative merits of these features and tradeoffs are best commented upon by the chip manufacturers themselves. We make sure the core Palm OS runs well across the board, and then Licensees can choose the right chip based on what their products need. You'll have to talk with them to hear where they target things - I don't want to step on their toes by contradicting them!
PIC: Fair enough [making note to contact TI/Palm, Intel/Sony, Motorola/Garmin].
So basically in OS5, the Palm Operating System is running ARM-native?
DF: Absolutely. We've completely switched over because of the speed and architectural improvements which result. And there's such a speed improvement that we could run the existing 68k software by "pretending" to the application that nothing (much) changed... and most software still ends up being faster without any effort.
PIC: There's a huge number of older devices plus new ones currently being released that use the non-ARM Dragonballs...
DF: It is well-understood technology, and certainly has life in it. Lots of users and applications don't need the extra speed.
PIC: ...and these OS4 and earlier devices are not upgradeable to Palm OS 5.
DF: True, like CD
players aren't upgradable to become CD burners. Fundamentally new hardware.
But OS 4 and OS 5 devices all work together and most software still works everywhere.
However, people choose to upgrade to new devices because of the whole package
of improvements they get: better screens, better built-in networking, new physical
capabilities and breakthroughs, and new software that is doing things that were
simply impossible before. Lots of improvements, not just the speed increase.
PIC: Sure, the advanced security capabilities and HiFi sound recording and playback are compelling reasons for some too.
Will some of the new features found in OS5 be adapted into newer versions of OS4?
DF: Yes, sometimes they will. But the vast majority of our engineering focus is spent on moving things forward, using the new capabilities the ARM chips offer us. There are indeed some exciting 68k-based projects which have been in the works for a while, but the reasons to start new projects on ARM are plentiful.
PIC: Yeah, I can imagine!
Let's talk about PACE: some people are under the impression that this is a kind of emulator.
DF: PACE is what makes existing applications work on a totally different processor than what they were expecting. (It stands for Palm Application Compatibility Environment.) This way the great apps keep working even as the operating system and hardware take huge leaps forward. It executes the app's code and implements the APIs it calls, by calling through to the real OS, after changing the parameters around.
For the programmers in the audience: it changes the endianness of numbers on data going in and out of system APIs, handles the different structure packing on the two architectures, and also insulates apps from a few environmental differences that we've not had to trouble people with yet.
PIC: OK, so it's more of an on-the-fly Translator, rather than an Emulator.
Now, PACE shouldn't be confused with POSE...
DF: Right. POSE (the Palm OS Emulator) is a developer tool for Windows, Mac OS and Linux. It pretends to be the old hardware, and provides fabulous debugging features. It runs the 4.x and earlier ROMs just like they are on a real device. PACE runs invisibly on a device, is much smaller and faster, and it calls through to the real OS 5 so you get the speed improvements. There's more under the hood that PACE doesn't expose; we're going to be keeping PACE basically exposing the 4.x APIs from now on. Native code will have access to more features when the time comes.
PIC: Maybe you can clarify the "high resolution" feature of OS5. It's somewhat different than what Sony introduced on their N-series handhelds running OS 3.5.1.
DF: Yes, Sony was the first to provide the much better screens. (For those who haven't gotten a device with a high resolution screen yet: beware, once you get one, you're hooked forever...) They were very concerned about making sure all applications worked properly without having advance notice, though. To ensure that compatibility, applications didn't reap the benefits of the better screen, until/unless the developer changed the code. When we added the capability to the OS, we did it such that apps will nearly always benefit, even without any changes. So long as they don't actively make assumptions about the screen's hardware being the old-style, of course. But we made sure developers knew way in advance, like we always do.
PIC: Obviously it's not just changing the original 160x160 to 320x320 pixels.
DF: No; you get much better looking text because the fonts have been redrawn to add more smoothness and readibility. You can get similar improvements in bitmaps (pictures and drawings) when the developers include the better artwork in their applications. Old pictures just get "blown up" and unfortunately stand out because their quality is only as good as it was previously, whereas everything else improved.
PIC: So the 320x480 resolution used in the new Clie "NX" line (OS5) uses PalmSource-approved APIs, whereas the "NR" "T" and "SJ/SL" lines (OS4.1) use their own proprietary system?
DF: That's right. Actually most of Sony's old proprietary APIs still work on their new devices, but I don't know how long they'll keep that support around. There's really no benefit to them, given that the Palm OS APIs are there, and they're encouraging people to move to the platform APIs too.
PIC: What about "non-standard" resolutions, like the HandEra 330 (240x320), Clie NX/NR (320x480), AlphaSmart dana (560x160), etc.?
DF: Those are actually different scenarios: the physical "real estate" is a different matter from its resolution. Resolution is what you see when you compare a letter printed on a laser printer versus a dot-matrix printer: same size paper, but nicer looking text. The devices you listed are like getting a bigger piece of paper: you can fit more lines without changing the font size. (Well, the Clie example there does both: more physical space as well as higher resolution.) In any case, applications will use the same Palm OS API for every density, and might now want to decide what to do with the extra space available on some screens.
Typically you don't want to add more lines of data when all you get is a resolution increase; that quickly leads to excessively small text, sharp though it may be. Sometimes, yes, but developers have to use good judgement.
PIC: So now that PalmSource has an independant role from Palm Inc. (the device makers), are all the various Licensees more willing to providing input to your OS-development team to get some more common APIs?
DF: We're very excited about having closer relationships with all Licensees, like the one we've had with Palm Inc. The more we do together, the faster we end up with great products. We've seen that work well in several situations: a Licensee is really excited about some feature, we work together to create something great for their device, and then it gets rolled into Palm OS later. Everyone can benefit, particularly the original creator, since there'll be more applications adding support for that feature.
PIC: I guess a closely-related question is about the difficulties developers are having trying to support the increasingly divergent number of devices and their features. Will OS5 help make broad device compatibility a simpler task?
DF: I think so, particularly for things like the high density APIs. APIs that only work on one device make life harder for developers, and that slows marketplace adoption of that feature. At the same time, our devices aren't carbon copies of each other. Sure it'd be easier if everything was just like the Palm V, but that'd be pretty boring. Life would be easier for architects if everyone's house was identical... Fossil's upcoming Palm OS watch device has different user interface concerns, and it is right for apps to customize accordingly! There's lots of value in diversity, and yet we standardize APIs whenever that's right to do.
PIC: So will we get some consolidation of divergent features; like HiRes, or JogDial, or virtual Graffiti?
DF: We've already got the single API in use for single, 1.5x, and double resolutions - and it wouldn't have to change at all when/if someone makes a triple or quadruple resolution screen. JogDial and the 5-way navigator are fairly different and you don't necessarily want the same behavior from them... and yet we'll see what we can do to keep life easy for things like that. Having single APIs for letting the Graffiti area close is certainly something that makes sense to have in the platform - stay tuned there.
PIC: Let's move on to existing application compatibility - we've heard that 80% of existing applications should run fine on OS5. Care to elaborate a little?
DF: Normal, well-behaved apps generally "just work", which was the goal. Some applications relied upon details of the hardware or the OS's internals, and didn't anticipate change. We've been open and honest for years about what things are subject to change, so hopefully no developers were surprised - unless they're hermits or something. (We started publicly seeding developers with Palm OS 5 over a year ago.) Lean on the affected developers to make sure they learned from the experience; unsupported things will keep changing, I guarantee that!
The more exciting part comes when the applications start taking advantage of the new possibilities. I know many developers have moved performance-critical code into native ARM subroutines (affectionately known as ARMlets) and seen dramatic improvements, some as high as 50x faster. Most applications don't need that, but the option is there and is pretty cool.
PIC: Yeah, very cool. :-)
One thing that power users are missing are their hacks; which basically don't work, right?
DF: Hacks by their very nature were nearly always relying on internal details of Palm OS 4 and earlier, and there were lots of changes to the OS. We tried hard to see if there were ways to keep them working, but had to make the tough choice to move the OS forward and give them new appropriate ways to do much of what they could before. They've easily got as many opportunities as they had before, though some of the opportunities have changed: some things are easier through new notifications that were added, but some are harder. Hack writers are usually very creative so it is always neat to watch what they can come up with.
PIC: Are there any optional apps that PalmSource makes available to Licensees or are those mostly developed independantly?
DF: There are lots of components to Palm OS, and Licensees have a great deal of flexibility in what they can put into a product. They can change, replace or remove the built-in applications, add their own applications and libraries... we give them lots of freedom.
PIC: Is Macromedia Flash a part of the OS5 License?
DF: Not at this time, no. Sony worked with Macromedia on their own, and that's a good thing: we don't want to stand in people's way when they want to add something excellent to their products.
PIC: Is there a timetable for incremental releases down the road, say OS5.1, 5.2, ...?
DF: Sure, but they'd send large men with baseball bats to my office if I told you! Actually 5.1 is already released to Licensees; 5.2 would be the next one. Palm OS 5.0 and 5.1 were both completed in mid-2002, but it is sort of a complicated situation to explain. 5.1 wasn't the traditional bug-fix, incremental release that the version number would imply, and some "5.0" devices have some 5.1 materials. Also, version numbers can change at the last minute. Suffice it to say we work on several things all at the same time: smaller releases as well as big, and we're paying attention to what our Licensees need and when.
PIC: Heh, not that I want to get you roughed up, but can you give us even rough ideas on timing, or forthcoming features? When will we start seeing some of the BeOS platform being folded in?
DF: You didn't hear what I said, did you? :-) We're not just dropping in BeOS components as-is, anyway; they'd be out of place. But you see (well, hear) some of their handiwork on the Palm OS 5 sound manager, and a few other aspects of Palm OS 5, and we're all cooking up some neat upcoming stuff now that their brainpower is added to our mix.
PIC: Heh, heh, well I tried... ...can't wait to hear more on the upcoming stuff ;-)
Anything you want to say about the "next big release" (notice I didn't say "OS6")?
DF: When I was first telling developers about Palm OS 5 at the PalmSource conference early this year, I mentioned the "next big release". That'll be where developers will have new tools and can often benefit from moving their applications to be completely ARM-native. Not all apps will want to; there's clear advantages to working on every device like they can do now. There will be some new abilities that will certainly give business reasons for moving up at some point, and that point will differ from app to app.
The next big release will be really significant for developers; lots of things we've been wanting to add or do for ages, plus features which come from newer requirements or industry developments. We'll be giving developers lots of information in 2003 and we're working hard on planning the developer events.
There will be other smaller but important releases coming out as well. For example we just announced (in early December) that we're going to be releasing Palm OS 4.2 and Palm OS 5.2 both in Simplified Chinese for 68k and ARM devices respectively. Those releases include OS support for "quarter-VGA" screens (240x320) as well. Mostly what that means to worldwide developers is that they'll be wanting to add icons and bitmaps at that 1.5 density - most already have single and double density bitmaps, and now they'll want to add another to look their best. (ROMs and tools are coming soon in the seeding area...)
PIC: Do you expect that the OS5/ARM devices coming out now will be flashable to "OS6"?
DF: That's really up to what the Licensees put into their devices. We work closely with the Licensees so they have the info they need about future OS releases, but it can sometimes raise device costs to ensure they're upgradable, not to mention the costs of administering an upgrade program anyway. Plus, Licensees usually add other improvements such that most devoted PIC readers will want the newer hardware anyway :-)
PIC: Heh, well "want" and "afford" are often two different things! For those of us who can't afford to get a new ARM/OS5 device right away, is the OS5 Simulator available for public download to check out?
DF: Sure. It is at http://www.palmos.com/dev/tools/simulator/
PIC: This has been really informative David, on behalf of all our readers, thanks SO much for doing this!
DF: My pleasure. It is very gratifying to have Palm OS 5 devices out in the market - if developers keep up their pace of making compelling solutions for real people, using the new capabilities we and our Licensees give them, we'll see a tremendous positive change in this and other markets. Exciting stuff, because this is uncharted territory, with so much more potential than what the traditional PC mindset has to offer.
Article Comments
(76 comments)
The following comments are owned by whoever posted them. PalmInfocenter is not responsible for them in any way.
Please Login or register here to add your comments.
Comments Closed
This article is no longer accepting new comments.
RE: Arrrrrgh, blue text!
jeff
The Shadow knows!
I have to agree that the blue text is terrible
RE: Arrrrrgh, blue text!
-Ben
Palm OS5.1 & 5.2
Palm Solutions will need to get moving since they had oS5.1 for sometime, didn't release it and this ties directly into the downsampling issue and no MP3 from Real.
With OS6 coming out the TT better be upgradeable or I will drop them and wait for Dell to come out with Palm OS devices, at least they will be better, faster & CHEAPER.
RE: Palm OS5.1 & 5.2
--
Ben Combee, CodeWarrior for Palm OS technical lead
Programming help at www.palmoswerks.com
RE: Palm OS5.1 & 5.2
Great interview!
It is very nice to know that things are moving steadilly and that PalmSource employees visit this site!
Roman Pedan
Palm V/Vx
Will get a Palm OS 5 handheld
RE: Great interview!
If you want more good info on Palm OS 5, I'd recommend reading Fedor's talk slides from PalmSource 2002. All of the talks are posted at http://www.palmsource.com/about/events/expo/2002/postdev.html
--
Ben Combee, CodeWarrior for Palm OS technical lead
Programming help at www.palmoswerks.com
RE: Great interview!
I have emailed some developers that develop for only the Pocket PC platform and asked for them to port some of their software. A majority said that they are waiting for OS 6 to be released.
If this is the case, then many Pocket PC titles will find their ways into Palm owners hands hopefully next August!
Roman Pedan
Palm V/Vx
Will get a Palm OS 5 handheld
RE: Great interview!
RE: Great interview!
This is an amazing interview that answered most(if not all) of my questions and cleared up a lot of things about OS 5. I can't wait to get an OS 5 device!!
Keep up the great work PalmSource and PIC!!
RE: Great interview!
"I have emailed some developers that develop for only the Pocket PC platform and asked for them to port some of their software. A majority said that they are waiting for OS 6 to be released.
If this is the case, then many Pocket PC titles will find their ways into Palm owners hands hopefully next August!"
GREAT! At that time we will have another 50 or so useful Pocket-PC ported applications to add to the 15,000+ applications we already have! :)
Visit us at www.tdscomputer.com
RE: Great interview!
You write:This is an amazing interview that answered most(if not all) of my questions and cleared up a lot of things about OS 5. I can't wait to get an OS 5 device!!
How do expect to get an OS5 device! If you have problems to get one, probably you should put five or six hunded Dollars in you pocket, walk in an Comp USA or BestBuy etc. shop, give to the cashier your dollars, and than - you will walk out with an OS5 device!!!!!! Itīs just such easy!!!! :-)
You will have an great X.mas day, with playing OS5
Georg
RE: Great interview!
_______________________________________
http://kempokaraterulz.ip2dns.org/
___________________
Wow, do you feel special? Do you want a cookie?
Money can't buy you happiness but it does bring you a more pleasant form of misery.
RE: Great interview!
And again a HUGE Thank You to David, who wrote his responses on his flights to and from China just before the holidays!
Have a great holidays all!
Dan
bogosity alert
In any case, that's not the worst about Palm OS 5. The worst is that it has still the same primitive APIs as Palm OS 4: a non-existent window system, hard coded sets of resolutions, severe limitations on file storage, severe limitations on memory access, etc. Even if you could write native ARM applications more easily, the OS really makes writing more high-end applications a huge chore.
Palm OS 5 is a mostly useless stop-gap measure. And while the Tungsten hardware looks nice, its limited memory means that it will likely be useless for future versions of Palm OS. If Palm doesn't shape up and deliver a decent, modern set of APIs with Palm OS 6 soon, I think they are finished.
RE: bogosity alert
Of course, the latest ARM hardware is still not 100% leveraged until with a more modern set of API and OS 6. Nevertheless, the future is positive and PalmOS is moving in the right direction.
--
With great power comes great responsiblity.
RE: bogosity alert
Do you work in the Tech industry? I do, and I can explain Palms reasoning. Trust me, every company "spins" to this degree, thanks to the dumbing down of America and internet rumor mongers.
Quite often corporate policy dictates that unless you're talking to technical people under an NDA, you don't give answers that the majority of people wouldn't understand, and unfortunately that pretty much limits you to "yes" or "no" when discussing technical details. If you don't answer this way, someone else will "interpret" your answer this way. Even tech-literate magazines publish articles with statements in them that offend the people that the article is about, because in boiling down statements made to feed to the masses, important points get dropped, misconstrued, or otherwise twisted, even if the original interviewer got the idea. The reason for this is if you try to answer a technical question in precise terms, quite often the listeners eyes will glass over long before the explanation is done. I'm not allowed to talk to anyone but the technical departments of our customers at work, for precicely this reason. I don't give yes/no answers, I explain why the question can't be answered with yes or no.
From an engineering standpoint, the answer to this question could in fact be yes or no if those are the only options allowed, as from an engineer's point of view emulation commonly implies hardware emulation, possibly even circuit emulation. Old school EE people would say that if you're not emulating to the circuit/microcode level, you're only simulating. There isn't any emulated hardware on the PalmOS5 units. Second, PalmOS5 itself is pure native ARM code. This is why most hacks don't work. Even in application space, they're not emulating the dragonball, just that portion of the instruction set that applies to user space. Do people make issue out of the fact that JavaVM implementations are emulating some fictional CPU? If you asked Sun if they're doing emulation, they'd say no. The only difference is that the Sun JVM targets a virtual machine that at least originally didn't exist, whereas PACE targets a instruction set that's been around for over 20 years in hardware. The line between emulation and simulation isn't fine, it's grey and wide.
Now, what it mean to a typical non-tech person if Palm said "Yes, we're emulating." It would mean "Oh, no, it's going to be slow and buggy!" I can assure you that it isn't. I've got a few games that I registered that are quite playable on older 66Mhz dragonball PDAs, but on my NX60, are so fast that they were unplayable. Aside from hacks and programs that violated PalmOS programming standards, my NX60 is compatible with more programs than my PalmOS 3.5 HandEra 330. Admit it, there were technically savy people that prior to the release of real PalmOS5 PDAs were claiming that the PalmOS5 PDAs were going to be slower, sometimes even much slower, than existing PalmOS PDAs. That has turned out not to be the case.
They could have said "There is some emulation happening." This would get filtered down to the masses as "Yes."
Instead, they said "no" which while not 100% technically accurate, is at least as accurate as saying "yes" without giving detractors who aren't going to bother checking the facts more ammunition. This is not an accusation that you fall into that catagory either.
I remember a time when companies sent technical people to COMDEX and I could get actual hard information out of people. I haven't bothered going to COMDEX in years because of this effect, since most companies don't send anything but sales people any more (with the possible exception of someone to work behind the scenes in case a demo fails).
RE: bogosity alert
I think Palm delivered backward compatibility beyond what I expected.
RE: bogosity alert
(mj6798 - is that the line that inspired your "bogosity/spin/sleezy politicians" remarks?)
That was merely my summary understanding of David's description of PACE. Granted, my expertise is much more on the hardware side, not the inner workings of the Palm operating system and precise definition of emulators. I may have misunderstood and misstated; maybe not. I'd like to know.
I don't know if David will be monitoring this article over the holidays and have a chance to clarify things, but assuming not, perhaps someone reading this page who DOES have a deep understanding of PACE and emulators in general can lay this out for PIC readers (skeezix - you there?? :)
Peace on Earth, goodwill to Netizens.
Dan
No bogon zone.
If we can try to distill and collect any follow-up questions here, maybe we can convince David to do a return visit in the new year? :)
One of the finest things about this site IMNSHO is that the community here works to explore and clarify issues. This is a good opportunity!
[Raising a mug of eggnog]
Cheers,
Dan
RE: bogosity alert
No, it's not your fault; Palm has been trying to cloud this issue since day one, and they are succeeding.
There is nothing wrong with delivering backwards compatibility through an emulator. Apple has done it, and so have other companies.
The reason why Palm is trying to cloud the issue is because an emulator is all they are delivering; other companies doing the same thing have usually given users the ability to emulate the old environment while developers could deliver new, native applications.
The Tungsten is a reasonably nice industrial design. It may be worth $500 just for its size and Bluetooth support. But the fact that it has an ARM chip is pretty much irrelevant given the current state of Palm OS 5.
My recommendation would still be: don't bother with the Tungsten--get one of those nice 320x320 Sonys for about half the price.
RE: bogosity alert
Why do you think people don't bother checking the facts anymore? If most companies are lying or trying to mislead you about their products, then there is no point. But that still doesn't make it OK on the part of companies.
"Second, PalmOS5 itself is pure native ARM code."
So? When I run VirtualPC on the Mac, Mac OS is running in native code. When Macs were running 68k applications on PPC, that's what they were doing. When I run Bochs or POSE on Linux, Linux is running in native code. PACE is no different.
"Old school EE people would say that if you're not emulating to the circuit/microcode level, you're only simulating. There isn't any emulated hardware on the PalmOS5 units"
We aren't talking old-school EE people, we are talking about modern software consumers and developers. There is a pretty wide understanding of what "emulation" means: it's what all those other systems that I mentioned above do as well.
"They could have said "There is some emulation happening." This would get filtered down to the masses as "Yes.""
And the masses would basically be right. The Tungsten is a nice handheld, but you are buying an ARM chip to run applications in emulation. I think at $500, that's too much, in particular since there are plenty of other ARM-based handhelds that run their applications natively.
Note that I think Palm's basic mistake was not that they are providing emulation, and pretty good one it appears, but that they are failing to provide the ability to deliver fully native applications. And that makes Palm OS 5 a bad and overpriced choice in my book. My recommendation is to go with Sony's Palm OS 4 devices for now: they are a much better value.
RE: bogosity alert
>
>So? When I run VirtualPC on the Mac,
>Mac OS is running in native code.
Yes, Mac OS is running in native code (well, more or less of it may actually be 68K emulated code depending on what version of Mac OS you're talking about). However, the Windows (or whatever) operating system you're running *inside* Virtual PC is *fully* emulated at the x86 instruction level. So, every x86 instruction in both the application AND the operating system itself is emulated by the Virtual PC code on the Mac's PowerPC processor.
>When Macs were running 68k applications
>on PPC, that's what they were doing.
Actually, that's not exactly true. When Macs were running 68K applications on PowerPC, the applications were emulated, but they were calling through to a single copy of the Mac operating system -- some of which was also emulated, and much of which was re-compiled to be PowerPC native for better performance. An emulated application that called into PPC-native Mac OS APIs would typically run much faster than emulated code that tried to do all of the work itself (in 68K code).
However, it's important to note that Mac OS was *not* 100% PowerPC native. Only certain portions of Mac OS were recompiled to be PPC native -- the rest of the OS was 68K code and ran in the emulator just like the 68K applications. In addition, hardware interrupts caused (at least one) round trip into and out of the slower 68K emulator "mode" (among other reasons) to avoid the possibility of interrupting the emulation of a 68K instruction. This happened on every interrupt, even if the processor was executing PPC-native code when the interrupt occurred. [This may be a bit technical for some folks, but bear with me for a moment...]
Contrast that with Palm OS 5 on ARM: The *entire* Palm Operating System (which is almost entirely written in "C") was recompiled into 100% native ARM code, including exception and interrupt handling and all hardware drivers. PACE is essentially an ARM application that sits on top of the native OS, and is used *only* to run 68K applications -- that's why it's called the "Palm *Application* Compatibility Environment". It emulates the 68K application code, but most applications spend much of their time either waiting for the user to do something, or making calls into the fully ARM native Palm OS. The OS is where the User Interface APIs, the Memory and Data Managers, communications libraries, floating point engine, etc. all reside, and they're all fully ARM native.
>When I run Bochs or POSE on Linux, Linux is
>running in native code. PACE is no different.
Yes, Linux is running in native code. However, POSE is a Linux (and Mac and Windows) application, which contains pure 68K instruction emulator, which uses a 68K device ROM and emulates a Palm OS device at the hardware register level. Hopefully after reading the above, you may now see how this is *very* different from what PACE is. PACE does not need a 68K Palm OS device ROM, nor does it contain (or emulate) any 68K Palm OS code. PACE does not know (or need to know) about how real 68K hardware devices work.
In summary, POSE is more like Virtual PC in that they each run both emulated applications AND an emulated operating system. PACE runs only emulated 68K applications (not the OS). It is in fact an API translation layer between the emulated applications and a fully native ARM-based Palm OS.
For those developers who wish to take advantage of some of that raw ARM horsepower, it's certainly possible to do so. Check out Kinoma Player, Mapopolis, SplashPhoto for some great examples of apps that take advantage of the ARM while still being able to run on 68K devices. In addition, it's also possible to write applications like XCade that require ARM-native performance and just aren't feasible on the 68K.
By the way, I'm an engineer, not a marketing person so I apologize if this is too technical or confusing (or too long-winded) for some folks. This is not marketing fluff or "spin", but the technical details some folks have asked for.
That said, I think people should decide for themselves if a particular device is right for them by actually trying it (if possible) -- it kind of reminds me of buying hi-fi speakers: some folks shop online or in a catalog for speakers with the best specifications, while others listen to various models and buy the ones that sound best.
--Steve
RE: bogosity alert
I guess I can stand by my non-technical summary statement "OK, so it's more of an on-the-fly Translator, rather than an Emulator." :)
Hoping you and your family have a wonderful Christmas!
Cheers,
Dan
PS I was just checking the latest AcidImage (v2.2t) which uses Arm-lets for native jpeg handling and it's wickedly fast: http://www.red-mercury.com/aibe.html
RE: bogosity alert
How the heck do you figure that "an emulator is all they are delivering" when OS 5 also means unified hi-res graphics API and new sound API?
>>other companies doing the same thing have usually given users the ability to emulate the old environment while developers could deliver new, native applications.
And what do you think ARMlets are? Oh yeah - they allow for native code execution to boast performance of Palm OS applications on OS 5 devices. Obviously its nicer to have a totally new API with complete ARM support (and updated dev tools to go with it). But honestly - there is very little limiting developers from doing just about anything you can think of - ARMlets allow for the speed.
RE: bogosity alert
I'm sorry, but you don't know what you are talking about. I/O and drivers in Virtual PC and VMware, of course, happen through the host operating system in native code because only native code can talk to the actual physical device.
There are three ways in which guest operating systems can talk to those devices. First, through I/O ports using the native driver of the guest OS. That's slow. Second, through special shim drivers in the guest OS that just hand off the request to the host OS. That's fast and equivalent to what PACE is doing. Third, through DMA using the native drivers of the guest OS. That's just as fast as the special drivers.
"which contains pure 68K instruction emulator, which uses a 68K device ROM and emulates a Palm OS device at the hardware register level. Hopefully after reading the above, you may now see how this is *very* different from what PACE is."
No, I don't. What you call "operating system" is just a bunch of application libraries that happen to be bundled with the device: some GUI stuff, some in-memory databases. Sure, PACE runs some of that code natively.
"That said, I think people should decide for themselves if a particular device is right for them by actually trying it (if possible)"
Yes, they should decide for themselves--after they have heard all the arguments. Most people, however, just get to hear the marketing fluff from Palm. You seem to want alternative views to shut up.
I maintain: $500 for the Tungsten T is too much, compared to both Sony's OS4 devices and the variety of PPC devices out there. Furthermore, Palm's claims that the Tungsten T will be upgradable seem dubious given its limited amount of memory, and whether Palm OS 6 will be decent or a dud remains to be seen, as well as whether it comes out before Palm goes under.
My recommendation is: save your money and buy a Palm OS 4 device. The Sony SJ30 is a great little handheld that makes as good an organizer as the Tungsten. Put off buying an ARM-based Palm until Palm delivers a more coherent platform than OS 5.
RE: bogosity alert
ARMlets don't allow you to deliver native applications, they allow you to deliver 68k applications with ARM subroutines.
"Obviously its nicer to have a totally new API with complete ARM support (and updated dev tools to go with it). But honestly - there is very little limiting developers from doing just about anything you can think of - ARMlets allow for the speed."
Yeah, it's all only a "small matter of programming". Many projects and developers have neither the time nor the resources to develop special purpose ARMlets for the Palm OS 5 platform. And all that effort will be wasted anyway when Palm OS 6 comes out.
And that's my point: OS 5 is a stopgap measure for Palm to be able to ship ARM hardware now, but it's a poor solution for both developers and end users. Get an OS 4 device for half the money or wait for OS 6 and see whether that is any good.
RE: bogosity alert
"which contains pure 68K instruction emulator, which uses a 68K device ROM and emulates a Palm OS device at the hardware register level. Hopefully after reading the above, you may now see how this is *very* different from what PACE is."
No, I don't see that. Sure, PACE runs a bunch of libraries natively, but so do many other emulators. Other emulators do that by translating it into native code on the fly. That is insufficient reason to call "PACE not an emulator". "Emulator" doesn't mean "interpreter".
(I also disagree that those libraries should be considered part of the operating system: they are application support libraries, stuff that runs in user mode and needs no special privileges.)
RE: bogosity alert
ARMlets are pretty damned handy and make a lot of things possible. They are not wasted effort, nor are they really difficult to make.
So whats wrong with making a 68k app with ARM subroutines? Its not a big deal theres a 1k 68k app at the front and the rest acvn be all ARM code? Woopee.
As a user, why do you care what is going on.. you just care abotu the services delivered. As a developer, this is all great stuff, so we can deliver apps for both ARM and non-ARM units.
Palm OS 5 is a stopgap, but its a good one. You think any other OS hasn't done stopgaps? We call it "upgrades" normally. Get over it :)
jeff
The Shadow knows!
RE: bogosity alert
In my personal experience, I've used and love Palm OS based PDA's because of the ease of use and peace of mind, not caring about API's and emulation or what have you, as long as I can work and play without fuss. Yet, despite being satisfied, I still yearn for something more once in while depending on my needs/wants. In this case, it was in the way of higher resolution, integrated Bluetooth to free up memory expansion slot, and voice recorder while maintaining the best, IMHO, form factor out there. Sure these are all luxuries, but if it makes my life a little easier and fun, I'm all for it.
But when I consider upgrading, I rarely find myself asking if it still uses primitive API's found in vOS4 or whether it will be emulating instead of other programming methods to ensure backwards compatibility with programs I've already paid for without breaking them. I just want to know if it works and runs faster. And if the answer is a resounding 'yes,' with all the extra features I want (and then some), that's all I need to know. Does it really matter if the task is completed using a "stop-gap" measure?
The SJ30 certainly comes close with a great price of MSRP $250 and good form factor. Unfortunately it does not have voice memo, or integrated BT, let alone the option for audio playback via headphone jack (though as an added accessory, it might). The DragonBall processor is fine, as I've had no complaints so far, but I've noticed that Docs2Go (which I uses daily for work) run much faster on my Tungsten, than my m505 ever did, so productivity in my eyes is higher. And with BT MemStick almost non-existent in the U.S., you're sure to spend at least a good ~$200 just to get it, at which already puts the SJ30 along the same price tag of the Tungsten.
It's great to be informed, as I've learned a lot today, but that still doesn't change my mind about the Tungsten|T, or any future PDA (Palm or other), based on whether the OS which runs the PDA is native or not, which are totally transparent to me anyway, as long as it fits my needs TODAY. Otherwise, I'll be waiting forever.
I'll admit that I've spent a little more money on the Tungsten|T than I would've liked, but that's the price to pay for "me first" in technology, isn't it? Value is in the eye of the beholder, not the API's in the OS (er.. that is, unless you're a developer/engineer, but I suppose that's another story ^_^).
Maybe this whole thread should've been taken place in a Palm developer's forum? :/
Jim
RE: bogosity alert
And let's not forget here, that even if OS5 is "nothing but emulation" -- it can at least take more advantage of the XScale's power than Pocket PC seemingly and currently can.
RE: bogosity alert
I said that writing ARMlets will be "wasted effort", not that they will be "broken". The effort will be wasted because Palm promises that in Palm OS 6, you can just compile your applications into all native ARM code directly.
"So whats wrong with making a 68k app with ARM subroutines? Its not a big deal theres a 1k 68k app at the front and the rest acvn be all ARM code? Woopee."
That's not how it works. You can't just write all your application in ARM code and call it from a 68k shim. There are lots of restrictions on what you can do from ARMlet code. Codewarrior tried to work around that a little, but it's still a chore. And if you are using other development tools, there is no easy workaround at all.
"Palm OS 5 is a stopgap, but its a good one. You think any other OS hasn't done stopgaps? We call it "upgrades" normally. Get over it :)"
Some OS upgrades are worthless, and some are worse than worthless because they require expensive new hardware to be purchased without giving you many new capabilities that you would care about. Palm OS 5 falls into that category in my opinion. Get a Sony SJ-30: it does everything you might want to do on a Palm for half the price of a Tungsten.
Click here for the full story discussion page...
Latest Comments
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
Arrrrrgh, blue text!
In the future, using bold/non-bold (or non-italicized/italicized) text for the questions/answers would be much easier on the eyes.