At 17:19 2003-2-3 +0100, you wrote:
David, there's a pretty big chance that if you setup an ARMlet that just returns the callback pointer to your 68K code, you could then later use the same pointer to call back to 68K code from your sound callback. However, there are big problems:The problem I face is that when running code from the ARM callback called by the Sound Manager API, I don't have an emulStateP or a call68KFuncP. Do you know a way of obtaining these despite the fact that the callback isn't called from PceNativeCall?
1) The pointer might not be valid. I don't know if there is one entry point or if Palm OS does some sort of thunk.
2) Your sound callback is in a different thread. Calling user interface functions is a bad idea, since they aren't designed to be thread-safe. Many other Palm OS functions are also not thread-safe, so you could easily mess up the OS or the device.
I think a much better solution would be to have a message queue in memory shared between your sound thread and your 68K-based UI thread. Make a ring buffer of message strings you can overwrite, and use a semaphore-like constructor to control access to the buffer -- your sound thread inserting messages, and your UI thread removing them and sending them to the screen or out to the debugger using DbgMessage.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
--
For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
