While I agree with you in general, let me disagree on this particular one.
ScrDisplayMode may have been put there with a good intention and for proper
reasons, but while I have to do the rest of the job myself with the
registers and *not* using the standard API it does not make much sense. I do
not know if you should blame me for not using something that's done by half,
but doing it from as low as I can myself. Either approach has its drawbacks.
The example maybe isn't the best approach for display mode change, but it
shows several things that I think may be useful, like where and how to
allocate screen buffer.
The upcoming grayscale API from Palm Computing is something different and
good to hear about. I would gladly stick to it if it provides me with what I
need for my projects.
I only wonder what these of us who can't attend PalmSource (something makes
me think this is the majority of the forum) should do...
Just my two cents...
Bobby
-----Original Message-----
From: David Fedor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, September 07, 1999 12:30 PM
Subject: Re: EZ Grayscale Palette register
>As I just now posted to a different thread, don't just go slamming the
>processor around without doing OS and processor checks first. Otherwise
>you risk looking silly when a future OS revision or new hardware
>demonstrates problems with your method that you couldn't know about yet.
>
>The code you just posted to switch back to one-bit mode is particularly a
>bad idea, since there's an OS trap to do it the right way:
>ScrDisplayMode(). Less code, guaranteed compatibility, how can you lose?
>
>And what if the system doesn't support one-bit mode? Serious shooting
>yourself in the foot if you use that hacky code. ScrDisplayMode lets you
>just go back to the default mode - a much, much better idea.
>
>I wonder how many times I'll have to post things like this, before people
>start remembering to do it. Perhaps some folks just will have to learn the
>hard and embarassing way. Sigh.
>
>-David Fedor
>Palm Developer Support
>
>
>Here's the text from the Knowledgebase.
>
>
> How do I determine which processor is on the device?
>
> The feature manager will tell you.
>
> Call FtrGet to get the sysFtrNumProcessorID feature. Mask the
>returned value with
> sysFtrNumProcessorMask, and the result will be any of
>
> sysFtrNumProcessor328 - the original Motorola 68328
(Dragonball)
> sysFtrNumProcessorEZ - the Motorola 68EZ328 (Dragonball EZ)
> other values - for other processors which might be used in
>Palm Computing platform
> organizers in the future.
>
> These values are defined in the 3.1 SDK. In case you don't have the
>3.1 sdk yet, here are the
> definitions:
>
> #define sysFtrNumProcessorID 2 // 0xMMMMRRRR, where MMMM is the
>processor model and
> RRRR is the revision.
> #define sysFtrNumProcessorMask 0xFFFF0000 // Mask to obtain
>processor model
> #define sysFtrNumProcessor328 0x00010000 // Motorola 68328
(Dragonball)
> #define sysFtrNumProcessorEZ 0x00020000 // Motorola 68EZ328
>(Dragonball EZ)
> #define sysFtrNumProductID sysFtrNumProcessorID // old (obsolete)
>define
>
> You can ask the system for this feature on any version of Palm OS.
>
>
>
