[...Once again following up to myself...]

In message <200212022218.gB2MIMk02584@fearless-vampire-killer.waterside.net>, 
I wrote thusly:

-> [...Following up to myself...]
-> 
-> In message <200212010128.gB11Srd12639@fearless-vampire-killer.waterside.net>
-> ,
-> I wrote thusly:
-> 
-> -> In message <000501c29374$07394b80$6601a8c0@caldwell>, you write: 
-> -> 
-> -> -> Is printing to the parallel port (lpt0) supported in NetBSD sparc64 - 
-> -> -> on a Sun Ultra 5?
-> -> 
-> -> So I tried after Martin's addition of the lpt driver major numbers to the
-> -> system, and get the following results:
-> -> 	(1) Using /dev/lpa0: nothing seem on printer, haven't yet hooked 
-> -> 	    up the breakout box to see if signals are being twiddled or 
-> -> 	    not; the printing job looks like it thinks it's done quite
-> -> 	    quickly.
-> 
-> This appears to be a timing issue, as the driver actually believes that
-> all the bytes have been pushed out.  I noticed there are some DELAY(1)'s
-> in the lpt.c code and recall that a few ports had off-by-one errors in 
-> their DELAY() macros or delay() functions so a DELAY(1) was in effect a
-> no-op... I'll check this out, but otherwise it looks like it's going to
-> have to be down-and-dirty tweaking until things work.

Actually, the sparc64 DELAY() looks to be totally sane, and this was just
a matter of the MI driver not having enough of them to make things work on
faster machines... According the the docs I found on the simple parallel
port transfer modes (like the PC-compatible SPP uni-directional mode), the
signals to the printer (data included) needed to be held for a minimum of
500ns... I added some DELAY(1)'s to the code and sure enough, my printer
now works, at least in polled mode.  I checked in these changes, and they
are available in rev. 1.61 of syssrc/sys/dev/ic/lpt.c...

-> -> 	(2) Using /dev/lpt0: printer starts up and makes some noises, looks
-> -> 	    like it's going to print but never[*] gets to the point of 
-> -> 	    producing any output.
-> 
-> Here, the problem is that no interrupts are generated.  I didn't have the
-> SuperIO docs on hand when playing with this last night, so I'm not sure if
-> we simply don't set up enough registers for interrupts to be generated, or
-> if there are other issues of some kind...

I haven't made much progress on the interrupt-driven mode, and now that
the polling mode works, I probably don't care *too much*, but I'll try
and look at this a bit more (esp. since I'm wondering if our driving the
signals too fast may have actually caused the printer to never signal an
ACK, thus not giving the parallel port hardware a reason to generate an
interrupt...).

I actually did unpack the x86 system for other reasons (needed to burn a
CD), but never got around to connecting the printer to it 8-)

--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill