SEWALL@UCONNVM.BITNET (01/13/88)
Don Elton writes: > Sounds like you were losing data because you have >an unenhanced //e. If you get the //e enhancement kit you get new ROM's that >fix a design error whereby the //e turns off interrupts for a long time during >screen scrolls. TIC won't lose data at all if you have the enhancement kit However, we've got an old (unenhanced) //e connected by direct line to our mainframe that runs Ted Medin's Kermit 3.xx at 4800 baud (emulating a VT-100) with NO LOSS OF CHARACTERS (Super Serial card driver; the mainframe supplies no nulls). There is some character loss at 9600 because Ted uses the 80 column card firmware and it's just not fast enough for 9600. My impression is that software that addresses the CTRC (is that the right combination of letters?) directly shouldn't lose characters (with interrupts enabled) at even 9600. I wish there was an interrupts by-pass in TIC for those of us who, for one reason or another, haven't interrupts available. LOTS of BBS's will supply (optional) pad characters which eliminate the character loss. Frankly, as mentioned frequently in the past couple of days, there are LOTS of Apple 2 comm programs that emulate a variety of terminals (even grungy old 1984 Apple Access // does a <more or less adequate> VT-100). I haven't seen a bbs where emulation was any advantage nor a mainframe on which Xmodem is of any use (I've heard of VAX's that support XModem for text file transfer only, but I've not tried one). It happens we have SOFTERM's transfer protocol running under VM on our IBM 3091, but the code was written locally and is not generally available (Softronics expressed little interest in it - we did ask). Hence, Kermit seems to be the way to go (most mainframes that support anything appear to support Kermit). The short version is that I find Apple commware that emulates terminals but doesn't support Kermit generally uninteresting. Software that only supports Xmodem can be very useful for communicating with BBS's but terminal emulation is superfluous on any bbs existant in this corner of the globe. --------------------- ARPA: sewall%uconnvm.bitnet@cunyvm.cuny.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut
mccann@CS.WISC.EDU ("Lester I. McCann") (01/14/88)
The only protocol I can find that's available here is Kermit, so I'd have to agree with Murphy. I do all of my downloads via text capture, as I've never been able to get Kermit to work right (though I just got a new version or two that I have yet to try -- thanks, Grant!). ALl of this brings up a question: Which comm programs support the Kermit protocol? Does anyone have a list? Lester McCann g-mccann@gumby.cs.wisc.edu
delton@pro-carolina.cts.COM (Don Elton) (01/14/88)
The 16-bit non-shareware version of TIC (Talk is Cheap: Professional) will probably support Kermit (and other) protocols. The sad fact is that most people don't pay for shareware.. any shareware so I see little reason to add Kermit to the shareware version of TIC when I can add it to a non-shareware version and offer cheap updates to people who registered the shareware version. The only ways to avoid losing data at 1200 baud on an unenhanced //e is to bypass the firmware scrolling routines (by scrolling the screen yourself) or to have the host send nulls. Apple hasn't made the defective //e's since March of 1985 and a nominally priced fix has been available since that time. The //c and IIgs never had the bug in the first place. I don't see much reason to write extra code just to handle the older //e anymore than I see a reason to support the Apple II+. I can see no reason anyone would want a comm program that didn't use interrupts but maybe someone can tell me an advantage here that I haven't considered. TIC only supports the built-in ports of the //c or IIgs and super serial card clones and I believe that all super serial card clones, by definition, support interrupts. Another comment on Kermit... while I'll be adding kermit to TIC Pro, most apple users, notwithstanding the group using info-apple, have never heard of kermit outside of ETV perhaps. It's just not a high priority thing for most users but it will make its way into TIC Pro which you'll be able to order through the mail when it's finished. UUCP: [ ihnp4 sdcsvax nosc ] !crash!pro-carolina!delton ARPA: crash!pro-carolina!delton@nosc.mil INET: delton@pro-carolina.cts.com Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
SEWALL@UCONNVM.BITNET (03/16/88)
"Larry W. Virden" <osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU>writes: >...the point in this is in accessing such minor services such as >Compuserve, >Bix, Delphi, Genie, AppleLink, colleges, universities, local BBS, etc. Gee, I didn't think any of those services (other than colleges and universities which generally don't support Xmodem) supported terminal emulation. I gather, however, that your (implied) point is that you'd like to have only ONE piece of commware for all of those purposes. Perhaps if we could talk Ted Medin into incorporating Xmodem into Kermit? :-) Seriously, ProTERM may be just the thing for your "ideal." For the price (very little $$$), I don't mind learning two programs- say Kermit, which is truly low cost ;-), for emulation and mainframe file transfer and TIC or ZLINK for the rest ($35 or less). I have noticed that Commodore based BBS's get VERY confused by Apple DOS 3.3 text files (because the high bit is set) and MS-DOS bbs's get even more confused by them (because they don't include LF after CR in addition to having the high bit set). One nice thing about SOFTERM (yeah, I know it's too expensive) is that the high bit can be cleared (and LF added after CR if need be) as part of the transfer command (a feature I'd be more likely to find useful in ZLINK or TIC than terminal emulation). --------------------- Disclaimer: I like my opinions better than my employer's anyway... (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
mdelama1@ORION.CF.UCI.EDU (Michael De La Maza) (03/18/88)
Sewall mentions a while back that SOFTERM is a good comm program because the high bight can be cleared as part of the transfer command... he is right. I will sell my copy of SOFTERM to the first person who writes for $20. -- Michael de la Maza 714-854-7093 10 Tumbleweed Irvine, CA 92715 mdelama1@orion.cf.uci.edu
lwv@n8emr.UUCP (Larry W. Virden) (03/23/88)
The situation is that it is at a minimum a bother, and a maximum impossible, to work in a situation where you log in with your terminal emulator, make a connection, jump out to prodos and start up your file transfer program, transfer a few files via xmodem, jump out of that program, jump into kermit to transfer a few binary files, jump out of that program, and jump back into your terminal emulator. Kermit 3.8? is a great addition, as it allows two of these steps to be avoided if one has good kermit support on the host (cis doesnt have good kermit support - many folks I have talked to have been unable to do kermit transfers - I dont know about genie, delphi, etc.) -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@PSUVAX1 (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.