Printer Connection Problem

[Mark Lawrence]

I'm *trying* to hook up an NEC LC-890 SilentWriter PostScript Page 
printer to our Sun 3/260 (running SunOS 3.5, thank goodness!) on 
/dev/ttya.  The line for the port in /etc/ttys looks like thus:

0zttya

The entry for 'z' in gettytab looks like thus:

z|std.19200|19200-baud:\
	:sp#19200:

The /etc/printcap for the printer looks like thus:

lp|lw|ps|PostScript:\
	:lp=/dev/ttya:br#19200:rw:\
	:fc#0000374:fs#0000003:xc#0000000:xs#0040040:\
	:mx#0:sf:sh:

The printer is set up through an LCD menu system and is set thus:
	RS-232 interface
	19200 baud
	8 data bits
	1 stop bit
	space parity
	XON/XOFF flow control

Communications between the Sun and the printer work nominally, that is, I
can send trivial postscript files (when the printer is in postscript
mode) and plain ascii files (when the printer is in its HP LaserJet
emulation mode) and I get good hardcopy.  I run into problems when
sending multiple pages (large amounts of bytes) to the printer.  Sometimes
one or two pages will get printed and the rest of the output gets sucked
into some black hole.

I've tried the following actions to figure out what's going on:

I switched the interface speed to 1200 (changed the entry in ttys and
printcap; sent HUP to init, killed and restarted lpd, changed the
selection on the printer).  I was able to get many more pages out but
ALOT slower.  Still not totally reliable output.  This led me to believe
that perhaps flow control was not working properly.  The combination of
flag and local mode bits in the printcap were suggested by Frame in
the Installation section of their Reference Manual when utilizing a
PostScript printer without Transcript.  I've studied the tty(4) man page
and all looks sensible.

