Conference hydra::amiga_v1

I dunno about the problems in .0, but Handshake 2.20c unfortunately still
doesn't honor keymaps other than USA0...
This and some mysterious crashes on my A2500 while just clicking along 
have me still hooked to VLT...

Cheers,

<CB> 

    I downloaded it and tried it with no problem, tho' it wasn't a thorough
    test.  I still have to read the docs.  Question:  (I don't know much
    about the Hayes commands) You say you have a sequence of D E T for
    Dial, Echo, Tone.  Is it possible it doesn't like the Echo in the
    middle like that?
    
    Tony

    I had a problem with it "freezing" up my modem connection.i.e. it would
    not send or receive but the connection was still there.  Its "screen
    scroll" is a drag.  I had light characters on a dark background and the
    terminal in smooth scroll.  When scrolling the entire screen blurs as
    if there are artifacts where the characters had previously been.  I
    would also like to have the choice of autodialing the Scholar in DEC
    mode which I haven't been able to do with Handshake.  I CRAVE vt220
    support(expecially next screen/prev screen) but will stick with VLTjr
    v4.824.
    
    md

	re .1   Haven't noticed any other problems, though I haven't really
	        given it a full test.  Up to this point I've been using
		Ymodem. Now that Handshake supports external protocalls I'm
		going to give Zmodem a try.  


	re .2	My fault. The string is actually AT L0 E D T . I've also tried
		it without the E at all - no change.

	The docs said to run EXEC_ME right after you unpack the archive or it
will not work properly. The EXEC_ME file was not included. I don't know what it
is supposed to do, but I have had the program crash a couple of times when I
had it dial out.

	Does anybody have this file or know what it does?

    Re: Hayes stuff

    Doesn't the [E]cho require an argument, ie: E1 or E0 (on and off)? Does
    Handshake look at what's echoed back or does it read the registers?
    Who's the bonehead that adopted the Hayes command mode as the industry
    standard anyways? I'd also like to be able to use the dialer with a
    DEC modem.

    FWIW, I too have had several guru's while trying out V2.20c. Several
    times while just minding my own business and one other while repeatedly
    calling up the "color" requestor ("*" key, I think?). I'll stick with
    VLTjr also, but I suppose I can't complain till I send Eric some cash.
    I noticed that starting it from Workbench gives it a stack of 5000.
    Perhaps it needs more...

    Pete

    Re: .5

�	The docs said to run EXEC_ME right after you unpack the archive or it
� will not work properly. The EXEC_ME file was not included. I don't know what it

    My guess is that it would be used to expand the file names from the
    original ARC archive (indicated in the docs as HDSHK220.ARC or something
    to that effect). It looks like somewhere along the line someone
    repackaged it with Lharc.

    Pete

    I uploaded it the way I got it.  I also didn't notice an exec_me in
    there.
    
    I too have had crashes when trying to change the colors once in a
    while.  I just don't do it now.
    
    Rob

    Well, it has worked for me without any problems at all.  I have used
    Zmodem from the external protocol support.  I have also tailored it to
    use the Pearl2 font.  And I spent a number of hours on it this past
    weekend also without any problems.
    
    re: the autodial hang
    
    I am also using a Scholar Plus modem.  I just use the ATDT prefix string.
    The only time I have had it consistently hang on the connection was when
    I tried to set the modem to use MNP-5, or the answering modem tried to
    shift me down to 1200.  I believe it detects connection when it reads
    the "CONNECTED" string returned by the modem.  I have had it hang on a
    few rare occasions that I attributed to line noise trashing the
    CONNECTED string.
    
    So far I have been very pleased with this new version. BTW: If you were
    a V2.12 user did you convert the .parms file with the utility program
    supplied?
    

re .-1

>    I am also using a Scholar Plus modem.  I just use the ATDT prefix string.
>    The only time I have had it consistently hang on the connection was when
>    I tried to set the modem to use MNP-5, or the answering modem tried to
>    shift me down to 1200.  I believe it detects connection when it reads
 
The Scholar plus only supports MNP level 2 or level 3. (error correction)
Level 5 is all the above plus on-the-fly data compression which results
in a much greater throughput for text and uncompressed files. Compressed
stuff (like .lzh files) see very small benifit but no degredation.

