Flying into the Bermuda Triangle, Pilots and Palms. Questions, comments, flames, updates to tz@execpc.com Last Updated 4/8/99 Warning: the techniques won't work if Palm changes something, and all this should be avoided if possible, otherwise used very carefully and warn the user that it might not work on different models. This is also a lot of rumor, hearsay, and wild speculations, though they seem to work. So treat this information like something from a tabloid. You should also get a copy of the Motorola Dragonball manual if you want to know what I am talking about when I refer to registers or ports or things, and of course the official Palm documentation. Q. Why did my palm shut off although it says the battery is only low? A. You were probably running an app that used IrDA, the serial port, or the CPU a lot. Batteries produce lower voltage when higher current is demanded of them, and some of the chemical processes can't keep up with higher drain when low. So when you turn it back on, it is usually in a paused mode waiting, and using less power, and the chemistry has had a chance to catch up. Various hacks will give a battery level display and you can see the voltage change as different things are done, especially when the batteries are low. You can see the chemical effect with a pocket flashlight: If the batteries are low, you can leave it on until you see the bulb dim. Shut it off for 90 sec to 5 minutes, turn it back on, and the bulb will glow brightly for a little while, then dim again. What is happening is that a chemical is being produced faster than it can be cleaned up that poisons the reaction that produces the power. After 90 seconds off, the cleaning chemistry has a chance to catch up so the battery appears to have recharged itself. This effect will differ depending on the type of battery and if it is designed for high or low load conditions. Q. Any Undocumented Graffiti or character processing? A. This is actually on page 26 of the basic book but almost nowhere else - there is a next/previous field stroke, but it only works with the Address Book. These strokes create nextField and prevField characters which can be processed by appications. The UR to LL slash produces a linefeed (end of line, like pressing enter) and works elsewhere. There are codes for cursor up and down (which can be bound to the vertical strokes with a hack), and several others. Q. Any way to speed things up? A. Reduce the wait states. Flash on the III is normally set at 3, but should work down to 1. On the IIIx and the V, you might try to remove an extra wait state on the DRAM designed to increase drive capability. Q. How do I tell if certain hardware exists? A. GHwrMiscFlags is a global that has backlight, IrDA, and some other details. See System/Hardware.h. FtrGet has some undocumented stuff in System/SystemMgr.h for the backlight. Q. Anything special about the serial port? A. The UART can produce more than standard baud rates. Between fiddling with the PAL clock (like EcoHack does), and the very flexible baud rate divider you can do almost anything including MIDI (31250). Most PCs can only use exact divisors of 115200. The SerOpen call will set baud rates by computation, but not take the PLL into account. Q. What about IrDA SIR? A. Except for the PilotPro upgrade board, the UART is multiplexed, so SerControl(OpenRef, serCtlIrDAEnable, 0, 0); will flip the UART to point to the IrDA hardware, and there is an equivalent for switching back. For the PPro upgrade, you need to do this call but also use SysLibFind("IrSerial Library", &OpenRef); instead of "Serial Library". Q. What about IR remote control? A. You can generate a 40Khz carrier for a remote by setting the baud rate to 80000, 8N1, and sending a string of capital Us (0x55 hex). This will allow receiving of remote control data, and sending, but the UART transmit routine is a little slow at times, so you might need to use EcoHack in turbo mode (or equivalent). I haven't gotten this to work fully, only the carrier. Q. Can I do timing finer than 10mS? A. You can change the timer register TCMP2 at 0xFFFFF610. Shifting it right 2 results in 2.5ms. The Palm doesn't seem to mind, but I don't know how far this can be taken. You can also hook the interrupt, shift the frequency up, and call the original tick routine at the original rate, but keep the faster local count somewhere else. But you will have to remember to unlink the interrupt. NOTE: This register moved in the Dragonball EZ as used in the IIIx and the V. There is only one timer, and the corresponding register is at 0xfffff604. Q. Any problems or unexpected things that aren't in the official documents? A. The battery check is done by queueing events, so if you are waiting for any event, you will get a keydown event with this code every few minutes to trigger the check which will display the low battery dialog. Intercepting and discarding these will cause it to only see events if a real hardware event (pen, alarm, button) occurs, assuming I haven't missed some other rare event, but will also cause the low battery dialog not to be displayed. The low battery dialog is displayed even while hotsyncing (interrupting a backup until you acknowledge it and telling you to hotsync as soon as possible :). This also seems to interrupt the internal SMF player for long sequences (or short ones if started just before one happens to be queued). Q. Any Heap or dynamic memory gotchas? A. If SaveBehind is set for a form, it will only allocate memory (or fail) when the form is drawn. And the form will successfully be drawn, but when dismissed it will crash with a fatal error if the original alloc failed. There is no documented way to determine the exact memory required ahead of time, but allocating huge buffers at the beginning of a program is a bad thing to do - leave lots of chunks available for PalmOS. Q. Is there any way to handle incoming serial characters asynchronously (via events instead of polling)? A. SerSetWakeupHandler will set up a callback that can queue an event (suggest using a new keydown). Ask me or palm devsupp for more details, but I hope to have some sample code available. Q. Can the LCD do grayscale? A. It can do a depth of two, and these can be 4 of 8 contrast levels but the details are involved, and I am not familiar with them. Many of the Palm Win draw calls in 3.0 will correctly handle 2 bit depths. (someone want to contribute a full answer and a URL?). Palm has a greyscale app note (seeing gray on www.palm.com in the devzone). Q. What about digitized sound? A. The current hardware is capable of audio, but the piezo speaker doesn't reproduce things clearly. For now it can only reasonably produce monophonic rectangle wave tones. Q. Are there some calls I should never use? A. FtrInit and several other Init routines are used internally during the bootup and will confuse things greatly if called by an application. You will end up resetting the Palm (or maybe lose memory) and there are better ways of doing this if this is the intent. Q. Other things I should never do? A. Change the PLL system clock frequency too far out of normal bounds - you will erase the memory. I would also worry about the LCD since they tend to break if DC is applied - insure that there is always an AC signal. Don't play with the timer used for memory refresh. Q. How can I speed things up (Writing things on the screen). A. Use lower level calls. If you call a routine that formats text within a field (scrolling and splitting lines at words, etc) it will take a while to plot. If you use WinDrawChars, it will be much faster. If you need more speed, use bitmaps since fonts take some computation. And even if you use bitmaps, stick to an even 16 pixel boundary (I get 8% speedups plotting something from 0-15 v.s. 8-23). Q. Anything faster than that for screen writing? A. If you are careful, and don't care about future compatibility, you can use the following: #define WinDrawBitmap(b,x,y) HwrLCDDrawBitmap(x, y, b, 0) Note that WinDrawBitmap requires word alignment and widths, but HwrLCD doesn't. Also HwrLCD is BYTE aligned and always writes BYTES, not bits, so 6 bit wide bitmaps that are 2 bytes long per line will end up taking 16 bit wide fields on the screen. HwrLCD ignores the width in bits. I don't think it can decompress either, but haven't tested. In one app, since I already aligned the fields, I simply had to alter the bitmaps to be one byte wide (they were two wide for WinDraw). But I used to offset the characters into pairs, and that didn't work anymore. So I had to create two sets of bitmaps, one shifted by one bit, e.g. ###### ###### ## ## #### #### ## ## ###### ###### and ###### ###### ## ## #### #### ## ## ###### ###### --------========--------========--------======== ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ## ## ## ## ## ## ## ## ## ## ## ## #### #### #### #### #### #### #### #### #### #### #### #### ## ## ## ## ## ## ## ## ## ## ## ## ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ######