Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!UMIX.CC.UMICH.EDU!hyc From: hyc@UMIX.CC.UMICH.EDU (Howard Chu) Newsgroups: comp.sys.atari.8bit Subject: OmniCom Kermit Troubles Message-ID: <8612171830.AA20961@umix.cc.umich.edu> Date: Wed, 17-Dec-86 13:30:41 EST Article-I.D.: umix.8612171830.AA20961 Posted: Wed Dec 17 13:30:41 1986 Date-Received: Thu, 18-Dec-86 07:07:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Summary of problem - with OmniView, OmniCom, and P:R Connection running with the "standard" RS232 device handler, Kermit uploads hang OmniCom. Mediocre solution - use PRC.SYS instead of the 850 RS232 handler. Gripes - the 850 RS232 handler signals when its buffer overflows, allowing OmniCom to send an XOFF until it catches up. The PRC.SYS does not. This is usually not a problem, but I also run OmniCom over a 9600 baud line, and it becomes pretty important then. The display seems to max out at about 2700 baud, so buffer overflows mean garbled text. With the 850 handler, the XOFF takes care of things just fine. With PRC.SYS, I get a mess. And, of course, with the 850 handler, I can only receive files, whereas the PRC.SYS will allow both sending and receiving with no problem. This seems to only be a problem with OmniCom and the 850 handler, I don't recall it happening with the PD Kermit. I'm curious, Dave, what is it about OmniCom that makes it so incompatible with the P:R Connection? The initial version wouldn't work at all without PRC.SYS, while the version I got recently works "most of the time..." (I'm also curious as to what you used to write it; the load vectors for that thing are horribly inefficient!) -- Howard Chu hyc@umix.cc.umich.edu