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.
