mike@ut-emx.UUCP (Mike O'Donnell) (04/28/89)
Some time ago I requested information on how to configure a printer to a 386 PC via the parallel port. I was having some difficulty using the 'lpset' command to turn the transparency mode on. I got about six responsesm three of which suspected that the AT&T driver was broken. One respondent said that someone had a replacement lp device driver. If anyone knows of such a beast I would sure like to get ahold of it. I am running Microport SYSV/386 and DOSMerge. Thanks, Mike O'Donnell Lower Colorado River Authority 3001 Lake Austin Blvd., Suite 201 Austin, Texas 78767
plocher%sally@Sun.COM (John Plocher) (05/03/89)
In article <12503@ut-emx.UUCP> mike@ut-emx.UUCP (Mike O'Donnell) writes: >some difficulty using the 'lpset' command to turn the >transparency mode on. (with Microport V/386) You need to use the "raw" lp devices (/dev/rlp*). These are the same as the normal devices (/dev/lp*) but with 128 added to the minor device numbers. (The 7 below is what I think I remember the major number for lp was ...) To make them: mknod /dev/rlp0 c 7 128 mknod /dev/rlp1 c 7 129 mknod /dev/rlp2 c 7 130 Then just link /dev/lp to the right one: ln /dev/rlp0 /dev/lp >respondent said that someone had a replacement lp device While I was at Microport I rewrote the lp driver and shipped it to several people. It worked a lot better than the stock one, but it still had the "cooked" garbage in it (backwards compatable - I don't know ANYONE who uses it!) Since they say they are still in business, call them and ask for it - they can't hate me any more than they already do :-) In the V/386 3.0e.1 release (and with the 3.0e CD-1 disk) I put quite a few "shar" files containing various device drivers in /src. This includes spkr, a lp replacement (not my mods), a mouse driver, and many more. These are all freely distributable, so you can get them from anyone who has them. -John Plocher
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/03/89)
>In the V/386 3.0e.1 release (and with the 3.0e CD-1 disk) I put quite a few >"shar" files containing various device drivers in /src. This includes spkr, >a lp replacement (not my mods), a mouse driver, and many more. These are all >freely distributable, so you can get them from anyone who has them. Could someone who has these make them available via ftp or anon uucp? -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
hwh@cup.portal.com (Harold W Hankins) (05/04/89)
In 102496@sun.Eng.Sun.COM, John Plocher writes: > In the V/386 3.0e.1 release (and with the 3.0e CD-1 disk) I put quite a few > "shar" files containing various device drivers in /src. This includes spkr, > a lp replacement (not my mods), a mouse driver, and many more. These are all > freely distributable, so you can get them from anyone who has them. > > -John Plocher Will someone who has these driver sources please mail them to me ? Even BETTER, please post them in alt.sources so that everyone will have access to them and they'll be stored in the archives. Thanks, Hank Hankins hwh@cup.portal.com Point of Sales Systems, Inc. Camarillo, CA
cutter@cutsys.UUCP (Bernie Hoffstadt ) (05/05/89)
In article <102496@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: >While I was at Microport I rewrote the lp driver and shipped it to several people. >It worked a lot better than the stock one, but it still had the "cooked" garbage >in it (backwards compatable - I don't know ANYONE who uses it!) (You must use a >80 col. window in your editor :-) Does your driver fix the problem whereby if your printer isn't turned on, but is connected when you boot Unix, /dev/lp refuses to work? It will even stop working if I take the printer off line while it is printing. Both cases require a reboot to regain functionality. And how about all those parallel cards I've tried that cause a delay between printing each line under Unix, but work fine under Dos? 2 out of 3 cards seem to bring on that symptom. I'm currently using 386v3.0e, but had the problems with SysV/AT also. -- Bernie Hoffstadt (503) 752-5929 * Internet: cutter%cutsys.UUCP@CS.ORST.EDU 1437 N.W. 9th st. -or- 753-1646 * -or- cutter@jacobs.CS.ORST.EDU Corvallis, Oregon 97330 **** UUCP: {tektronix,hp-pcd}!orstcs!cutsys!cutter
bill@bilver.UUCP (bill vermillion) (05/06/89)
In article <427@cutsys.UUCP> cutter@cutsys.UUCP (Bernie Hoffstadt (753-1646)) writes: >In article <102496@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: >>While I was at Microport I rewrote the lp driver and shipped it to several .. >>It worked a lot better than the stock one, but ... > >And how about all those parallel cards I've tried that cause a delay >between printing each line under Unix, but work fine under Dos? Delays in printing are not just a Unix problem. I have seen it on SCO's Xenix, 2.3.1 and 2.2.3. First on an AST 386, latter on an IBM 80. The AST seems to recover after doing a page or so. The IBM driving a laser printer would go into "super slow mode" of 1 page every two minutes. I suspect it is something in the orignal sources supplied to uPort, SCO, and probably relates to the re-boot printer problem on Interactive's. Anyone had printer problems on a generic AT&T 386 release? -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
plocher%sally@Sun.COM (John Plocher) (05/09/89)
+---- In <536@bilver.UUCP> bill vermillion writes: | +---- In <427@cutsys.UUCP> Bernie Hoffstadt writes: | | And how about all those parallel cards I've tried that cause a delay | | between printing each line under Unix, but work fine under Dos? | +---- | Delays in printing are not just a Unix problem. I have seen it on SCO's | I suspect it is something in the orignal sources supplied to uPort, SCO, and +---- The problem is related to interrupts: lp0 and lp1 both use interrupt 7 (lp2 uses interrupt 5) some parallel ports on Herc clones do not generate interrupts (correctly) The microport driver conceptually works as follows: OPEN Enable the port interrupts timeout(1 second, watchdog, device) WRITE loop till no more data dump text out till status = notready sleep( on something relating to this device) endloop INTR (Generated on the transition from notready to ready) wakeup( ...device) WATCHDOG (called once a second) wakeup( ...device) timeout(1 second, watchdog, device) CLOSE disable INTR and watchdog It does NOT do reliable interrupt sharing for lp0 and lp1. If interrupts are working the flow is: open turn on intr and watchdog write dump text till not ready sleep wakeup( BY INTERRUPT from printer) dump text till not ready sleep wakeup( BY INTERRUPT from printer) done with this "write" return close turn off intr and watchdog If interrupts are NOT working the flow is: open turn on intr and watchdog write dump text till not ready sleep watchdog activated because no interrupt for 1 second wakeup( by WATCHDOG) dump text till not ready sleep watchdog activated because no interrupt for 1 second wakeup( by WATCHDOG) done with this "write" return close turn off intr and watchdog -------- -John Plocher