ado@alw.nih.gov (Arthur David Olson) (09/26/89)
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@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.