hyc@UMIX.CC.UMICH.EDU (Howard Chu) (12/17/86)
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
DYOUNG@A.ISI.EDU (C. David Young) (12/18/86)
I have no idea what the problem is with the P:R connection and the 850 handler. If I knew and thought I could compensate for it in OmniCom I would. The thing is evidently not completely 850 compatible as their ads claim. I would contact the manufacturers and complain. I use the Atari Macro Assembler which generates those inefficient load vectors. With a little effort you should be able to convert the file to one continuous load. Since I always run it out of a ramdisk I never notice. David -------