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


On Fri, 30 Aug 1996 16:10:42 Peter Rottengatter <perot wrote: 
>
>On Fri, 30 Aug 1996, Ronald Andersson wrote:
>
----- snip -----
>> I got the impression from what he said, that at present STiK is not interrupt
>> driven after all, but simply polls the port for bytes, and then reads them in one
>> by one, with a similar procedure for transmission writing to the port.
>
>Actually the DEVICE-LIB interface is block orientated (well, you can use 
>it that way, if you wish). So STiK doesn't see the byte by byte operation 
>on the port.

No, but if that is still the actual access method inside the lib, then it is not
much help since the lib is probably still wasting 99% of the byte delay time.


>I do not understand the DEVICE-LIB code completely yet, but I do not see 
>where the DEVICE-LIB does things in an interupt driven way. I strongly 
>believe that STiK gives a block of data to the lib, the lib then writes 
>it byte by byte to the port, blocking the caller (STiK) meanwhile.

That was how I interpreted your earlier post, but this means getting some kind of
new interrupt system for STiK has a much higher priority than I had thought.
This also means that at present the HSMODEM improvements to system routines are
not used by STiK, so any tests made assuming them to be used have been invalid.

Since the raw serial interrupt systems of TOS implement no 'protocol' at all, I
see no reason why these routines should not be used as the basis for an interrupt
driven version of the DEVICE-LIB used by STiK.  This means we can automatically
support gemdos-compatible improvements like HSMODEM (ie: any compatible driver).


>> Hopefully this description is wrong, so that the built-in interrupt buffering is
>> at least active, but then it is still inefficient to handle data byte per byte.
>
>No, you're very probably right.

Well, then I think someone should sit down and have a close look at DEVICE-LIB,
compare its port defintitions to those of HSMODEM, and write an interrupt driven
interface implementing similar functions (in assembler of course).

I'm not talking about any new interrupt routines here, just a novel way of using
the routines that are part of the TOS itself (or added on like HSMODEM drivers).
The most necessary change in the interface is of course that both transmit and
receive functions should return without delay with a transferred byte count value.

Hmmm, but doesn't both the original TOS routines as well as the HSMODEM code
already implement bufferred operation in both gemdos and bios serial functions.
Maybe all code is already done, only we've never bothered to use it ??? !!! ???

I'm not sure, but I believe we may simply use Fread/Fwrite, complemented of course
by some 'modem control' functions for carrier detect etc.

Gemdos is unfortunately rather wasteful of CPU time in its call interface, so we
may still want to write a separate buffered interface, but this should then be
modeled after the original as well as Harun's code, for maximum compatibility.
We then get serial Fread/Fwrite functions without the slow gemdos call interface.

Switching from real gemdos to these faster routines, simply consists of changing
two function declarations and including one more object module in Dan's linking.

Note that experiments on this may commence at once, without affecting Dan at all,
since all that should change for him are the DEVICE-LIB function bindings.
Two sets of C bindings should be made, one for gemdos and one for our own code.

The former of these should be completed ASAP, since Dan can then switch to the
new system (using gemdos at first), as soon as he wants to try it (if he does).

I believe a note to Harun would be in order, asking for HSMODEM details.

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