gjp@sei.cmu.edu (George Pandelios) (06/15/89)
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. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
tj@gpu.utcs.utoronto.ca (Terry Jones) (06/21/89)
A great utility that someone once sent me was LPTCOM1 which redirects output destined for any lpt port to com1 with xon/xoff handshaking. xonxoff.asm (if it is the one I have used) is a device driver and I have had unexplained lockups with it on many different machines. tj