To: perot@pallas.amp.uni-hannover.de
Subject: Re: [2] STIK: Important inquiry, please read !


On Sun, 29 Dec 1996 14:45:30 Peter Rottengatter <perot wrote: 
>
>On Sat, 28 Dec 1996, Ronald Andersson wrote:

----- snip ----- re: the 'trap #2' function $C9 == appl_yield ???
>
>I think you're talking about XGEM if any, but not XGEMDOS ? GEMDOS is 
>trap #1 and called this way only because it's "DOS under GEM". If I 
>remember right that you're referring to a trap #2 call with D0 == $C9.
>Just to avoid confusion.

This is a simple terminology problem.  In a lot of my literature the term
XGEMDOS is used instead of your XGEM (which does not appear), and is of
course never to be confused with GEMDOS (without X).


>> Since this 'appl_yield' does not use any AES arrays, it should be legal in
>> both GEM and TOS programs, which is another great advantage.  Naturally it
>> can not be used from interrupts, but it could be called from an event-
>> driven scheduler such as we have discussed earlier, or from any STiK routine
>> that is called by the 'main' code level (non-interrupt) of any client.
>
>If it works this way, then I agree, it could resolve the issue. Both 
>TCP_wait_state and resolve should never be called from anything but what 
>you called main code level.

That was what I thought too, so if we can only find some confirmation of the
reliability of this function, we can go ahead and use it.  I'll make a few
experiments in any case, just to satisfy my curiousity as to the effects.


>> I suggest we try to find out more about this function, which must surely be
>> documented somewhere.  If we can find that documentation, and if it agrees
>> with the impression I have of how it is implemented and can be used, then
>> it may become a very useful part of some future STiK functions.
>
>If you can find out more, it'd be useful. So I'll wait with scrapping 
>those functions until you dug up some document. I can try to contact 
>Andreas Kromke on this issue too.

Please do so.  Since he has implemented this function in MagiC, he most
probably knows of some documentation concerning it, which we need.
We can only rely on the presence of it if documented as an AES component
by Atari.  Otherwise newer AES like XaAES or oAESis may cause trouble later.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
