Comments on: Sony Will Drop Proprietary Hi-Res API in OS 5 Handhelds

R u sure your alright?

If Palm isn't going to step up to the plate, then Sony should. I believe Handspring made thier own API for 16-Bit color and that became standard. I guess I don't see whats so stupid about that....

To Larry....try to obstain from insults with no backing. It just makes you appear to be stupid yourself.

Could you please explain then? As far as I understand, the current API's in Palm OS5 do not support VG or highres+.....is that not correct?

We need Resolution independant API's like Windows has

I have seen pretty minimal incompatabilites currently with software on the 330, so I don't know what you mean by this. As far as the future goes, HandEra could support hi-res on the 330 using the methods/APIs Palm is using in OS 5, but would require an OS update. The way hi-res works on the 330 already isn't that much different than OS 5 anyhow, so I think the future is bright in that sense.

I THINK it should be possible for an enterprising developer to make a shim that will look like the sony API, but map it to the Palm OS API. If you've ever used the sony API, it was just identical to the Palm OS API except it used 16-bit values for pixel row/column instead of a byte (which isn't sufficient for 320x320) and 32-bit values for bitmap sizes as opposed to 16-bit values. The API lives in a library. All you'd need to do is write a library mimicing it, that turned around and called the Palm OS 32-bit library. From the docs, it looks like the calls are pretty much the same. They just live directly in the OS, rather than in the sonyhr library.

As someone else said, it does. I believe Palm phrases it as something like: they will support 320x320 in OS 5 but other licensees are open to provide their own [including non-square] solutions. It is not the big deal some are making it out to be. I read it as the solution PalmSource will provide to its licensees will include support for 320x320 and it's up to the licensee if they want to add in support for something else. Current Sony owners should be more concerned that they will slowly (or maybe quickly) lose hi-res support in updated and future apps on current devices.

Ahh - no. It was mentioned here on PIC.

I think future versions of the Palm OS will have a digital graffiti area standard. But OS 5 is about porting the operating system to ARM chips, not remaking the UI. That comes later.

Actually, in terms of **usable** screen space the PPC is better. 320x320 doesn't (generally) mean double the amount of "lines" shown in a datebook or address book application. It just means the lines are drawn with more and smaller pixels.

I agree I would rather see a 240x320 device -- or at the very least 320x320 with virutal graffiti.

-Kevin Crossman

I think you guys are missing the point. We are talking about improved 'screen real-estate' - not nescarily resolution. That is, by increasing the length of the screen so its not square (ie 50% longer) - you get a screen that is more readable and less cramped because you have more 'physical' space. Of course, you could just make the square screen larger but that screws up the form factor of the device - which is why ppc,sony, and handera opt for a different ratio instead. And if you've used any of these devices, you'll notice right away that it feel MUCH LESS cramped then a standard Palm OS device. I can't believe Palm wouldn't support virtual graffiti in OS 5. Can anyone verify this? Is this really true?

However, crippling the ability to write native ARM code to take full advantage of multimedia, etc. is a disturbing revelation, to say the least. I thought OS 5 was going to be a bridge to fully native ARM apps with a way to make existing apps compatible, with only minor UI tweaks, but I guess not. All I can say is that OS 6 better be CLOSE behind and the new ARM hardware released this fall had better be flashable and fully upgradable to OS 6! This is looking more and more like OS 4.5 rather than 5.

The OS calls are fully native as far as I understand. Any multimedia calls made will be calling ARM code.

it emulates 68K too.

What exactly is the real advantge of OS 5.0? it sounds more and more like 4.0 patch running on Arm, with some minor up date like color option UI and sound ability.

Might as well get Zaurus than.

You will see hybrid 68K/ARM apps in some key categories once the devices are out. I fully expect to see action games, video playback apps, graphic demos, and more take advantage of it. Even PalmSource is taking advantage of it in little ways -- the new DateBook in OS 5 uses ARM code to perform fast sorting. One of the winning hacks at PalmSource 2002 was John Marshall's fast Mandelbrot generator running in mixed 68K/ARM code on a Palm OS 5 development board.

