Ken, thanks to the very helpful ideas. A key assumption I had been making about my problem was incorrect. Turns out this was an OS-HEAP MEMORY limitation problem, but NOT a 64K barrier problem nor a 16-bit color problem (both red herrings for me).
I had been trying to allocate a 320 x 320 x 16 bitmap (200K) on a device when the largest free ram chunk was 450K in size. I got sysErrNoFreeResource! I didn't understand why, since this was less than half the ram, so I did some experimentation: 320 x 320 x 8-bit (100K) WORKED! 160 x 160 x 16-bit (50K) WORKED! So then I set the simulator to 1024KB HEAP RAM. At this point in the program, my largest free chunk was now over 980K!!! This time, I COULD allocate the 320 x 320 x 16-bit bitmap! But I could STILL NOT ALLOCATE a 320 x 480 x 16-bit bitmap (300K). So I cranked the simulator to the MAXIMUM of 2048KB HEAP (likely more than in most real devices), and FINALLY, I could allocate a 320 x 480 x 16-bit bitmap. So APPARENTLY, the PalmOS PARTITIONS the free space and only allows the OS a set portion of available memory to use. It seems like this percentage is LOW -> around 20% on the larger heap sizes. Can ANYONE shed some light as to the PalmOS 5 algorithm for partitioning heap usage? It seems nonlinear. NOTE: This is why I so enjoyed being able to gain true access to VRAM on the OS 4 CLIEs (via WinScreenLock). Because I could use VRAM for my buffers and not use up valuable heap space. By the results of the test, I conclude that some devices out there MAY have only 512K HEAP size, and then I can't do 16-bit graphics. Does anyone out there know a trick in OS 5 where you can create a screen buffer and not use heap RAM? Thanks to all for help! It's great to be making progress again. - Jeff Diamond -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
