To: perot@pallas.amp.uni-hannover.de
Subject: Re: [3] New STiK, more info and binaries                                        


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

----- snip ----- re: new ST-Guide

----- snip ----- re: Harun and HSMODEM etc

----- snip ----- re: Martin Mitchell (& the never-ending debate :-)
>>
>> Well, the Pexec issue is at least partly a matter of taste, like you said.
>> The IP-module issue on the other hand is definitely not so.  I think he has
>> already realized his mistake, since he started talking about meaning a form
>> of 'modularity' affecting only the theoretical design, not the implementation.
>> This does not match what he said earlier, but that's not important.
>
>Aha, maybe this was what puzzled me with his mentioning integration and 
>modularization at the same time. Hopefully it can be settled now, and we 
>can go on with development of STiK.

Yes, that would be a relief.


>I'm finished with UDP.STX (well, completed is the better word, as it is 
>probably still full of bugs). Hopefully this means that the core's module 
>functions are up to some final stage, so that I can tell Dan that this 
>time the specs will be the final ones. Tell me if you wanna look into the 
>UDP.STX, I'll send you the source code then. It's only 12 kB, the STX is 
>4 kB. Doesn't this indicate that the interface is reasonably efficient ?

Sounds ok, though I can't really appreciate this without knowing exactly what
it does.  Like I've said before, I still have a lot to learn about the various
protocols and their usage.  Even so, I am indeed interested in seeing your
source.  And while I may not be up to advising you on the protocol dependent
parts of the code, I can certainly look for optimization details.


>> >The problem with Harun is that he wants to talk me into using the GEMDOS 
>> >interface. He does not accept that we abandoned the GEMDOS approach for 
>> >good reasons, and that we'd need to throw away the interupt driven back-
>> >ground operation, which in my opinion is one of the major improvements
>> >of the new concept.
>> 
>> I don't quite follow you here.  At some levels we must use GEMDOS or BIOS
>> in order to reach the device drivers.  The GEMDOS interface is a bit more
>> 'expensive' than the BIOS interface, but does have some advantages.
>> AFAIK it is perfectly legal to mix the use of BIOS and GEMDOS, since many
>> GEMDOS functions are often implemented by calling BIOS functions.
>
>This is often perceived as wrong (the mixing issue). I have no settled 
>oppinion on this, I simply try to not mix, as many important people say 
>you should not mix them (like Eric Smith, or the ProfiBuch (Julian 
>Reschke)), others say you may do it.

Both opininions are actually correct, but relate to various parts of bios.


>You certainly shouldn't do it with mass storage access, i.e. mixing of
>Fopen/Fread/Fwrite with Rwabs is certainly hazardous.

Precisely, since the bios disk functions work below the level of the FATs
and the directory oriented parts of the system.  But nevertheless the rule
can not be applied categorically.  Some special tools (eg: KOBOLD) must
have the ability to work on both levels at the same time.


>I'm trying to get away completely without GEMDOS  for the access to the
>serial devices.

That is naturally legal in itself, but also means that a device opened for
STiK will not be recognized as 'busy' when other APPs use GEMDOS.


>Calling the routines via the bios vectors is fast, a lot of overhead (two 
>traps, one for jumping into GEMDOS, another one for GEMDOS jumping into 
>BIOS, are avoided, and twice the cost for function pointer lookup - in 
>both GEMDOS and BIOS) is saved.

Actually you still have to make the BIOS lookup, but who cares ?  The _BIG_
savings lie in avoiding the GEMDOS trap, since those functions are implemented
in a completely different way (much more timewasting) from both BIOS & XBIOS.
This is of course most important for the running communication calls, and less
important for operations like 'open' and 'close'.


>It's only that the SERIAL2/LAN handshake works with the DEVICE chosen via
>GEMDOS Fopen("LAN" or "SERIAL2"), setting the PSG Port A Bit 7 only chooses
>the port, but does not switch handshaking. But Harun already mentioned a
>backdoor into the HSMODEM  routines, he wasn't very specific, but this seems
>to be what I need. I thus won't be quiet before Harun tells me what it is ;-)

Ok, but I'm 100% certain that it is perfectly legal to use BIOS for the running
I/O combined with GEMDOS open/close.  This is what TOS does internally anyway.
HSMODEM should also allow this, and if at present it does not then it needs to
be altered in this regard.  It should only extend, not limit, capabilities.

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