kolb@nisc.nyser.net (Christopher Kolb) (07/13/89)
i wrote a while back about what was needed to insure to the interoperability between a sun3/60 (or any sun, using the serial line port on the processor board) and an apple laserwriter IINT. i received plenty of responses, the majority of which were requests to pass this answer on when i had gotten to one. so i decided to go public with my findings (i never did get it working, and it has been shipped to it's user who will have use cat instead of lpr... of the suggestions i received, some only might have helped if i were running sun os 4.0 (using a new printcap tag that describes the attributes of the rs232 line), while others were flat wrong (yes, you do *need* the null modem adapter or a null modem cable). others however were on target. the handshaking should be set to XON/XOFF, *not* DTR. this is because the sun is not fast enough to handle the interrupts generated by hardware handshaking. also, it should be set to 8 data bits and one stop bit. the line speed in 9600 b/s. using this configuration, i am now able to cat postscript files directly to the laserwriter, and it does the right thing. this is done like below... (stty 9600; cat stupid.ps) > /dev/lp i am also able to use 'tip' to type postscript commands directly to the interactive postscript interpreter that is built in to the laserwriter. again, it does the right thing. so the communications seem to be set up correctly, as does the laserwriter itself. yet lpr still does not work. so the postscript filters are now suspect. i am running transcript 2.0. i know about the communications problems (pscomm), without knowing exactly what those problems are. it was suggested that we upgrade to 2.1, and it is on order, which means that we may get it 6 to 8 weeks from now. the 2.0 stuff works on our other laserwriter that is wired up to a port on an alm2. it works just fine (well... it works well enough for the time being). the symptoms are that i invoke 'lpr -Pps -h file-name' and what is see running is the ps filter 'psof' (which is supposed to invoke psbanner). this process hangs out for awhile and then dies. the green light on the lw that signifies that a job has started and eof has not been seen yet, never blinks. the job forever stays in the print queue until it is manually removed. (btw, if i give lpr the -h flag, wouldn't that mean that psbanner shouldn't get run and that the psif filter should be used instead of the psof filter) (btw2, i never do see the psbanner process itself running...) so that's the end of my tale. i no longer have the lw on my desk to play with. but i am still curious as to why it wouldn't work. any ideas out there... christopher kolb NYSERNet, Inc. Network Information and Support Center
beau@ames.arc.nasa.gov (Beau James) (07/19/89)
-- In SunSpots v8n69, kolb@nisc.nyser.net (Christopher Kolb) writes:
-- of the suggestions i received, some only might have helped ...
-- while others were flat wrong ...
--
-- others however were on target. the handshaking should be set to XON/XOFF,
-- *not* DTR. this is because the sun is not fast enough to handle the
-- interrupts generated by hardware handshaking.
This particular comment is flat wrong. The speed of the Sun is not an
issue. Lack of software support in the driver (and bugs) are the problem.
"Hardware handshaking", usually using the CTS signal line, need not
generate any interrupts at all.
There are two directions of flow control: the external device asking the
Sun to stop sending, and the Sun asking the device to stop.
CTS flow control for the Sun-to-device direction is implemented by the
serial I/O chip hardware, at least for the chips used on the Sun CPU board
(Zilog 8530 SCCs). When the device driver initializes the chip properly,
then CTS going away (going high) automatically stops the transmitter on
the chip. (The driver can also ask the chip to generate an interrupt on
CTS transition, if the driver really wants to know about it.)
For the device-to-Sun direction, the Sun flow control software has to know
that it should raise the RTS hardware line rather than send an in-band
"stop" character (^S), and later drop RTS rather than send a "start" (^Q)
character. The driver did not offer that capability in release 3.x, and
it didn't work in 4.0, but it is fixed by YAPT5.5c and in 4.0.3 (or so
we've been told by Sun).
The USARTs and UARTs used on other boards, e.g. ALM-1s and ALM-2s, have
similar capabilities. Of course, the CTS & RTS signals have to be
properly cabled from the chip to the device, which is not always the case
(as with the "default" cable wiring configuration of the ALM-1).
Beau James beau@Ultra.COM
Ultra Network Technologies {sun,ames}!ultra.com!beau