What I don't know is whether to trust what /usr/5bin/stty is telling me
about that port after refiring up the lpd.  It says:

}112 drd:/etc# /usr/5bin/stty -a < /dev/ttya
}speed 19200 baud; line = 0; intr = ^c; quit = ^|; erase = DEL; kill = ^u;
}eof = ^d; eol = ^`; swtch = ^z
}parenb -parodd cs7 -cstopb -hupcl cread -clocal -loblk 
}-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc 
}ixon ixany -ixoff 
}isig icanon -xcase echo -echoe echok -echonl -noflsh 
}opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

I *think* it's saying that even parity is turned on and ignore parity is
set and that xoff is off.  The man page fails to mention what ANY of
these codes mean.

I tried switching to the DTR (hardware) mode of flow control by clearing
the TANDEM bit in the flag in the printcap and selecting DTR at the
printer.  I killed and restarted the lpd.  Is there anything else that I
must do to make the tty recognize DTR and send DSR?  Anyway, this action
didn't help matters any.

I tried sending the postscript patch to the printer that Frame supplies.
It follows:
----------patch begins
%! 
% This is the uart patch to fix timeout errors on the LaserWriter.
% This is the 4/4/86 version of the patch.  Earlier patches do not
% work reliably most of the time.  This one seems to work OK.
0000000000			% the exitserver password

version (23.0) ne
   {(Patch not installed -- wrong printer type or version) = stop} if
statusdict /Patch1Installed known
   {(Patch already installed -- not installed again) = stop} if
serverdict begin exitserver
statusdict /Patch1Installed true put
currentfile eexec
c3c703843e75cc772962e3a7fadee742bb1258167ac7020cbc1cdfd379c35f53
da38afaed75c86541fde979ff594180fe542991f2199c8614247e4a1e3e5ecff
8bc3844d36e2d091e9f649518473592b44be262c7a2929ac4a9acd626bd3c441
e2aae320e60b2c21e02bc9c4f3cde0d5eca674f5b0bbff3ee860a7cd2e4e9f7b
9eed9b1286e5a9b9b0fdf8e73951152837a16a6913e477cc8a4f3cebbf2e78e8
fe5b0f92d45a274e75df31e5182cd81dce61bc53bdb8685f0a7ce24c0b8440f7
67b7fd750bb998fc775415b1c7b8502ea7c744ccb807635f7244d3fdd6ebd01f
634c9f3241fddc1a95d62bfb710a9ea6831ec6e1792f60503f077868e860dc3a
518d8ac29dc625ec65157889cd1f943a37eb55ef0e44c3a4776a481f1dd10cda
79b3db9907295c0ab9e3142df3ef0840b07f29d67c4f8aba333c9cc6e9f57d3f
47083e0bd9e85151ef158308a7d991b02ddcf47bffe6fed2f8e342dd7d2f81ca
80bb689bd0cb5af2a471b5577a4f8dbdfd2b0fcd0267bfa4dc6038bc235d3d8b
35469a680b41dc95e6a1d48ba543d291575d72475ef512492547629c4db741b8
68705f01282c230e1570cea8daea989707e99dce1d11d561256bd24608a66945
2042384aadfcc25cb0167b5896b1a13092d0a7c4ce1343e30834de5d5df345b9
ccb742acf36f7d3a9b43361cf5a9e0121fec84ba8b6c06312a71600ab9783ddc
59b8cb4da03019e82690df5cb2aefd9026aed30efb24b19e5405410685eb35b3
b25cf8ba535156ee600749abf2e3c572313c62dcd9492ca3abcfe7ee8fd40410
902f417c82908b412c9a826206f4292ab5196013a5f3615661cf81fc60b36a84
f457c2adb1a0c1c19f089d170de47d6933ce247d44865035caa1a6d4a2f6986f
9856de5f3d05a5a1020bce9768df8e8aab928b90029dfc2bbb715e19b5e7bc3e
11f05c1dad24849f8aadb7867f9d92f4400a432cdd6587057c582dc25fbeadde
f75121202e2a90dc6a4491ae9ee2b39c5fab5071a2f415d4a3cf8357fff771d8
790cc5788d506086c5a07ddbc2997f3abe28972cd40275c0117c77f479fd0b74
53a0bfcd82f30d1eb3c35fc914657d6f484bf3be81c54238267ccc2a19ec42a3
1336014c6446b12e3fe7746b658f829c52173a78e456ad78c2d65a3209949a5a
735d3795579151ee0102773c204134e8563b011a90c7cf0622058081c60b4d5d
6a146eb610c92e2e9c05f7ca40a1375e7c397def7f0d6a4c65e22728ae30adc2
b1b088339a7e7ab8f2dc6a3b5abd1318663cc5d3c37edd57f8ace64a565d1775
6e5a1268986105c918547306e0bf12d128220771e074323746ac15c52ef16e95
c0e62a0746b7c202a2e2aba2060cd64d5f656dbeb1fa837734d4a23093ddb312
537c0a6f8e224e5aa6cd22f1740e3611550b85d1a447c58ca8
------patch ends

Anyway, that didn't affect anything.  I tried setting the CRMOD flag in
the printcap and killing then restarting lpd.  That didn't make it work
better either.

At this point I'm at a loss and all I've got is a vague suspicion that 
flow control is the culprit.  I'm under the assumption that If I can print
anything at all, XON/XOFF flow control should work regardless of whether
pins other than 2,3,and 7 (Transmit, Receive and Ground) are connected 
or not.  Isn't that so?

I have tried both modes of flow control at line speeds of 9600, 4800 and
2400 also.  Basically, the lower the speed, the more hardcopy you
generally get but not reliably.  Can you suggest anything I can do to
make this interface work?  Especially, can you tell me how I can verify
that the tty is actually set in the modes I think I set it and how I
force it to use hardware DTR/DSR if I so wished?

Any boots here *much* appreciated.

Mark
-- 
 DRD Corporation                     | [uunet!apctrc,romed,tulsun]!drd!mark
 6111 East Skelly Drive Suite 415    |     apctrc!drd!mark at uunet.UU.NET
 Tulsa, OK 74135       (918)664-9010 |      mlawrence at jarsun1.ZONE1.COM
+------------------------------------+--------------------------------------+