CLDLV@NASAGISS.BITNET (Dimitri Vulis) (11/14/87)
>From: mcvax!minster.york.ac.uk!john@uunet.uu.net >Date: 30 Oct 1987 13:38:13 GMT > >My department has an Apple LaserWriter Plus connected to the serial >output of a Sun 3/280 fileserver. ... > ... the silos of the Sun serial port are emptied so quickly >that one character pulse train immediately follows the preceding >one, and that overrun errors occur in the UART of the LaserWriter's >RIP. Our department (my school, CUNY, not here) has a SunWriter (identical to Apple LaserWriter) that used to be connected to a Sun (now it's on a PS/2 model 60). When you drive it at 9600 bps, every 10 chars or so it sends you a xoff and then you have to wait till it send you a xon. Since you did not explicitly say that your driver waits for xoff/xon, I presume that your problem MAY lie there. Most modern (post-1970) software expects the adressee to do its own buffering. ----> Adobe stinks. DV P.S. Your other printer sure sounds nice.
holtz@cascade.carleton.CDN (Neal Holtz) (12/18/87)
> Sender: Dimitri Vulis <CLDLV@NASAGISS.BITNET> > Subject: LaserWriter losing characters > ... > Our department (my school, CUNY, not here) has a SunWriter (identical > to Apple LaserWriter) that used to be connected to a Sun (now it's on > a PS/2 model 60). When you drive it at 9600 bps, every 10 chars or so > it sends you a xoff and then you have to wait till it send you a xon. I was extremely dubious when I saw this, so I ran the following tests: Hardware: a) Apple LaserWriter Plus, PostScript Version 38 (I think). b) OEMTEK AT clone (MS-DOS, obviously). c) RS232 connection at 9600 baud, XON/XOFF flow control. Software: Simple homebrew C Interface to an RS232 driver. C program simply copies from file to one of the serial ports. RS232 driver is the set of assembly language, buffered, interrupt driven serial i/o routines, distributed with the public domain UUPC mail program (but fixed by me to "correctly" handle XON/XOFF flow control). The C program also continually checks for data from LW, and displays everything so received on the screen. Software overhead seems to limit transmission speed to about 1250 chars per sec (measured by sending a large file to a serial port set at 19200 baud and not connected to any device). This is significantly higher than the 9600 baud rate of the LW, so should not have been a mitigating factor. Note that measured rates will be *very* slightly "in error", as I measured time between start and end of sending chars to the 500 char buffer, not between appearance of first and last chars on the serial line. Test 1: simple transmission of the MACPREP header file. This probably does not cause any graphics computation in the LW, and certainly causes no output. File size: 27000+ chars Avg. transmission rate: 976 chars/sec (i.e., about 30 sec.) No XOFF's received from LW. Test 2: A 9 page extract from a LaTeX document; the DVI converted to PostScript using my own DVI->PS driver. The data contains many downloaded character bitmaps, and the resulting PostScript deposits many small bitmaps using the "imagemask" operator. File size: 147000+ chars Avg. transmission rate: 788 chars/sec. Total of 16 XOFF's received from LW. First XOFF received after 32000+ chars. Usually at least 2000 chars between XOFF's (this varied a lot, from < 1000 to > 5000). Test 3 (incomplete): a different set of pages from the same LaTeX document. First XOFF received after 46000+ chars. Two years experience with a LaserWriter (but no monitoring of serial transmissions) would lead me to beleive that its behavior would not be significantly different from my LW+). > ... Most modern (post-1970) > software expects the adressee to do its own buffering. > ----> Adobe stinks. Perhaps DV would like to rethink this. Or perhaps SunWriters are not identical to LaserWriters. - Neal Holtz Carleton University
lharris@gpu.utcs.toronto.edu (Leonard Harris) (12/21/87)
Hi. I have encountered the same problem on both apple laserwriters and Nec and Oki lasers. It usually occurs on files that use lots of macros and the problem is it drops characters or loses part of a postscript command resulting in an error. This is using an ibm pc/xt/at through either the serial or parallel port. I find that if I download the file using a modem program that inserts nulls after each line the problem goes away. Is the xon/xoff handlers in Postscript bad ? (ver. 38 and 47 roms) /leonard