Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!rrd
From: rrd@hpfcso.HP.COM (Ray Depew)
Newsgroups: comp.sys.atari.st
Subject: Re: Uniterm 2.0f where to get?
Message-ID: <7340061@hpfcso.HP.COM>
Date: 18 Jan 91 05:50:02 GMT
References: <123@gem.stack.urc.tue.nl>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 64

In comp.sys.atari.st, rosenqui@crc.skl.dnd.ca (Eric Rosenquist) replies:

>In article <7340060@hpfcso.HP.COM> rrd@hpfcso.HP.COM (Ray Depew) writes:
>>....  However, the discussion
>>here has drifted to STalker/STeno, and since I use my ST for program 
>>development on the HP48SX, I could really use a combination datacomm/text
>>editor program.  That's why STalker/STeno sounded so neat.
>>
>>So, again, re: STalker:
>>
>>    1)  What handshaking does it support?
>
>It currently supports None, XON/XOFF, RTS/CTS, or BOTH as per the ST's
>serial routines.  I don't know much about HP's ENQ/ACK; if you have
>any info you can send me I will look at it and consider adding it in a
>future version.

I don't have any technical info on ENQ/ACK; perhaps a fellow HP-ite reading
this can help out.  ENQ/ACK is an abomination left over from the days of the
HP3000 (a very good mainframe business computer).  The 3000 I/O systems 
required ENQ/ACK handshaking with their remote terminals.  (Why they couldn't
use just RTS/CTS or XON/XOFF, I'll never know.  Maybe because that's the way
HP ran their computer bizniz back then...)  Anyway, ENQ/ACK acquired a life
of its own, and now, even though it's not needed in our new computers, people
keep building it in as an option.  Someone on this site decided to exercise 
that option, and so here I am.

Don't worry.  Uniterm doesn't have it either.  Nor does Flash.  I've seen one
PD termulator with ENQ/ACK, but it didn't work very well.

>>    2)  Why not Kermit?  Will future versions support Kermit?
>
>Why not?  Because :-)

:-) :-)

>I realize that there are some cases where Kermit
>is the only choice (talking to IBM mainframes typically), but it was
>basically a case of Kermit being the low man (frog?) on the totem
>pole.  XModem and its variants are in much more demand, and
>consideration has always been given to the amount of memory occupied
>by STalker (since it's primarily used as a GEM DA).  If there is
>sufficient demand, I may consider implementing Kermit using the
>upcoming STalker 3's script language, or if I'm lucky, perhaps some
>enterprising programmer will do it for me.  The script language should
>have everything needed for such a task.  Right now I've got my hands
>full working on ZModem, so don't expect to see Kermit from me any time
>soon.

I see.  I don't know how much demand there is for it.  Kermit is awfully
slow, compared to other protocols.  HOWEVER, on the question of code:  there
is a book by Frank da Cruz, called "Kermit:  A File Transfer Protocol."  I
leafed through it once, and it had a lot of code (Pascal? shell script? not C)
in it -- it looked like enough code to build an entire Kermit.

Thanks for responding.  The combination of termulator/editor, especially as
desk accessories, sounds intriguing enough to me.

>Eric
>----------

Regards
Ray Depew
rrd@hpfitst1.hp.com