| From: | Joseph Fenton |
| Date: | 11 Dec 99 at 20:33:49 |
| Subject: | Re: [warpup] Re: GetMsgPPC arguement. |
Tim Hanson wrote:
>
> Hi Sam
> Sam Jordan wrote this on 11-Dec-99 at 01:18:19
>
> -> WarpOS has its own message system and its own message ports, which work
> -> independently from AOS/68K, therefore you can't use the PPC message
> -> functions to query a 68K message port. You would have to call exec/GetMsg
> -> to do that.
>
> ARGGH! This leads to another context switch in my central loop. Is it possible
> to allocate a PPC message port and attach it to a window? No I doubt it. Any
> suggestions as to how I can get key presses without going to 68K.
You can do all your 68K handling in a seperate task created
with exec for the 68K side; make the task assembly language
and you'll be sure vbcc will keep it 68K. :^} It also allows
you to make the 68K part as fast as possible and control exactly
what it does. Handling messages and the like is very easy in
assembly language; it's not the same level of programming
as say a 3-D perspective correct texture rendering engine...
anyone can handle that much assembly. Have the 68K task wait on
messages and Io and anything else, then preprocess the data
to a form that is easier for you to use on the PPC side, then
flush that region of the cache and signal the PPC task. The
PPC task can then simply check the signal staying completely
on the PPC side eliminating the switch; when it sees the signal,
it invalidates the cache for the data area and then fetches
data from the data area. A cache invalidation is virtually
instantaneous as all it is doing is marking cache entries
as not valid... no push-backs or the like are needed.
powerpc.library has all that you need for doing all this.
If you want instant (sort of) action on the signal, WOS
now allows you to set PPC signals that will cause an exception.