Why isn't this thread on handspring-forum?
Anyway, since we're speculating:
* Assuming that Handspring *does* have a 16-bit device (I haven't seen any
official announcements and don't see anything on their web site about it), I'd
guess that Handspring is using a custom LCD controller instead of the Dragonball
controller. The latter doesn't support 8- or 16-bit LCDs. That's why we use the
SED 1375 in the Palm IIIc.
* The custom controller probably has dedicated video memory. This, again, is
how the SED 1375 works.
* The LCD frame buffer probably uses direct RGB values for pixels instead of
table indexes and a color table. Each 16-bit value in the frame buffer has RGB
values encoded in 5-5-5 or 5-6-5 format.
* I'm not aware of ANY displays greater than 8 bits that use color tables. I
expect that they may exist, but they're rare enough that I've never encountered
one. So you don't have to worry about 192K color tables.
* Creating large offscreen buffers may be tricky since you quickly run out of
dynamic heap space. However, since the actual buffer allocation is performed by
WinCreateOffscreenWindow, you don't have to worry about *how* the OS allocates
chunks > 64K...you just have to know that it can do it.
-- Keith
Tom Zerucha <[EMAIL PROTECTED]> on 09/28/2000 09:05:54 AM
Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent by: Tom Zerucha <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
cc: (Keith Rollin/US/PALM)
Subject: Re: 16 bit color Handspring Prism and chunk size limit
On Thu, Sep 28, 2000 at 01:45:24PM +0200, Linke, Andreas wrote:
> As mentioned before, Handspring is supposed to unveil a PalmOS device with
> 16 bit colors RSN.
>
> Given the 64 KB chunk limit, how would one cope with that screen depth?
>
> A 16 bit color table would be at least 192 KB in size, i.e. not fit in a
> single chunk. Even if they only support a fixed color table, IMHO it must
> fit in a single chunk.
> A 160x160 screen in 16 bit colors would take up 51.200 bytes, i.e. one
> wouldn't be able to create off-screen windows much larger than the actual
> screen.
>
> Any ideas?
> Andreas
I really wish they would say, but it is possible that they are using
dedicated screen memory (so how do I do Offscreen bitmaps), but 3.5
does have a FtrMem call or something that can allocate more than 64k
at once.
It also might be 16 bits DEEP but selected from a 256 byte colormap,
though I suspect they would do a 24 bit cmap since that wouldn't be
much harder (though the LCD might only do 5-6 bits).
Or they may have a vid chip. Basically if Palm does a multimedia
device, they should add a DSP for sound (with uploadable MP3 or synth
programs), but have it use no power when off, and a Blitter chip (or a
68020+ core with bitfields) that would do the dirty work of drawing
lines, fonts, rectangles, etc, and also use practically no power when
idle. Or maybe they are moving to a 68xxx core with MMU so they can
do the page protection and remapping to assemble enough memory for the
16 bits.
Or maybe that is the ARM device that people have been whispering about
so it isn't our PalmOS.
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
