Slashdot Mirror
Handspring's New Palm-OS Entrants: Color and Speed
ResQuad writes: "Handspring realeased a new palm top in their Visor collection, the Prism. It is $450 and have 65k colors, compared to the 3c's 256 colors. It also has an internal Li-Ion battery. Handspring also came out with another new palm, the Platinum. It is still gray-scale, but it is suposed to be 50% faster that the Visor Deluxe. This makes four palms out from Handspring." These are the same models discussed a few weeks ago, but now Handspring claims that they're shipping. Personally, I'm still pretty happy with my Deluxe, but the Platinum one looks very nice.
Be careful here. You may be slightly misled by the 'photos' of the Visor.
The Prism looks awesome in the photos, but remember that the resolution is ONLY 160x160 -- the same as the Palm IIIc. For those that have seen the IIIc, you will remember that it has a very grainy resolution.
Although the Prism does have a higher color depth, and uses TFT color, unless the screen has a tighter dpi, you will probably find that it is only marginally better than the IIIc. Also, remember that it is thicker and heavier than a regular Visor.
Be careful buying this blind -- I'm very interested in seeing a real one up close, in both indoor light AND outdoor light. As far as color goes outside, I have only seen 2 color LCDs that really work well outside -- the Sony hybrid LCD on their digital camera, and the Compaq IPAQ. The rest wash out completely.
But it's not virtual. So even if you maxed out the Dragonball VZ's DRAM controller with 64M, you'd still need some way of controlling fragmentation etc, because you don't have a hardware MMU to shuffle pages around.
Why is controlling fragmentation important? Old Amiga hackers remember the pain of programs refusing to load, not because you didn't have enough memory left, but because you didn't have enough contiguous memory left. (If an app is expecting to be able to malloc a meg, the OS can't really reply "would you take two 512k chunks instead?".) That kind of behavior sucked back then, and it would suck even more on a PDA that stays up for weeks at a time.
The most reasonable way to solve fragmentation on a 68000 is to address all memory through handles. Load up a raw 32-bit pointer to the start (or middle) of a chunk of memory, then do all addressing based on offsets from that pointer. Whenever nobody is using a chunk, the OS is allowed to move the data and the pointer---after the move, the data, relative to the pointer, will be in the same place.
This is not a very Unix-y memory model. This is why nobody has ported perl to PalmOS. You'd have to change everything that assumed that a single 32-bit pointer was enough to access memory. Even if you could convince PalmOS to give you, say, a contiguous 2M chunk to use for malloc, and lock that region down forever (don't want pointers in there moving out from under us), you'd be back to the original problem of fragmentation.
A 2M chunk would be unnatural for another reason. Until the 020, 68000 addressing modes can only reach +/-32k from a register. Plop your chunk pointer in the middle of a region and out pops...that 64k limit you're always seeing in PalmOS hacking. If you're willing to take the performance hit, you could *manually* add 32-bit offsets to an address register (and give up the offset addressing mode). But pretty soon this starts looking just like the near/far pointer tar pit from the bad old 8086 days.
The newer versions of PalmOS are also moving closer to processor agnosticism with a HAL, which will sever its dependence on the DragonBall Series (MIPS, anyone? How about an IPaq, then? Mayhaps even Crusoe...).
I still can't figure out what they're going to do to move beyond 160x160 or 160x240 screens. Those hundreds of third-party apps are almost all using absolute pixel positioning for form layout. Wait...I have an idea---what if we redefine old pixel positions as really being dimensioned in "dialog units", and...wait, nobody would actually do that...
Unlike Microsoft, Palm is changing and eliminating its OSes primary weaknesses rather than saddling its developers/users/customers with archaic requirements, just like a company in a competitive market should.
So, what should Linux people be doing? Sitting back and waiting for Palm to be the source of All Good Things?
http://www.zdnet.co.jp/macwire/0010/16/r_viprfi.ht ml h tml
http://www.zdnet.co.jp/macwire/0010/16/r_viprfi2.
If your Palm 3 eats up its batteries, there's a few things that you may want to check:
- Leaving the Palm (only for units running on alkaline batteries) in its cradle drains the batteries. There's a *very* easy fix for that (a wire to cut in the cradle). You can find detailed instructions here
- Perform a warm reset, it often solves lots of problems. There's plenty of info on usenet, and I strongly recommend comp.sys.palmtops.pilot, there's heaps of guys who probably have all the answers to any question...
On average, my Palm IIIx runs about 18 hours on 2 AAA el-cheapo alkaline batteries, about 45 days of use. I once managed to run the beast a whoping 34 hours on a pair of the same batteries. Uptime hack is pretty handy, and once you get to know your batteries' discharge curve you can really guess how long they'll last (I have found many variations, even between batteries from the same pack).
Nevertheless, I really wouldn't mind a Palm Vx. The lithium-Ion battery is a dream to use, and if you know how to use them properly (recharge them as often as possible, never empty it totally and never, ever, leave the device usused with an empty battery).
Cheers,
/max
-- It's always darker before it goes pitch black.