ALM-2 parallel port and LaserJet II [LONG]
Arthur David Olson
elsie!ado at alw.nih.gov
Tue Sep 26 05:31:18 AEST 1989
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.
More information about the Comp.sys.sun
mailing list