Conference hydra::amiga_v1

Looks like we have a winner!

VT100 gives great DEC compatibility and FAST Zmodem (as fast as JRComm, but
I haven't actually measured it yet).

I'm sold.

John

    Hey John,
    
         I've been waiting for Zmodem to finally be incorporated into
    VT100.  Glad it finally made it.  Was the Usenet binary compiled with/
    without the AREXX port installed?  That is, will I get errors unless
    someone recompiles this thing without the port? (No, I don't own a 
    compiler or AREXX).  
    
    Bob                                                    

    Bob, I don't have AREXX either so I gave it a try.  Except for an
    error message at the start, it dosn't seem to make a difference
    in running the program.
    
    The on;y problem I have noticed is that the zmodem doesn't have
    the ability to resume from where it left off, which means that if
    a download get broken partway through, it must be restarted at the
    beginning.   Boo!! That was my favorite part of zmodem 8-(
    
    				Rob

I don't have ARexx either (waiting to get it "free" with WB 1.4 :-)) but
like .-1 said, it just prints a 1 line message stating that AREXX isn't
installed (can't find some AREXX library). Otherwise it works just fine...
Yeh, except for the ZModem Resume.

John

I tried to download a file to RAM: with ZMODEM and got an error about
insufficient space (I think, the status window disappeared pretty quick).
The file should have fit easily.  

Anybody else see this?

Mike

> I tried to download a file to RAM: with ZMODEM and got an error about
> insufficient space (I think, the status window disappeared pretty quick).


I suspect that's because VT100 checks to make sure the file will fit (nice 
feature IMHO), and RAM is only as big as what's in it (i.e. always shows 
0 free blocks.)

You'ld do better to use RAD: or the ASDG RRD (VD0:) which have a definite,
fixed size.

John

    How much does the Arexx version that VT100 wants cost?
    
    dennis

    A quick survey of recent mail-order ads shows $30 or so on the average.

    
    RE: .5
    
     I think I read in the Documentation that you can disable the
    insufficient space checker, (for downloading to RAM:).
    
    Chuck

Thsi just came over usenet from the author of vt100 2.9. I don't have a C
compiler (yet), but maybe someone would like to try it out.

tom
-----------------------------------------------------------------------------

From decwrl!ucbvax!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!amdahl!pccuts!acs Wed Oct 25 15:59:16 PDT 1989
Article 36967 of comp.sys.amiga:
Path: rust!decwrl!ucbvax!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!amdahl!pccuts!acs
>From: [email protected] (Tony Sumrall)
Newsgroups: comp.sys.amiga
Subject: VT100 V2.9: Kermit BYE and other problems
Message-ID: <[email protected]>
Date: 25 Oct 89 17:38:47 GMT
Reply-To: [email protected] (Tony Sumrall)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 80

Well, I finally had time to look into the problems that y'all've been
reporting with VT100 2.9.  It appears that I screwed up.  After suitably
punishing myself (vowed to watch 20/20 at least twice before the end of
the year with at least one attempt at watching Geraldo) I came up with
the following fix for Kermit BYE: replace the saybye() routine in kermit.c
with the following:

saybye()
{
   int len, num, gotbuf = 0;

   if(msgpkt == NULL) {	/* No msgpkt buffer, create one */
	msgpkt    = (char *)AllocMem((long)(MAXLONGPKS+20), MEMF_PUBLIC|MEMF_CLEAR);
	spackbuf  = (char *)AllocMem((long)(MAXLONGPKS+20), MEMF_PUBLIC|MEMF_CLEAR);
        if(msgpkt == NULL || spackbuf == NULL) {
	    InfoMsg1Line("KERMIT: Insufficient free memory, BYE bypassed");
	    return;
	}
	gotbuf = 1;
    }

   if(numreqs != 0)	/* Requester's up... */
	Delay(5L);	/* ...so wait for Intuition, just in case. */
   spack('G',n,1,"F");  /* shut down server no more files */
   rpack(&len,&num,ackpkt);
   if(gotbuf) {
       FreeMem(spackbuf, (long)(MAXLONGPKS+20));
       FreeMem(msgpkt,   (long)(MAXLONGPKS+20));
       msgpkt = spackbuf = NULL;
   }
}

I've also gotten some details from folks on their script problems.  What
I've seen so far has pointed out a (another?) failing in the VT100 script
language: its operation isn't intuitive.  See, in 2.9 (and 2.8), VT100
won't execute a script command until AFTER processing some other event
(menu selection or serial data received, to name just 2).  This would lead
to different operation of the script depending, for example, on how
quickly their host could emit data or whether they used the right
mouse-button.  Needless to say, this caused ME a number of problems since
most folks don't relate mouse clicks or serial data to a script problem
("I can *see* the data that the script's waiting for right there on the
screen, how come my WAIT wasn't satisfied this time but was the last time
I tried it?!?").  I also have a fix for this but am not quite so willing
to share it with you just yet since it *does* change the way that VT100
works.  This "fix" will cause VT100 to execute script commands to the
exclusion of processing serial data UNTIL the script has suspended itself
by either issuing the WAIT or the DELAY commands.  The fix is trivial
but I'll hold onto it until some of the folks that have reported script
problems have had a chance to try it for a while.  In the meantime I
suggest that you:

   1. minimize your use of the WAIT command (or WAIT on shorter strings),
      e.g. instead of WAIT "Password:" use WAIT "ord:"
   2. not re-execute an ON command to establish an already existing ON
      condition, e.g. instead of
           A:
               ON "login:" GOTO B
               SEND "^M"
               DELAY 2
               GOTO A
      Try
               ON "login:" GOTO B
           A:
               SEND "^M"
               DELAY 2
               GOTO A

You need not take any action if your scripts are working OK.  I expect to
have the final fix within a week or so and send Bob Page the kermit BYE
fix, the script fix and a new VT100 executable with the fixes incorporated.

Sorry for the problems.
---
Tony Sumrall   author of VT100 2.9 (and 2.8a and 2.8 and...)

[email protected] <=> amdahl!pccuts!acs

[ Opinions expressed herein are the author's and should not be construed
  to reflect the views of Amdahl Corp. ]

I'm missing something. I'm trying to use Zmodem from V2.9 and getting
nowhere. I've got the Arexx process running (at least i followed the
installation procedure and also inserted the following into my
s:startup-sequence:
	run sys:Rexxmast
and my system comes up w/o any complaining.
Question is: what else do I need to do? I suspect I don't have something
in my vt100 init file, and am not sure whether there are zmodem files
i need to put somewhere also. If this is already posted, pls just
give me a pointer. I've looked a bit, but may have overlooked it.

Thanx, Verell Boaen

You need to put the rz and sz (I think those are the names) into a directory
(like c:) and edit the s:vt100.init file (think that's the name) to tell it
where they are.

john

I've been having a problem with VT100 V2.9A's file name requestor.
Once I set a file name I'm stuck with it untill I exit VT100. For
example, If I want to do an ASCII capture to file FOO.TXT, I can do it,
but then if I click to turn off capturing, and then subsequently want to
use KERMIT to receive, or just to capture something else, I'm stuck with the
FOO.TXT file name. This is in the annoyance category as I can just rename
each FOO.txt before starting the next capture/transfer, but it's still a
pain. Didn't have this w/V2.8 and wondered if anyone has a workaround. 
Has this been reported to Tony Sumrall?
	Also, Would REALLY like to be able to occasionally select a resizeable
window so I can use the workbench screen and still get at the workbench icons
when memory is getting tight. The earlier VT100s had this feature, and it's
really needed for a small memory (eg: basic A500) user.


'Gards, Verell (BTW, I really like VT100 and appreciate all the help I've
received in the past.)