Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!csd4.milw.wisc.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!gjp From: gjp@sei.cmu.edu (George Pandelios) Newsgroups: comp.sys.ibm.pc Subject: RE: RE: RE: inserial printers to PCs Keywords: XON XOFF LQP03 LaserJet Message-ID: <3505@i.sei.cmu.edu> Date: 15 Jun 89 12:28:46 GMT Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA Lines: 64 Dion Hollenbeck writes: >From article <626@acheron.UUCP>, by clarke@acheron.UUCP (Ed Clarke/10240000): >> From article <3484@i.sei.cmu.edu>, by gjp@sei.cmu.edu (George Pandelios): >> - My AT-class computer is unable to print a file at data rates greater >> - than 150 baud without overflowing the printer's buffer. This is be- >> - cause the LQP03 uses an XON/XOFF protocol, whereas DOS implements a >> - >> - SUPERSPL which I believe to be a commercial product. I >> - was unable to discover who makes it, though. >> >> Hmmm - I've been using the following to drive my LaserJet at 9600 baud. >> The LaserJet uses XON/XOFF protocol: >> >> MODE COM1:9600,N,8,1,P >> MODE LPT1:=COM1 >> >What you have done with the above commands does not have anything to >do with XON/XOFF protocol handling. Neither does the BIOS support >it nor the above commands turn it on. All you are doing is setting >the serial port to the appropriate baud rate, data bits, stop, bits, >parity and retry on timeout. The P parameter merely causes continuous >retries on timeouts to the asynchronous adapter. I would guess that >you are able to get this to work only on a fluke. You have done >nothing to implement XON/XOFF protocol. Exactly. That's what I was trying to say (poorly). In discussing the relative buffer sizes and throughput speeds of the LQP03 and LaserJet, I was trying to point out how Ed might be avoiding a buffer overrun condition by the skin of his teeth. I also speculated that the LaserJet might implement the hardware flow control protocol. As you said, the MODE commands do not affect/implement the protocol involved. I did not mean to imply (by omission) that they did. >If anyone is interested in a discussion of XON/XOFF protocol in >greater detail, I can supply it. I have implemented XON/XOFF >protocol in 6 different operating systems and know what it is >supposed to do and how it actually works. I can also supply information >about hardware handshaking and ETX/ACK protocols. Much of what I >do for a living is implement serial device drivers on all kinds of >operating systems and proprietary hardware. I also program at the >very lowest level extensively on the PC (I have ported MS-DOS to >several different PC hardware environments). I would certainly like to hear about the XON/XOFF protocol. Based upon the number of requests I have had for XONXOFF.ASM and FLOW.ASM, I think there are some people out there who would benefit by such a discussion (myself included). At the very least, please e-mail to me. Thanks, Dion. George =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= George J. Pandelios ArpaNet: gjp@sei.cmu.edu Software Engineering Institute usenet: sei!gjp 4500 Fifth Avenue Voice: (412) 268-7186 Pittsburgh, PA 15213 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Disclaimer: These opinions are my own and do not reflect those of the Software Engineering Institute, its sponsors, customers, clients, affiliates, or Carnegie-Mellon University. In fact, any resemblence of these opinions to any individual, living or dead, fictional or real, is purely coincidental. So there. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=