[comp.sys.ibm.pc] Interfacing serial printers to PCs

dbilar@antares.UUCP (Dave Bilar) (06/13/89)

In article <3484@i.sei.cmu.edu> gjp@sei.cmu.edu (George Pandelios) writes:
>    [ stuff deleted ]
>AUTOEXEC.BAT.  These programs operate by "watching" COM1 for incoming
>characters (XOFF) from the printer.  They tend to be COM files because they
>need to "sit" on a particular memory location. By using one of these programs,
>COM1 and the LQP03 can communicate successfully at 4800 or 9600 baud without
>buffer overrun.
>    [ ... ]
>SUPERSPL  which I believe to be a commercial product.  I was unable to
>discover who makes it, though.  The code works, but I'm taking it off my
>system (unless someone out there points me to the company).
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  George J. Pandelios			ArpaNet:	gjp@sei.cmu.edu
>  Software Engineering Institute	usenet:		sei!gjp



Hi George...
Sounds like you're referring to SUPERSPL.COM from AST, makers of the
famous Six-Pac Plus and other expansion/io/clock/multifunction cards
for the IBM-pc market.  It came on a disk of utilities that was supplied
with each AST card.  I wouldn't take it off your system though; it works
just fine!

--
Dave Bilar
Speaking only for himself...
PDP:  dbilar@antares   OnTyme: NSC.D/Bilar   LRV: Component Station
UUCP: {uunet,ames,pyramid}oliveb!tymix!antares!dbilar
USPS: McDonnell Douglas Network Systems Co., PO Box: 49019,
      ATTN: Mailstop F21, San Jose, Ca. 95161-9019   (408)922-8078
ICBM: 122 30'45''W     37 30'25''N  [Not exact, but close enough! :-) ]
"Remember:  its not _just_ an electric bulb, its a Dark Sucker!"

hollen@eta.megatek.uucp (Dion Hollenbeck) (06/14/89)

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.

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).


	Dion Hollenbeck             (619) 455-5590 x2814
	Megatek Corporation, 9645 Scranton Road, San Diego, CA  92121

                                seismo!s3sun!megatek!hollen
                                ames!scubed/

gjp@sei.cmu.edu (George Pandelios) (06/15/89)

Ed Clarke writes:

>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

Hmmm, indeed!  That's an interesting twist to the issue.  However, there 
are some other aspects of the two printers that should be considered:

    1.	True printing speed:  My LQP03 is only rated at 25 CPS.
	The LaserJet is substantially faster than that.

    2.	Buffer size (internal to printer):  Again, the LQP03 only has
	a 256 character buffer.  That's SMALL!!!!  I don't know the
	actual size of the LaserJet's buffer, but it's GOT to be bigger.
	I believe LaserJets have a minimum of 512K and can be expanded.
	Is that correct?  Can that memory be used for buffering?

With those two factors in mind, remember that I was able to get the
printer to work without a protocol in place (at 150 baud).  But you
can see why higher speeds are impossible without some sort of handshaking.
I think that explains why Ed's LaserJet is having no problem with 9600
baud.  It simply has the ability to move (print) greater amounts of data
at greater rates.

One other question:  Does the LaserJet possibly implement the hardware
flow control protocol under the covers?  Isn't that how other serial
printers work with IBM PC/XT/AT/Compatibles?  Let's hear from some 
more owners of serial printers.

Thanks for the response, Ed!

George

PS.  Keep those cards & letters coming.  I'm more than willing to send
     copies of XONXOFF.ASM and FLOW.ASM to anyone who wants them.  If
     the volume becomes intolerable, I'll post the sources to all my
     original news groups.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=