My apologies to the list, all we need now is even more spam! Chris >Date: Fri, 10 Sep 1999 19:31:59 +0200 >To: [EMAIL PROTECTED] >From: Christian Vandendorpe <[EMAIL PROTECTED]> >Subject: Re: EZ Grayscale Palette register > >Ok, got the file thanks > >Question, the field called rate which is of type char, it is just a char >of the exact rate right? So if the rate is 28.234 it will say "28.234" in >chars right? > >what is the SecurityID? > >How do I know the currency that this person is tracking securities in? > >Chris > >At 01:17 PM 9/7/1999 -0400, you wrote: >>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. >> > >> > >> > --- Christian Vandendorpe ([EMAIL PROTECTED]) http://www.zorglub.com
