ALM-2 parallel port and LaserJet II [LONG]

[Arthur David Olson]

I've attached a copy of a letter I sent to Sun and (with permission from the
engineer involved) the reply I received.

I'd appreciate the insights of Sun-Spots readers on two questions:

1.	The Sun engineer writes that "The HP [LaserJet II] printer does not
	assert [the SLCT and RYD/PE] lines."  Is this true?

2.	Has anyone successfully hooked up a device to an ALM-2 for which
	bit 17 is set to zero in the "device" line?
-- 
	Arthur David Olson   ado at alw.nih.gov   ADO is a trademark of Ampex.

ado> What I've observed is that:
ado> 
ado> A.  The SYNOPSIS section of the mcp(4s) manual page has lines such as
ado>     device mcp0 at vme32d32 ? csr 0x1000000 flags 0x1ffff priority 4 ...
ado>     and the /sys/sun3/conf/GENERIC file has lines such as
ado> 	 device mcp0 at vme32d32 ? csr 0x01000000 flags 0x1ffff priority 4
ado>     where in both cases there are 17 bits set in the configuration "flags"
ado>     (the 0x1ffff's).
ado> 
ado> B.  The mcp(4s) manual page goes on to say that
ado> 
ado> 	Bit 17 of the configuration flags may be  specified  to  say
ado> 	that  the  interface  should  ignore  Centronics  SLCT-  and
ado> 	RDY/PE- when attempting to open the device, but this is nor-
ado> 	mally  useful only for configuration and troubleshooting. . .
ado> 
ado> C.  If you compile this program:
ado> 
ado> 		#include <stdio.h>
ado> 		#include <sys/types.h>
ado> 		#include <sys/ioccom.h>
ado> 		#include <sundev/mcpcmd.h>
ado> 
ado> 		main()
ado> 		{
ado> 			unsigned char	uc;
ado> 
ado> 			(void) ioctl(0, MCPIOGPR, &uc);
ado> 			if (uc & MCPRIGNSLCT)
ado> 				(void) printf("MCPRIGNSLCT ");
ado> 			if (uc & MCPRDIAG)
ado> 				(void) printf("MCPRDIAG ");
ado> 			if (uc & MCPRVMEINT)
ado> 				(void) printf("MCPRVMEINT ");
ado> 			if (uc & MCPRINTPE)
ado> 				(void) printf("MCPRINTPE ");
ado> 			if (uc & MCPRINTSLCT)
ado> 				(void) printf("MCPRINTSLCT ");
ado> 			if (uc & MCPRPE)
ado> 				(void) printf("MCPRPE ");
ado> 			if (uc & MCPRSLCT)
ado> 				(void) printf("MCPRSLCT ");
ado> 			(void) printf("\n");
ado> 			return 0;
ado> 		}
ado> 
ado> 	and then run it on a system where you've configured with
ado> 	"flags 0x1ffff" (and with a LaserJet II attached to the ALM),
ado> 	you get these results:
ado> 
ado> 		Script started on Wed Aug 23 18:43:26 1989
ado> 		elsie$ try < /dev/mcpp0
ado> 		MCPRIGNSLCT MCPRVMEINT MCPRSLCT 
ado> 		elsie$ echo Now I will turn off the printer
ado> 		Now I will turn off the printer
ado> 		elsie$ try < /dev/mcpp0
ado> 		MCPRIGNSLCT MCPRVMEINT MCPRPE MCPRSLCT 
ado> 		elsie$ exit
ado> 
ado> 		script done on Wed Aug 23 18:45:10 1989
ado> 
ado> 	If you then run the program on a system where you've
ado> 	configured with "flags 0x0ffff", you get these results:
ado> 
ado> 		Script started on Wed Aug 23 18:54:10 1989
ado> 		elsie$ try < /dev/mcpp0
ado> 		sh: /dev/mcpp0: cannot open
ado> 		elsie$ echo Now I will turn the printer off
ado> 		Now I will turn the printer off
ado> 		elsie$ try < /dev/mcpp0
ado> 		MCPRVMEINT MCPRPE MCPRSLCT 
ado> 		elsie$ exit
ado> 
ado> 		script done on Wed Aug 23 18:54:58 1989
ado> 
ado> 	The above results seem to indicate that the "0x10000" bit is indeed
ado> 	the "IGNore SLCT" bit (bit 17).
ado> 
ado> D.	If you configure a system with "flags 0x0ffff" and then try to run
ado> 	a LaserJet II printer off the parallel port, you get I/O errors
ado> 	(or, as above, you're unable to even open the device).
ado> 
ado> My conclusions:
ado> 
ado> 1.	The manual page statement that "Bit 17. . .may be specified. . .
ado> 	but this is normally useful only for configuration and
ado> 	troubleshooting" seems at odds with the fact that bit 17 *is*
ado> 	specified in both the SYNOPSIS line and the /sys/sun3/conf/GENERIC
ado> 	file, meaning that bit 17 is on in a normally-operating system.
ado> 	Either the "Bit 17" statement should be changed or the SYNOPSIS
ado> 	and GENERIC lines should be changed, yes?
ado> 
ado> 2.	It seems that, at least with a LaserJet II, bit 17 must be set
ado> 	for "normal operation."  It may be that this is only a problem
ado> 	with LaserJets; perhaps HP got the SLCT/PE signal polarity backward.
ado> 	Then again, perhaps Sun has it backward--the fact that when I
ado> 	turned off the printer and had MCPRIGNSLCT turned off I got
ado> 		elsie$ try < /dev/mcpp0
ado> 		MCPRVMEINT MCPRPE MCPRSLCT 
ado> 		elsie$ exit
ado> 	as output, indicating that the 3/280 thought a turned-off printer
ado> 	was ready for output, might indicate this.
ado> 
ado> 	If it's Sun that's wrong about SLCT, the thing to do would be
ado> 	to fix the logic and let the "bit 17" statement stand.  If it's
ado> 	HP that's wrong about SLCT, no Sun action is needed, though it
ado> 	might be helpful to add a note to the manual page so that folks
ado> 	would know that they needed to have bit 17 on.

Sun> After finally getting a chance to look over your message I think that
Sun> the operation of the bit is correctly stated in the manual.
Sun> 
Sun> Bit 17 of the configuration flags may be specified to say that the
Sun> interface should ingnore Centronics SLCT- and RDY/PE- (notice the
Sun> double negitive) when attemptiing to open the device, but this is
Sun> normally use....
Sun> 
Sun> The double negitation means to not ignore the SLCT and RDY/PE lines.
Sun> The HP printer does not assert those lines.  So with bit 17 of the MCP
Sun> driver configuration line set to 0 you will recieve an error.  The
Sun> reason this is not apparent when the printer is off is because the
Sun> lines are in an inconsistant state.  In this case our responce to this
Sun> is to assume asserted.
Sun> 
Sun> I believe that this follows the manual conventions.