Conference hydra::amiga_v1

    What I've been seeing (after a couple night's use of a DF224 for
    downloading) is I'll KERMIT along (using WeckerTerm) for about 20K-40K
    bytes, then the terminal connection will sort of "plop" back to
    the LAT box.  Then, WeckerTerm's KERMIT will think the LAT's prompt
    is a bad packet, send a NAK, which causes the LAT to type and error
    and reprompt, etc, until it reaches WeckerTerm's KERMIT error limit.
    
    Funny thing is that I haven't defined any "LOCAL" or "SWITCH"
    characters to the LAT box, and just in case a NULL would match "LAT>
    SET LOCAL NONE", I even tried setting the local characters to some
    other unlikely control characters.  Still no dice.  Lest we think
    that WeckerTerm is sending a break, doing so on the line I dial
    into will not return you to the LAT, but the port switcher in front
    of the LAT instead (who will promptly hang up).
    
    This is real odd, because without any LOCAL or SWITCH characters
    set, and given that the port switcher intercepts any BREAKs, I can't
    really think of any way to get the LAT prompt back once I've connected
    to a system.  I did a "SHOW TERMINAL" to the LAT after it happened
    once, and the data overrun counter reported a 0, so that didn't
    even seem to be it.
    
    What's especially weird is that I can KERMIT on my Hayes 1200 Baud
    all day and never see this.  In fact, I hadn't seen it until I tried
    my first download with the DF224.  Don't know if it's modem related
    or speed related, but my guess is that it's speed related.  Once
    it got late enough (and presumably, everyone else got off the system),
    the problem "went away".
    
    What a bummer.

    I have encountered a similar type of problem using Dave Wecker's
    Kermit with the DF224 2400 baud modem. If you try to download files
    at 2400 baud, kermit will fail for some strange reason. However,
    I can download files with no problem at all at 1200 baud so suggest
    trying it at 1200. I also haven't tried doing it on a lat line,
    always have used it on the micom switch with no problems at all,
    even if it is a noisy connection.
    
    Mike
    
    

    I have the same problem with Kermit.  After several hundred blocks
    are sent, Kermit bitches 'record too big for Kermit buffer' or some
    such.  I have been using Xmodem under DBW_VT100 with out anyu problems.
    

    
    Its not just DBW_vt100. A-talk from felisna software cuts off at
    2400 too. I believe the problem is with escape sequences due to
    the fact that my Lat also quits when I hit too many arrow keys in
    succession.
    
    

    Guys ... really now. I have been using my DF224 with VT100_DBW for
    months now. I used to have a similar problem until I started typing
    SET FILE TYPE BINARY at the KERMIT> prompt. Try that and your problems
    should be solved. Again, I have NO problems using the default settings
    on my DF224.
    
    Paul

This is all I do for flawless 2400 baud operation. Have not had a failure 
since I went to 2400 but used to have a lot at 1200 with a DF03.

	Dick

-------------------------------------------------------------------------
In LOGIN.COM

$KERMIT:== @KERMIT

KERMIT.COM

$ set term/nobroad/eight/past
$ run kermit
$ set term/noeight/nopast/broadcast

Make sure that the transfer mode is IMAGE on DBW-VT100

    Given that it works all day at 1200 baud, I can only assume that
    either the LAT is lying to me about data overruns, or it's getting
    some other kind of error that I'd call an overrun, but that the
    LAT wouldn't.
    
    In either case, while using binary mode transfers may "solve" the
    problem, if it's flat ASCII text that I'm downloading, I'd end up
    spending more time editing the resultant carriage returns out of
    the file than I would have spent downloading at 1200 baud in the
    first place.
    
    For now, I'll try all the suggestions in .-1 excepting the image
    mode transfer, and if that don't work, I'll drop back to 1200. 
    I think I've also figured a kludge workaround specific to the precise
    problem I mentioned, requiring some programming, but otherwise,
    not applicable to just about anyone else.

re: .7
	I forget the name of the utility but someone had a program
	for the Amiga that would strip the <CR>'s from a VAX text
	file after it was downloaded in image mode.  Anybody out
	there with a better memory?

	Don't use a LAT between the Amiga and the Vax.  This used to cause