--
CodeWarrior for Palm OS technical lead
Programming help at www.palmoswerks.com

The fact that the NR series is based on OS 4.1 and therefore the "old" APIs hardly makes it obsolescent. It still has virtual graffiti, multimedia capability, and more functions than even the first OS5 machines will have. I would expect major developers will still support it for some time, especially with its current lightning-fast sales. What's more, the fact that OS4.1 is well-established will actually HELP it. Which would you prefer: a machine that does just about everything you could ask using a tried-and-true OS, or a machine that, while new, has a good chance of being "buggy" and less stable?

I know what my answer is...I just hope the price comes down soon.

I am not worried because I figure Sony will find a way to use virtual graffiti despite the rigidity of PalmOS 5 vis a vis resolution. Some API modifications should do it.

I worry because I am a software developer and I can't figure out what the hell I'm supposed to do. I don't want to roll out upgrades every time someone comes with a device with a previously unknown screen resolution. I don't want to have to write weird special cases for every single device under the sun. That's what operating systems are supposed to shield me from. I can write applications for PocketPC or Linux handhelds and they run across a wide variety of screen sizes. It's just Palm that's stuck with such pre-historic APIs. Come on, guys, the Apple ][ days are over.

They've done that already in OS 5. Height and width are now independant variables everywhere in the API, and the size and pixel offsets, etc., now support values > 160.

That is all that the Sony API did, was replace the "broken" API's that wouldn't work at resolutions > 160. Sony didn't replace the whole graphics API.

Also, for the record, the Sony Virtual Graffiti API on the NR70 isn't attached to or a part of the Sony Hi-Res API. The new PalmOS 5 API should fully support a hidden graffiti area, since all that is required is that horizontal res not be tied to vertical, and height and widths > 160 be supported.

The only way the graphics calls change when the graffiti are is hidden, is that "current resolution" queries return > 320 for the vertical value, and "y" values > 320 work on output.

That was true in OS 3.x. See a HandEra 330 for an example.

> That is all that the Sony API did, was replace the
> "broken" API's that wouldn't work at resolutions > 160.
> Sony didn't replace the whole graphics API.

I would say that is a relatively inaccurate statement.

> I wonder why we all keep making excuses for Palmsource's
> half finished code in the areas of resolution and VFS,
> saying it can't be done, when it's BEING done.

I would say that PalmSource's code is far more than half finished. When it comes to hi-res, the real issue isn't the APIs, it is the development tools. The development tools are all geared toward creating, essentially hand drawn, 160x160 apps. That's great for drawing up a simple GUI, but not necessarily for anything scalable to other resolutions.

I would suggest you do considerably more thinking before you keep posting. All coordinates have been 16 bit values for some time now. How exactly do you think the 320 pixel dimension on the HandEra 330 is supported then?

You are so kind when you hide behind anonymous posting...

Ok, I just double checked and type Coord is indeed a UInt16, not UInt8, like I thought, but that just means there is even less work to do to get the API to work.

To be honest, I think what most people are thinking about related to "non-square" support is with the forms manager, and the fact that you can't just design two versions of a form - one to fit 160x160, and one to fit 320x480 (insert your favorite non-square [virtual graffiti] res here), and have the OS simply pick the right one for the current display mode.

The problem with that is really that there isn't a standard resolution or even set of proportions for a non-square "form" on palm, and I doubt PalmSource is planning on setting one any time soon.

I have no desire to get into a flamewar on whether HandEra's API enhancements are better than Sony's API enhancements, or anything of the sort. In fact, I expect many more permutations of the resolution before any standard gets established. That is what worries me the most.

The NR70V is probably superior to the first PalmOS 5 device that Palm will release. Of course Sony's first OS5 device will beat the NR70V, and hopefully some of the older players like Handspring and Handera will surprise us with a cool OS5 device.

But even so, OS5 is basically a patch for OS4 and the differences will be minimal (read these threads), so you won't be missing much by going with an NR70V.

no wonder you are conformable with that STANDARD SUDS m515

Not with OS 5, it requires a different CPU than is in the current NR series. They could provide OS 4.x updates, but Sony has provided very little in the way of OS updates for their devices in the past.