To: stik@ON-Luebeck.DE
Subject: Re: [11]  STIK: STIK/DIALER                                                      


On Fri, 23 Aug 1996 01:01:25 Christian Andersson <falt wrote: 
>
>On Thu, 22 Aug 1996 23:19:35 Peter Rottengatter <perot wrote: 
>>
>>Anyway, nobody is required to have a timer value of 0 ms. Set it to, say, 
>>10 ms, which is also the sort of time slices you'd use with MagiC. 
>>Suddenly your program won't waste CPU power anymore.
>
>Even if I set teh timer to 1 second, it is still a WASTE of time checking 
>for something that might not be there! i'd rather only check for data IF 
>there is data to recieve :)

Then you are not talking about checking at all, but about a direct implementation
of STiK specific events in an altered version of 'evnt_multi'.

I personally do not have enough information about the internal use of event
related data structures inside the AES code to do this.
Especially not in a way compatible to all known AES, which it would have to be.


>Magic 4.01 I belive it is! Running Semper/Octopus in the background. and 
>FireCall as an application if the foreground!
>I ran some utility that tested how fast the processor was left! when 
>running FireCall, about 10% of a "normal" TT, NOT running FireCall aprox 98% 

Excuse me, but is not 'Octopus' a BBS program, and can it really share the modem
port with STiK correctly.
(Just curious...)


>With the 1 second delay, it is down to only 97% free!
>
>Unfourtunally I cannot remember what program I used to test this.
>
>Im currently thinking of Adding supoprt for the inter-rupt driven thing in 
>HS-Modem, but I'm not sure how to do that at the moment!

I don't get it !
You would try to make Dan's routines directly interrupt-driven, is that it...?
Then I suggest you speak to him about that directly.

Or is it your own routines that would call STiK functions from within interrupts?
But how do you get these interrupts to occur when appropriate to STiK then ?
I'm very unclear on what exactly you mean here, so please clarify.


>>> If you want speed in the machine under multitasking, this is NOT the way to 
>>> go!
>>
>>Depends. You shouldn't do it with MultiTOS, of course. ;-)
>
>And I think STIK is going to be Multitos freindly, not perheps NOW but some 
>day :)

No program can really be MultiTOS friendly, since MultiTOS is a bug-ridden AES
highly inimical to all applications run under it.  It is an unfinished product,
and considering what's happened to Atari it is unlikely ever to be finished.

Fortunately this does not matter since nAES is a perfect replacement for it,
and when XaAES and oAESis reach a later stage of development they too may
become serious contenders for that position.


>BUT, could not the message-part be done without the ACC?
>
>Hmmm what about this? this is just a hype idea, that I'm not sure if it has 
>been discussed or not before.
>
>why not let the Evnt_multi(...) calls that STIK Programs are using be done 
>through STiK? 
>STiK is already interupt-driven, and when a pakage is recieved it would onlu 
>have to "fake" an answer from the real evnt_multi call.

STiK is not entirely interrupt-driven even today, and is certainly not linked
into the event system of the AES, which it would have to be for what you suggest.


>Is this possible? or am I just going to have to hide forever in disgrace? :)

I think it may be possible, but extremely tricky, since it involves linking into
the AES functions (always tricky), and possibly changing the event handling.

It would not be very difficult to change the 'evnt_multi' to simply test STiK
flags first, and only call the old 'evnt_multi' if no STIK events are pending,
but then we must still use timer events to get out of the deeper AES levels.

To actually modify those 'deeper' AES event routines will be extremely difficult
(perhaps impossible) to do in a way compatible with all known AES.

If we choose the former approach, then we may as well do it by a direct call to
a new STiK function (legal only for GEM APPs), since that eliminates the need
to link into the AES functions at all.

But like I said, this still does not eliminate the need for timer events.

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