all kinds of problems for PFT.

Mark

    There is a utility called CRLF (makes sense to me). I may have a
    copy of it buried on some disk somewhere.
    
    Paul

    Yeah, now that I think about it, I have an old something that strips
    carriage returns that I wrote back in November '85 that I long since
    removed from c: when I got my first KERMIT for the Amiga.  Guess
    I'm gonna have to go back and dig it out.
    
    It still makes me do a slow burn to have to download ASCII files
    in image mode.  That's what the protocol is there for, and to have
    to bypass all the niceties just to prevent the d***ed 2400 baud
    modem from freaking the blasted LAT box is nothing short of a kludge.
    
    Maybe I'll just go back to 1200 baud.  WeckerTerm and C-Kermit both
    spend so much time waiting for AmigaDOG to saw the download disk
    in half that the upgrade to 2400 baud didn't do much for total download
    times anyway. (And yes, I'd be downloading to RAM: instead of the
    disk if only I had more than 512K on the machine (and I'd have more
    than 512K on the machine if they'll quit dorking around with the
    Zorro spec and come out with some RAM and hard disk expansions that'll
    play together.))
    
    Three things I'd like to see in WeckerTerm:
    
    1) Asynchronous disk I/O
    2) A big "Stop that download right now" gadget
    3) Support of the KERMIT "sliding window" feature
    
    Then again, my fingers aren't broken, so maybe I ought to put my
    keyboard where my mouth is (and what a sight that would be!).

    I have experienced the same problems with AND without a LAT, at
    1200 AND 2400 baud.  
    
    (See 479.0, ps the suggestions at 479.1 did not help).

    ONLINE! V2 is now available. They claim numerous improvements over
    V1 including real honest-to-gosh VT100 emulation. They also toss
    in a free T-shirt when you place your order.
    
    Paul

Re: .6

>Make sure that the transfer mode is IMAGE on DBW-VT100

Not needed.  From examining the code in VT100, image mode merely
causes VT100 to delete any carriage returns it receives in a packet
and to insert a carriage return before any line feed in a packet it
is about to send.  It does not change the KERMIT protocol.

So, when transferring text files, I see no reason not to use CRLF mode.

Re: .*

I use 2400 baud, VT100, and the ZK dial-in LAT a great deal.  I have lots
of problems with line noise at 2400 baud, and I have lots of problems with
loss of signal (I believe the line noise sometimes causes either my scholar
or the ZK modem to hand up).  My belief is that 2400 baud pushes practicality.

    Well, I tried everything in .6, and I still get returned to the
    LAT prompt cleaner than {whatever}.  Some conclusions:
    
    If it's anything, it's probably something that the Amiga is sending,
    because I can't think of any condition that the VMS Kermit could
    induce to cause the LAT box to take control.
    
    I'm not getting *ANY* line noise on this line, or any other that
    I've experienced this problem on.
    
    If there was a break being sent by the local (Amiga) Kermit, it'd
    cause my connection to get dropped, because the BREAK never makes
    it to the LAT given the connection I have.
    
    Lots of voodoo and black magic has been suggested here.  I feel
    sort of strongly that since I've never seen this problem (or even
    close to it) at 1200 baud on my Hayes, either it's the higher speed,
    or the DF224 does something really wierd (perhaps blips carrier
    or something).

    Re: .14
    
>    Not needed.  From examining the code in VT100, image mode merely
> causes VT100 to delete any carriage returns it receives in a packet
> and to insert a carriage return before any line feed in a packet it
> is about to send.  It does not change the KERMIT protocol.
    
    Did you mean the text mode ? IMAGE mode does not do anything with
    CR's, it just passes everything through verbatim.
 
    As a suggestion to resolving the transfer (transmission) difficulties,
    DBW's VT100 (Basic version) could be used as a diagnostic tool.
    As I remembered from using it once to download the real DBW VT100,
    the basic version showed some of the inner workings of KERMIT transfer
    (ACK, NAK, packet number, size, and some of the contents of the
    packet in hex). Sure was a long and slow download, by the way !
    
    Good luck !
    
    Paul.

Re: .16

My mistake: IMAGE mode leaves the data alone and text mode causes it to
have carriage returns deleted/inserted as appropriate.