SEWALL@UCONNVM.BITNET (Murph Sewall) (05/12/88)
>Everyone of course appreciates those who take the trouble to tune and >improve kermit -- but I would think in the interests of lessening >confusion only Ted Medin should be allowed to 'release' any versions >that have an 'official' sounding name -- the one recently mentioned, for >instance, should perhaps be known as 3.82-SEWALL, but definitely not >3.83. I'd also argue, but less strongly, that the ONLY versions of >kermit that should be released in any mass way (e.g., through a LISTSERV >mechanism) are those that are released through Columbia. I could quibble, but your first point is pretty well taken. 3.83 IS a beta copy (I believe I said that) and I DID ask Ted about posting it (It's as "official" as 3.82 which hasn't ever been sent to Columbia). You can call it whatever version you wish to, but it contains some significant improvements over version 3.81 (which is the one currently on the server at Columbia). The fact that BYE works will make quite a few folks happy. An awful lot of people have version 3.82, however obtained, and I don't believe that one will ever exist at KERMSRV (version 3.80 never did). Version 3.83 is stable (Ted's assessment) and word already is spreading around that it exists. The "delay" (if you choose to call it that) in sending it to Columbia is whatever time it's going to take to update the documentation (I won't bore you with details, but it'll be a little while). In the meantime, 3.83beta has some nice features (XModem for instance) that the one available from Columbia doesn't have. If very many people are going to want it, then APPLE2-L and comp.binaries.apple2 are clearly the most efficient way of making it available. Ted may well have a small improvement or two between 5/7/88 and the time he sends the new version off to Columbia. I don't think it a bad idea at all to download a new copy of KER383.2 from Columbia when it gets there and update it. Where do all those new versions of BLU and TIC come from (not Glen Bredon and Don Elton, do they)? Anyhoo, I certainly don't mind your asking me where I got 3.83 and howcome I decided to send it to APPLE2-L. BTW There was some sort of communications problem between Yale and Brown last night (backed up a few hundred files including the 2 parts of Kermit), so it will be a day or two before the backlog clears and those files arrive in your mailbox. --------------------- Disclaimer: The "look and feel" of this message is exclusively MINE! (subject to change without notice; void where prohibited) ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut
SEWALL@UCONNVM.BITNET (Murph Sewall) (05/12/88)
>Isn't speed wonderful kermit 3.83 has hit Compuserve on Monday already >and it hasn't made it through elsware. Was the improvement the Time extension >you mentioned earlier through INFO-APPLE or have other changes been made The thing about beta software is that there may be small subtle changes. If you have a copy of what appeared on Compuserve, try k-ESC, ? If it tells you about the cl(E)ar screen option, then it's at least as recent as the one I posted to APPLE2-L. I don't recall "time" extension? Changes since 3.82 1) if you QUIT to BASIC and type BYE, you get no longer get an "unclaimed interrupt error 2) SET PROTOCOL XMODEM ("vanilla" XModem - no CRC, no filespecs block) naturally that means SET PROTOCOL KERMIT (the default) 3) when connected to a host, the Kermit escape character (default is an ASCII null) followed by 'E' clears the screen, resets the 80 column and other display parameters which can be messed up by telephone line noise. My timing problem is that I shipped the files to APPLE2-L last night just as the link between YALEVM and BROWNVM crashed for 12 hours or so. Bitnet's file transfer protocol is to ship small files first. This morning there were nearly 500 files waiting on the link between Yale and Brown and the two Kermit files had been dropped to 480th or so. I just got a message from the LISTSERV telling me that the first file has arrived. I'd guess it'll be sometime tomorrow before the files reach the Internet (assuming nothing else goes wrong :-) --------------------- Disclaimer: The "look and feel" of this message is exclusively MINE! (subject to change without notice; void where prohibited) ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut
tucker@unocss.UUCP (Greg Tucker) (07/13/88)
At the risk of asking ANOHTER dumb question about an already beaten subject, I will proceed. 1. Does Kermit 3.83 support interrupts? One post said that the software will mess up at 9600 baud if interrupts are off, and yet, I still drop characters, which leads me to believe that it doesn't at all. How come the author(s) chose to use the "flow" scheme with each line feed, rather than just support interrupts like "ordinary" software. 2. Even with flow set at xon I still drop characters at the beginning of each line. I have accounts on both a Vax 8650 running VMS and a Sequent running Unix. How do I get either or both of these machines to support the xoff/xon scheme? How do I get either or both of these machines to avoid dropping characters when using a full screen editor such as edt, or any program that uses the ansi mode? 3. Is there any way to enable "ordinary" interrupt support with the software. If it helps any, I have an unenhanced //e with Applied Engineering's super serial compatible serial card. Thanks... -- ------------------------------+--------------------------------------------- Gregory A. Tucker- Consultant | Internet: conslt05%zeus.dnet@fergvax.unl.edu Campus Computing | Bitnet: CONSLT05@UNOMA1 Univ. of Nebraska at Omaha | UUCP: uunet!btni!unocss!tucker
elliott@yosemite.steinmetz (07/14/88)
In article <334@unocss.UUCP> tucker@unocss.UUCP (Greg Tucker) writes: >1. Does Kermit 3.83 support interrupts? ... > How come the author(s) chose to use the "flow" scheme with each line > feed, rather than just support interrupts like "ordinary" software. ... >If it helps any, I have an unenhanced //e with Applied Engineering's >super serial compatible serial card. > ------------------------------+--------------------------------------------- > Gregory A. Tucker- Consultant | Internet: conslt05%zeus.dnet@fergvax.unl.edu > Campus Computing | Bitnet: CONSLT05@UNOMA1 > Univ. of Nebraska at Omaha | UUCP: uunet!btni!unocss!tucker Even software that uses interrupts can run into problems on an unenhanced //e if it tries to use the firmware screen routines. They turn off interrupts for huge amounts of time during scrolling. (As many people on this network have pointed out to me, some more vivdly than othes... :^) If what you want is good vt100 emulation for your unenhanced //e, that works at high baud rates, you might want to try ATP-Pro, a ShareWare terminal emulator which I wrote. It supports VT100 completely (as far as the Apple hardware allows; ie, no 132 columns, etc.) as well as several other terminal types, has sophisticated macros and windows, special-function segments, and online documentation. And it avoids the problem that Kermit runs into since it does not use the firmware screen routines. You'll still want to use Kermit for file transfer (at least for the moment). But when it comes to emulation, ATP is really nice. (It works great on the enhanced //e and the //c as well, and the Pascal1.1 mode supports the //gs except for the more esoteric ATP features. I'm working on a //gs driver.) I have been posting copies around the net (one is trying to trickle its way through comp.binaries.apple2 right now). If you can find one, try it out! If you want to order a registered copy directly from me, send $15 (NY state residents add 7% sales tax) to: Jim Elliott 2214 12th St. Troy, NY 12180-2940 . . . . . . ... . . . . . . . . . . ... . . Jim Elliott / ...!seismo!uunet!steinmetz!crd!elliott / "Don't look, son, it's / Jim_Elliott%mts@itsgw.rpi.edu [school] a secular humanist!" / (or) elliott@ge-crd.arpa [work] . . . . . . ... . . . . . . . . . . ... . .
SEWALL@UCONNVM.BITNET (Murph Sewall) (07/20/88)
>At the risk of asking ANOHTER dumb question about an already beaten >subject, I will proceed. > >1. Does Kermit 3.83 support interrupts? One post said that the software > will mess up at 9600 baud if interrupts are off, and yet, I still It will surely drop characters if interrupts aren't active. As you can see, it also is possible to drop characters at 9600 baud even with interrupts active (if you are using the SSC driver, interrupts ARE active or you won't receive ANY characters from the host). > drop characters, which leads me to believe that it doesn't at all. > How come the author(s) chose to use the "flow" scheme with each line > feed, rather than just support interrupts like "ordinary" software. The problem is that the program is designed to support ANY Apple 2 with an 80 column card (including 2+'s) without having to write a separate driver for every conceivable 80 column board (and there are a LOT of them). The program works "well enough" but the scheme does have it's limitations. >If it helps any, I have an unenhanced //e with Applied Engineering's >super serial compatible serial card. Ah, there's the rub. At 9600 baud the nasty bug in the original //e's ROM DOES catch up even with FLOW XON/XOFF. At this point, you have two ways to go: 1) spend a modest sum and enhance the //e, or 2) slow to 4800 baud (that's about as fast as the display is capable of anyway). Murph Sewall Sewall@UCONNVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {rutgers psuvax1 ucbvax & in Europe - mcvax} !UCONNVM.BITNET!SEWALL [UUCP] -+- My employer isn't responsible for my mistakes AND vice-versa! (subject to change without notice; void where prohibited) "It might help if we ran the MBA's out of Washington." - Adm Grace Hopper
22149853@WSUVM1.BITNET (Duane Wessels) (07/24/88)
>Ah, there's the rub. At 9600 baud the nasty bug in the original //e's >ROM DOES catch up even with FLOW XON/XOFF. At this point, you have two >ways to go: > >1) spend a modest sum and enhance the //e, or >2) slow to 4800 baud (that's about as fast as the display is capable of > anyway). My unenhanced //e lost characters even at 1200... +---------------------------------------------------------------------+ | Duane Wessels Bitnet: 22149853@WSUVM1 | | | | "P is, for each individual, the number of minutes per month that | | that person spends thinking about the number P." | | -- Douglas R. Hofstadter | +---------------------------------------------------------------------+ Acknowledge-To: <22149853@WSUVM1>
SEWALL@UCONNVM.BITNET (Murph Sewall) (07/26/88)
>>Ah, there's the rub. At 9600 baud the nasty bug in the original //e's >>ROM DOES catch up even with FLOW XON/XOFF. At this point, you have two >>ways to go: >> >>1) spend a modest sum and enhance the //e, or >>2) slow to 4800 baud (that's about as fast as the display is capable of >> anyway). > >My unenhanced //e lost characters even at 1200... SET FLOW XON I've yet to see a mainframe that didn't support Xon/Xoff (I suppose there are some out there, and I'm told the VAX editors still won't work even with Xon/Xoff -- disable it apparently, but the "VM" in WSUVM1 suggests an IBM mainframe & Xon/Xoff works fine with UConnVM). Murph Sewall Sewall@UCONNVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {rutgers psuvax1 ucbvax & in Europe - mcvax} !UCONNVM.BITNET!SEWALL [UUCP] -+- My employer isn't responsible for my mistakes AND vice-versa! (subject to change without notice; void where prohibited) "It might help if we ran the MBA's out of Washington." - Adm Grace Hopper
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/31/88)
In article <8807251723.aa25106@SMOKE.BRL.ARPA> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >... I'm told the VAX editors still won't work even with Xon/Xoff... VAX is a hardware architecture; there is no "VAX editor". There is a vendor-proprietary operating system called VAX/VMS; since the vendor's terminals have required flow control since almost the beginning of time, it is unlikely that any of the system software provided in VAX/VMS doesn't support flow control. In fact, it is really the operating system's terminal handler layer, not user-level programs such as editors, that actually supports DC3/DC1 flow control. A large fraction (perhaps as many as one-half) of VAXes run some variant of the UNIX operating system. The only editor in common use on UNIX systems that disables the terminal handler's support for flow control is EMACS (some variant thereof; there are several). This is clearly a design error, but the "owner" of EMACS maintains that terminals should not need flow control so he refuses to consider supporting it. Reasonable variants of EMACS (such as JOVE) have this fixed. (The symptom of a broken EMACS is that it automatically enters "search" mode without being asked to.)