john

    
    The only problem I seem to suffer since changing is that I have to stop 
    MACHIII first or I can`t QUIT or reset the terminal 
    
    I`ve now used it for all of the weekend and logged in to some BBS`s and 
    Thanks to the font requestor (I`m using a modified version called
    Tony.font written by one of my sysop friends that also allow I*B
    codes..) I can now see his new logo on his BBS (01 for Amiga in London
    071 377 1358)
    
    All in all it got everything I require (or has it)
    
    I`ve just heard that Dialog and Jack Regan (of JRComm) are working on a 
    Bi-sync protocol (XPR) so you can download and still look around the
    BBS...??? 
    
    Would that be posible on the VAX (I can`t see how this would work)
    
    	Steve G

 >   Bi-sync protocol (XPR) so you can download and still look around the
 >   BBS...??? 
 >   
 >   Would that be posible on the VAX (I can`t see how this would work)
 
All you need is a packet protocol and a client server model.

you would run a application on the VAX side that decodes packets from the
terminal program and directs them to the correct local process. It would also 
generate packets from each processes output and send them back to the 
terminal program. Each VAX process would have a "channel id" associated
with it which allows each side to distinguish packets.

The terminal program is responsible for managing the local amiga screen
and requesting the VAX side to create processes to do something. It also
provides the user with a mechanism of switching between VAX processes. It
must buffer all VAX side process output until the user requests to see it.

A real neat model would allow you to create multiple "terminal windows"
which would each attatch to a VAX DCL process via the VAX-side program.
On the amiga each process would get it's own window so you could see everything
at once.

The biggest problem is performance over a 2400 baud link. You could write
your application to allow assigning a priority to each "channel" so a 
download could happen in the "background".

I believe Unix has something called "windows" which the Meshugena terminal
emulator (ala Mike Leibow) uses.

any takers?

john

re: .12

The protocol you described so well is called CTERM, and it is implemented
for the Amiga - as part of the TSSnet package from Syndesis.  Mike Leibow
has implemented it for the ST, so that code could perhaps be ported to
the Amiga.  I don't know if CTERM is licensable, or maybe it is just
documented.  (Or maybe external people just reverse engineer it).

Steve

    On VMS it's called SSU (Session Support Utility)
    
    It's used by those newer terminals that support running as multiple
    terminals.  Jeff Lomicka's WHACK terminal emulator for the ST supports
    it.
    
    And something called STRANSF on the ST supports using it for file
    transfers.  For more info, see note 423 in BOLT::ATARIST notes conf.
    
    I suspect it's a simple protocol, don't know what the status of it
    is concerning licensing.  Would be nice if the Amiga could do that
    stuff too.
    
    Dave

    I gave HandShake220 a quick try over the weekend. 
    
    When I first started it up it GURUed the system - this was after the
    modem hung. I use PhoneLineWatcher and it sets the modem noecho - This
    seemed to cause the modem dial hang...
    
    After the initial problems I have had no Amiga problems.
    
    HandShake still has one problem that will keep me from using it - When
    in interlace (48 lines/screen) it will not work with Jeff Lomicka's
    SET_TERM_INQUIRE program which will attempt to set the proper screen
    size. HS always returns an 80 by 24 screen. I guess I'll stick with
    JR-Comm V1.01 - it seems to everything I need but 132 col stuff.
    
    
    John

    	I set Handshake to 48 lines and did a set term to 48 lines. Mail
    and notes still only used 24 lines, but I got LSE to use all 48 lines.
    It's pretty hard to look at 48 lines interlaced for any perion of time,
    though.
    
    	If I got past the dialup without crashing, everything worked fine.
    But I did have an active edit on another screen the first time it
    crashed.
    
    	Interesting that one other user had to turn off machIII. I'm using
    Dmouse. I wonder if these rodent accelerators are causing the problem?
    

Re: .16

I already had 2.12 crashing constantly on me with DMouse. Qmouse didn't cause 
any troubles, but since I had no other problems with DMouse I blame a 
consistent Handshake bug.

Cheers,

<CB>

I too have the same problem as .0 After the CONNECT line i must RESET
to get the <cr> to activate the LAT. It doesn't matter if i use a
simple dialog string like ATDT or (trying to enable MNP2) AT$M2 DT.
More of a pain than anything else. I am also trying to get ZMODEM too.
I assume that all i have to do is get XPRZMODEM from FF261 and put it
in LIBS: and get ZMODEM on the VAX side & away i go??

    mark

    Re .18:
    
>   I am also trying to get ZMODEM too. I assume that all i have to do is
>   get XPRZMODEM from FF261 and put it in LIBS: and get ZMODEM on the VAX
>   side & away i go??
    
    I'm one step ahead of you.  I extracted XprZmodem.library from FF261
    (along with xprzmodem.doc) and put it into LIBS:
                                    
    When you tell Handshake you're going to use an external transfer
    protocol, it displays LIBS:xpr#?.library so you can select a module. 
    (It turns out that this selection is case-sensitive, so stick with
    lower case when you put xprzmodem.library into LIBS:)
    
    You'll also want to "Initialize" the external protocol, which sets up
    the Zmodem options, including where to put files that you receive. 
    Then you SHOULD be ready to roll.
    
    I got this far without difficulty, but when I typed SZ with a pathname
    under VMS and Right_Amiga-R to tell Handshake to receive the file, an
    empty window appeared but nothing happened.  (It seemed to hang the
    same way that XMODEM does for me -- perhaps I should go back to the LAT
    setup stuff that has been detailed elsewhere in this conference.) 
    Eventually, SZ timed out.

	I installed Z modem last night.  The procesdure described in .19 
	is absolutely correct.  One thing I might add though is to do a
	save parms after you set up everything and do the init.  I believe 
     	this is necessary as "reset term" will reload the original parameters 
	in Handshake.parms.  This may have "erased" the external protocol 
	settings, resulting in a blank screen.

	After I set everything up, and saved it, I had no problems loading
	files with zmodem.  I did notice however that the "auto recieve" 
	function either isn't supported, or is perhaps another symptom of the 
	hang problem  experienced when a connection is made. 


	-mt

    re: DMOUSE
    
    I use DMouse 1.22 (I think) and didn't experience any problems with
    HandShake220 in my short (1/2 hour) test. 
    
    John

Re: .19, .20

One more nit, it seems that the xpr location is also stored with it _complete_
path. When starting the Handshake I configured at home here on my office
A500 it requested the volume "BOSS:" (my Sys: HD-Partition). 
I had just entered "Libs:" at home and per definition that's where the xpr
protocols are kept.

Cheers,

<CB>

re .18 and on

	I got through it a couple of nights ago;  somewhere along the 
way I forgot that I was still connected to the phone via handshake 
2.1_something and just ran 2.220c out of the shell  - -  it came right 
up and showed me the dollar prompt from VMS, it had just grabbed the 
line.  I had all the usual minor problems with number of data and bits, 
parity and terminal type - once I set that up and saved params things 
were fine.  Then I got into that Stooopid projector thing that is also 
on FF261 - wasted some time there (-:

	R

     Reg (-.1) mentions something I consider a feature that I am
     reluctant to mention because it might go away ;-)...
     
     I use VLT to dial up and download and just about everything (I
     especially like the VLT review buffer) except 48 line  editing in
     EVE/TPU.   For some reason VLT gets a bit crazy  with cursor
     placement and screen scrolling. I can cleanup things with a CTRL/W but
     if I want "perfect" emulation for heavy EVE use, I just exit VLT and
     fire up VT200 leaving the modem/serial line active. After VT200 starts
     up I hit one return and see the prompt right where I left it!
     
     With these two programs and this "feature" I am so far reluctant
     to even bother trying the new Handshake.
     
     BTW if anyone knows why VLT gets confused I'm interested (wrong note
     I suppose).
     
     Dave

Re: .24
     
>     BTW if anyone knows why VLT gets confused I'm interested (wrong note
>     I suppose).
Yup, wrong note... ;-)
But to answer your question, it's because VLT is just VT100 and not VT200.
Do a "set term/inq" or a "set term/dev=vt100" and you'll loose the VT200
stuff (like keymapping) but now EVE will no longer send VT200 specific 
sequences and VLT will work as advertised...

Cheers,

<CB>

 >    EVE/TPU.   For some reason VLT gets a bit crazy  with cursor
 >    placement and screen scrolling. I can cleanup things with a CTRL/W but
 >    if I want "perfect" emulation for heavy EVE use, I just exit VLT and


It seems to be timing related. If you hold down the arrow keys (repeat mode),
it gets screwed up. If you hit the key each time, it seems to work.

john
 

>It seems to be timing related. If you hold down the arrow keys (repeat mode),
>it gets screwed up. If you hit the key each time, it seems to work.

All the DEC's terminals insert a short delay between the transmission each byte
of the escape sequence, almost simulating human typing.
Usually, compatible terminals and terminal emulators don't do it and the poor
terminal driver (expecting human typing speed) can miss some character while
receiveing quick/long sequences, that are no longer recognized.

The solution would be to add some code to the terminal emulator so that,
when sending an <ESC>, a short delay is introduced after each character
until the first alphabetic character is sent.

e.g.:

ESCapeCare(c,stream)
char c;
FILE *strem;
{
 extern short EscapeON;

   if (c == '\e') {			/* beginning escape sequence ? */
     EscapeON = 1;			/* yeah, got to put delay */
   }
   fputc(c,stream);			
   if (EscapeON) {			/* delay needed ? */
      SleepAlittle();	
      if (isalpha(c)) {			/* end of sequence ?*/
         EscapeON = 0;			/* yeah, delay no longer needed */
      }
   }
}

>   fputc(c,stream);	
		
>   if (EscapeON) {			/* delay needed ? */
>      SleepAlittle();	
>      if (isalpha(c)) {			/* end of sequence ?*/
>         EscapeON = 0;			/* yeah, delay no longer needed */
>      }
>   }

Won't this loop kinda hang on the first escape sequence?

>Won't this loop kinda hang on the first escape sequence?

Actually I see no loop, I just notice that I forgot the return() statement just
before the last '}' but most C compiler would default it ...
Anyway ESCapeCare should be called for each character to send to the serial port
at the first escape, EscapeON is set true, so SlepAlittle is called and since
'\e' is not alpha, EscapeON is left true then the function is done and returns.
Next time EscapeCare is called, SleepAlittle is called then if c is alpha
EscapeON is reset false and next character won't be delayed unless it's another
escape.

I didn't have a single problem with the latest HANDSHAKE until I tried using
the XPRZMODEM.LIBRARY which I extracted from FF261.ZOO.  For some reason, I
can't seem to get it to work.  When I attempt to tell handshake to load the
external protocol, it lists all of the possibilities from the LIBS: directory,
which in this case is libs:xprzmodem.library.  I select it, and handshake tells
me that it can't find the library.  Strange.  It finds the file, and gives it
to me as an option, but when I choose it, it can't be found.  Do I have a
corrupt library?  I even tried downloading xprzmodem.library again and put it
in libs: but still got the same response from handshake.

To try out the library another way, I tried to load the library with "loadlib"
(I think that's the command) in a CLI window.  It wouldn't work, either.  I
asked "why?" and it told me it isn't an object file.  It looks like one to
me, when I examine the file and compare it to others in the library, but what
do I know.

Can anyone help me out?  I have to use xmodem for downloading to amy right
now, but FF261 is "big" and will take "39 minutes" to download.  I'd rather
just download the zmodem-related file(s) since that fish disk has a lot of
stuff I *really* don't want.  (garbage).  Any suggestions?  How do I extract
the zmodem stuff and download to amy without screwing it up?
    

    If you are downloading xprzmodem.library directly then XMODEM is
    probably padding the last buffer to make it 128 bytes. Try ZOOing the
    xprzmodem.library before downloading - This will allow the archive
    format to take the hit for the pad and not the amiga object module. 
    
    It should make the download faster too. You can also use LHARC to LZH
    it if you have that utility.
    
    John

I downloaded FF261 last nite and extracted the whole damn thing into
ram: and then moved all the xprzmodem stuff to my hard disk. I moved
xprzmodem.library to LIBS: and started HANDSHAKE. I selected External
Protocol and just got LIBS: in the requestor. So i typed
xprzmodem.library (case sensitive) and then intialized the protocol
(picked all the defaults). I installed SZ.EXE on the VAX and ran
SZ_SEND.COM. IT WORKED! I typed right-Amiga R and got a nice status
window. Surprised the hell out of me...

 mark

    Re .19 (and later):
    
>   I got this far without difficulty, but when I typed SZ with a pathname
>   under VMS and Right_Amiga-R to tell Handshake to receive the file, an
>   empty window appeared but nothing happened.  (It seemed to hang the
>   same way that XMODEM does for me -- perhaps I should go back to the LAT
>   setup stuff that has been detailed elsewhere in this conference.) 
>   Eventually, SZ timed out.
    
    After searching through umpteen notes, I discovered that I had to get
    the LAT session out of the way (SET SESSION PASSALL) and that life is
    much easier if one uses SZ_SEND.COM (after stripping off the initial
    commentary).  Having done that, voil�!  The "External Protocol Receive"
    window that Right_Amiga-R starts gives lots of nifty information,
    including the current transfer rate and estimated transfer time (which
    it revises as necessary).
    
    I might NEVER use Kermit again!  Except for a few unexplained GURUs,
    Handshake V2.20c is nearly perfect!

I too have had a couple of unexplained GURU's. When i shut down
HANDSHAKE last nite it crashed, and during a couple of transfers today it
has crashed. As a general rule i have very few GURU's.

    mark

    
    re .30
    
    You may be guilty of the same dumb mistake I was the first time I
    tried to get Zmodem to work.  Here's my stupid mistake...
    
    Just as you described, Handshake listed all the XPR possibilities 
    from LIBS: , which in my case also was only libs:xprzmodem.library.
    My mistake was when I saw that as the only file I just naturally
    hit the "OK" button in the ARP file requestor.. but, I had forgotten
    the SELECT (highlight) xprzmodem.library in the window, before I
    hit the "OK" button.That's when the old wiexternal protocal
    window popped up empty.
    
    Must have done it three times before I realized what I was doing wrong.
    
    Just to re-mention my initial concern about 40 replies back, has
    anyone else had to hit the "reset term" after the connection is made,
    or did I miss the answer in here somewhere? 
    

    A couple of people have made reference to a sz.com file.  Would someone
    please give me a pointer to where I could get a copy of it. I just
    discovered that sz does not seem to support wild card file names.
    
    						thanks

    4140.10

Has anyone used the "-d alt.device" switch?  I don't have a serial board,
but would like to use Handshake with the tsstrm.device that comes with
TSSnet.  In the past I have patched VT200 and VLT to use tsstrm.device
rather than serial.device.  Patching Handshake does not seem to work.

Previous versions of Handshake were not cleanly layered upon the
serial.device, so using alternate devices was not possible.  It claims to
have that feature now, but I haven't proved it yet.

Steve

FYI: tsstrm.device is a driver that allows "generic" TE's to make use
     of TSSnet/CTERM to "set host" to DECnet nodes.

    Isn't there an option in one of the menu's to choose the device?
    Somewhere in a config menu, one of the last choices.

    That's correct. In the first pull-down, near the bottom.
    
    Tony

    I thought I would try HandShake one more time tonight - 
    
    It GURUed as soon as I selected the number to dial. After reboot I
    tried to 'manually' dial using ATDnumber. My modem was in a very
    strange state, as if someone had typed an ATA (answer) - it immediately
    went off hook and started a tone, didn't even try to dial...
    
    I finally got connected and downloaded some stuff - Seems to be as fast
    as JR-Comm's ZMODEM. I didn't time them officially..
    
    John

    Seveal people have mentioned not being able to get Handshake to see
    xprzmodem.library although it exists in libs:
    
    make sure the file name is all in lower case. The default from FF261
    and other archives is XPRzmodem.library (note the upper/lower case
    mix), and handshake only looks for an all lowercase spelling....
    
    regards
    kevin

I just typed the name, using the same case as it was in LIBS: and it
works fine.

I do have a problem tho. When i initialized, i gave it a default path
name and then saved the settings, however, if i start it up the
following day it defaults to HD0: (instead of HD1:scratch). ANy idea
why it loses this setting?

 mark

 RE: .43
    Giving the external protocal a "default path" will work for the current
    session only.  As I understand it, the information you enter while
    "Initializing External Protocol" is NOT saved from Handshake's "save
    settings" option.  You have to (re-)initialize each time you run
    handshake.  Also, you will find that if you do a "reset termainal"
    after you have initialized the external protocal, your initialization
    settings are erased/reset to the "defaults" and you will have to
    re-init yet again.

    I finally gave up on Handshake and went back to VLT.  I wanted to like
    Handshake, I really did.  Buuuuttt....  It kept guruing on file
    transfers.  (Kermit and ZModem)  On occasion I could get ZModem to
    work, but it wasn't reliable enough to suit me.  Even though it wouldn't
    drop DTR on guru, it was still a pain waiting for the machine to
    reboot.  (Never did get KS 1.3, so I'm still booting from floppies, 
    don't ya know.)
    
    
    -Gary

I tossed it the second night I tried it. 

VLTjr is just too good and stable to give up. And it's free :-)

john

>Why can't it save the External Protocol settings. I set the path to something
>like HD1:SCRATCH/ and have to do it everytime i power up.
 
RTFM.
 
The external protocol specs clearly state you put a file in your ENV:
directory containing the protocol's settings.
 
In the docs for the xprzmodem.library, it is written that you put a file
name "xprzmodem" in the ENV: directory, and the contents of that file are
clearly documented.
 
Thad Floryan [ [email protected] (OR) {decwrl, mips, fernwood}!btr!thad ]

    Conventionally, the ENV: logical is assigned to RAM space.  It tends to
    disappear with electricity 8>).
    

    Hi,
    
    Anyone aware of a recent update to handshake?? I would like to use it
    but the rate of guru's is too high...
    
    regards
    kevin