Thanks Danny. You solved my problem. You're God!
Just one minor detail ... I had to look for 128KB boundaries, not 4MB
boundaries, although I would be very interested in buying a Palm with a
dynamic heap big enough to cross 4MB boundaries :-)
Here's the code to find the barrier, in case anyone cares.
- Ioi
#define BOUNDARY_MASK (~(128 * 1024 - 1))
#define BLOCK_SIZE (128)
MemHeapCompact(0);
for (head = NULL; ;) {
long start, end;
ptr = (MemBlock*)MemPtrNew(BLOCK_SIZE);
start = (((long)ptr) - 8) & BOUNDARY_MASK;
end = (((long)ptr) + BLOCK_SIZE) & BOUNDARY_MASK;
if (ptr == NULL) {
break;
}
if (start != end) {
/* the block crosses the boundary, or the end touches
* the boundary */
beamBarrier = ptr;
break;
} else if (start == (((long)ptr)-8)) {
/* the start of the block touches the boundary */
beamBarrier = ptr;
break;
} else {
ptr->next = head;
head = ptr;
}
}
> Your description triggered my memory. :)
>
> You've found a bug in WinScreenLock that only exposes itself on 8MB
> devices. On the DragonBall EZ, the buffer for the LCD mustn't cross a
> 4MB boundary. There is one such boundary on 8MB
> devices. WinScreenLock didn't do anything to ensure that this boundary
> wasn't crossed. This was fixed in Palm OS 4.0. The higher screen
> depth increases the size of the LCD buffer, making it more likely to
> cross the boundary (but it can still happen, even in 1-bit mode).
> Allocations in your app will change the layout of available memory,
> changing where the LCD buffer gets allocated.
>
> The reason that you're seeing this when beaming (or receiving) is that
> the Progress Manager uses WinScreenLock/Unlock to avoid flicker when
> it animates.
>
> The workaround is to allocate a small chunk of memory across the
> boundary when your app starts. To do this, keep allocating chunks (via
> MemPtrNew) until one crosses the boundary. (Touching the boundary is
> actually good enough.) Then free all but the last one. You can either
> free the last chunk when your app exits or you can set its owner to
> "system" and leave the fix in for everyone else. You'll need to handle
> the possibility that a chunk has already been allocated across the
> boundary when your app starts too. Pretty ugly, but a workable
> workaround. :)
>
> The bug probably doesn't appear in Poser because it's not emulating
> the behavior of the EZ down to that level of detail. What the EZ does
> when you place the LCD buffer across a 4MB boundary isn't documented;
> you're just not supposed to do it. So Poser can't emulate the weird
> effects you see on a real device without knowing "too much" about the
> EZ. What Poser could do is complain when it sees an LCD buffer that
> doesn't conform to the processor's rules. Of course, that would expose
> the bug in Palm OS 3.5, but that's the whole point, after all.
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
