>From what I've seen, here's a description. I've posted much of this stuff
before, but here it is from a slightly different angle...
Starting with OS 3.1.1 on the Palm IIIx, IIIe and 3.1 on Handspring Visors
devices, the LCD controller's refresh rate is set differently depending on
whether you're in grayscale mode or in black in white mode. Basically,
the refresh rate is faster in grayscale mode than in black in white mode.
In general, here are the effects of the refresh rate on what is being
displayed:
1. The first characteristic (don't know why this is) is that at the
faster refresh rate, you need a higher contrast level. This is
what you're seeing. If you turn up the contrast manually, the screen
will look normal.
2. If you're running at a high refresh rate, black and white stuff looks
streaky (you see ghosting for vertical lines). The CPU also runs a
little slower, since the LCD controller steals the memory bus more.
3. If you're running at a low refresh rate, you see flickering in
grayscale mode.
...notice that on the Palm side, I refer specifically to the IIIx and the
IIIe. That's because (from what I've seen--I don't swear by this fact),
the Palm V can run fine always at the low refresh rate. Basically, you
don't get the flickering in grayscale. That's because the Palm V has a
slightly different screen.
Now you know about the LCD controller. Next, contrast controls. The Palm
IIIx and IIIe have a hardware pot. on them (a little wheel on the side)
that controlls the contrast. I don't think (another questionable fact)
that there is any way to control the contrast on the IIIe and IIIx by
software. The Palm V and Visor both have software contrast control.
Finally, onto the software on the device. What happens when you switch
from one screen mode to another. I will cover IIIe/x on 3.1 and 3.1.1 (I
don't know what happens on 3.3, sorry). I will cover the Visor on 3.1.
IIIe/x, 3.1
-----------
Always runs in high-refresh rate mode. Grayscale is fine. Black and
white is streaky. No problems switching from gray to black and white.
V, 3.1
------
Always runs in high-refresh rate mode. Grayscale and black and white are
fine. Whenever you switch between black and white and grayscale, for some
reason switches back to default contract (bug?) (see below)
IIIe/x, 3.1.1
-------------
Runs in high-refresh rate mode in grayscale but low-refresh rate mode in
black and white. I believe that you have to physically adjust the
contrast, but I'm not sure.
V, 3.1.1
--------
See V, 3.1 (except that it's in low-refresh rate I think)
Visor, v.1
----------
Runs in high-refresh rate mode in grayscale but low-refresh rate mode in
black and white. IMPORTANT: When you switch from black and white to
grayscale, the OS moves the contrast for you. Try going into a
well-behaving grayscale app and notice that the contrast is higher.
Now, onto problems
------------------
* If you try to much with the CPU registers directly, you're in
trouble. Always use the ScrDisplayMode() call if possible.
* If you try to work around the fact that the Palm V always resets
the contrast when you switch to grayscale mode (by saving the
contrast and the restoring it), you screw up the Visor, since it
not only preserves the contrast, it actually adjusts it for you
(which is one reason you might get the washed out look).
That's about it. Sorry that I'm not positive about all the details, but I
just didn't have a chance to go find all the devices in question and test
them all under all the OSes. This would be a great FAQ / knowledge base
thing...
BTW: some of my early investigation of this led to a DA that I wrote:
FlickerFixDA (includes source code).
http://www-cs-students.stanford.edu/~dianders/palm/
---
On Fri, 14 Jan 2000, Bryan Nystrom wrote:
> We have implemented an application which utilizes the grayscale calls talked
> about in the "Seeing Gray" papers. The application look absolutely GREAT on
> the PalmPro, III, IIIx, and V that we have. Unfortunately, on our Handspring
> Visor, the application is hardly usable. The entire screen is "washed out"
> and streaky. I know of other software authors ( the developer of
> ImageIII???), that have had to deal with the Visor hardware specifically in
> order to get grayscale to work properly. Does anyone have any pointers on
> problem? Does it have to do with the fact that the Visor is running 3.1 and
> the other devices are at either 3.0x or 3.3? I would hate to have to back
> out all of the software changes for grayscale and use patterns just so that
> it works on the Visor.
>
> Regards,
> Bryan Nystrom
> Natara Software, Inc. http://www.natara.com
> ICQ: 2526059 (630) 579-0958
>
>
> -----Original Message-----
> From: Bryan Batchelder [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 14, 2000 11:53 AM
> To: [EMAIL PROTECTED]
> Subject: RE: TCP/IP vs. ping
>
>
> I know on almost every server I admin, I shut down echo ports due to
> security issues.
>
> --B
>
> > -----Original Message-----
> > From: Scott Lopez [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 13, 2000 8:17 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: TCP/IP vs. ping
> >
> >
> > I'd say this really depends on what you are trying to do.
> > For security
> > reasons, including windows, the SOCK_RAW parameter is not
> > accepted, only in
> > winsock2 was this changed and the only supported raw types
> > are a limited
> > version of ping and traceroute.
> >
> > My question is, are you trying to figure out if a system is
> > alive? If the
> > server supports ping, then open a connection to the ICMP
> > "echo" port on the
> > server, if you connect then you will know that the system is
> > alive. Two way
> > communication must occur for a socket to connect with TCP/IP.
> > Ping or echo,
> > simply receives data and regergitates it back out to the
> > socket, connecting
> > a socket performs almost all of these steps.
> >
> > Echo is supported on port 7 and both UDP and TCP are supported.
> >
> > BTW, the purpose of a raw socket is to allow the programmer
> > to modify what
> > is sent in the headers of the packet. Primarily to support
> > new protocols
> > over IP such as multicasting, etc.
> >
> > ----- Original Message -----
> > From: "Bryan Waters" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, January 13, 2000 9:46 PM
> > Subject: RE: TCP/IP vs. ping
> >
> >
> > > Without the raw sockets support, it is NOT possible to
> > perform a ping...at
> > > least not short of writing your own TCPIP protocol...
> > >
> > > -bryanw
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, January 13, 2000 9:40 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: TCP/IP vs. ping
> > >
> > >
> > >
> > >
> > > I need to implement a "ping" function on the Palm.
> > According to Article
> > > 1141 in
> > > the Palm Knowledge Base, "... PalmPilot supports the TCP and UDP
> > > stream/datagram
> > > layers of the internet. The raw socket interface is not
> > supported. As a
> > > result,
> > > applications cannot implement a ping protocol." The
> > article goes on to
> > > describe
> > > the Berkely Sockets API and the PalmPilot Net Library API.
> > Can someone
> > > clarify
> > > for me whether it is, in fact, possible to perform a ping
> > function in some
> > > way?
> > >
> > > Thanks,
> > > Barb
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
