*BSD News Article 68396


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!Germany.EU.net!EU.net!newsfeed.internetmci.com!news.sprintlink.net!neonramp.com!cynjut.neonramp.com!cynjut.neonramp.com!not-for-mail
From: burgess@cynjut.neonramp.com (Dave Burgess)
Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers
Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 9 of 10)
Supersedes: <386bsd-faq-9-830584807@cynjut.neonramp.com>
Followup-To: comp.unix.bsd.netbsd.misc
Date: 13 May 1996 01:00:39 -0500
Organization: Dave's House in Omaha
Lines: 865
Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu
Expires: 05/31/96 01:00:07 CDT
Message-ID: <386bsd-faq-9-831967208@cynjut.neonramp.com>
References: <386bsd-faq-1-831967208@cynjut.neonramp.com>
Reply-To: burgess@cynjut.neonramp.com (386bsd FAQ Maintainer)
NNTP-Posting-Host: cynjut.neonramp.com
Keywords: FAQ 386bsd NetBSD FreeBSD !Linux
X-Posting-Frequency: Posted on/about the 13th and the 27th of every month.
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.announce:171 comp.unix.bsd.freebsd.announce:233 comp.answers:16715 news.answers:64623

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part9


Section 8.	("Supported" Hardware List)

8.0	What hardware works!

	The problem with this section of the FAQ is that software is 
	the only reason that every PC card on the planet does not work.

	EISA cards are not directly supported; when and if EISA
	is directly supported, they will give a significant performance
	advantage to EISA bus machines.  As it happens, user who desire 
	more than 16Meg of memory must use either VESA or EISA systems.
	Even with an EISA system, many users will not be able to use the
	address space above 16Meg unless their system uses only EISA 
	cards for those devices that need access to DMA.  The limitations
	are covered in another section of the FAQ.

	Many EISA cards operate in an ISA emulation mode.  Notably, the
	Ultrastore 24F SCSI controller operates in an IDE emulation mode 
	that allows the card to be used in the current system without 
	modification.  Most EISA cards that operate in ISA mode will 
	work with 386BSD, NetBSD, or FreeBSD.

	Like EISA, MCA is unsupported currently; unlike EISA, it can't
	work until it is supported, as it doesn't fall back to ISA
	operation.  If you want to work on this problem, I'm sure that
	many people will appreciate it; you will probably need an ISA or
	EISA machine to do the work, however.

	On top of all of that, NetBSD (being the 'horizontal' entry in
	the *BSD family) supports about 13 CPUs.


8.1	Video cards

8.2	Mice and Trackballs

	Mice are not supported, per se, in the Operating System.  They
	do make the GUI for 'X' a great deal less challenging.  The 
	following mice are supported in 'X' and are therefore supported
	by the free BSD systems:

		Microsoft mouse
		Mouse Systems mouse
		Logitech serial mouse
		PS/2 bus mouse requires a special driver that is included
		    in the current source trees.
		PS/2 compatible trackballs are also supported, but
		    there have been problems with the trackball causing
		    the keyboard to lock up.  See the psm driver
		    information for help on getting this driver to work
		    correctly with your system.


8.3	Serial Cards

	As a general rule, you should avoid a serial card that either 
	does not use a 16550 UART, or does not have a chip that you 
	can swap out to install one.  The 16550 will prevent many silo 
	overflows that can occur with high speed modems.  Other than 
	that, virtually all serial cards are supported.

	
8.3.1	How do I configure multiport cards?  Is there a possibility of 
	using multiport serial boards?  How do you configure an AST/4 
	in the kernel?  It looks like the AST driver only supports 
	4-port cards, but it looks like it would be easy to add support 
	for 8 ports ... or am I wrong?

	From: "Martin Husemann" <martin@euterpe.owl.de> 
	All AST 8 port Cards I have seen simply were two AST-4-port on 
	one board. You would configure them like this:

	 master	ast0	at isa? port 0x1a0 tty irq 5 vector astintr
	 master	ast1	at isa? port 0x2a0 tty irq 7 vector astintr

	With that said, the discussion about these cards continues with
	how to make older versions of *BSD react correctly to your AST
	4 or 8 port cards.

	The AST/4 and its clone multiport cards can run on 386BSD using 
	patchkit 0.2.4 and later, NetBSD, and FreeBSD.  The only
	problems seem to be that the code in older versions of
	sioprobe() and sioattach() in sio.c needs to be hacked to get
	it to properly detect the ports and then recognize the type 
	of UARTs installed (16550As).  The code segment that is causing 
	the problem is included below:

	The test in the sio.c driver (in the sioattach() routine) that 
	is causing it to *think* it is a 8250 is:


	
	scr = inb(iobase + com_scr);
	outb(iobase + com_scr, 0xa5);
	scr1 = inb(iobase + com_scr);
	outb(iobase + com_scr, 0x5a);
	scr2 = inb(iobase + com_scr);
	outb(iobase + com_scr, scr);
	if (scr1 != 0xa5 || scr2 != 0x5a)   <--- this is it!
		printf(" <8250>");


	This test seems to be depending upon the absence of the com_scr 
	register in the 8250 (iobase+7).  Unfortunately, the AST 4-port
	card uses this last register of the last UART for interrupt status
	(for the 4 UARTs), hence the last port of the 4 fails the test.  
	The easiest fix is to simply delete this test in your copy of 
	sio.c (If you *know* that you have no 8250s).

	The Bocaboard (BB1008) fails the same way on *all* 8 of its
	ports (the +7 address register is replicated for each port 
	according to the documentation).

	There are also some problems with another test in the if 
	statement:

	if (   inb(iobase + com_cfcr) != CFCR_8BITS
	    || inb(iobase + com_ier) != IER_ETXRDY
	    || inb(iobase + com_mcr) != MCR_IENABLE
	    || !isa_irq_pending(dev)              <--- this one fails!
	    || (inb(iobase + com_iir) & IIR_IMASK) != IIR_TXRDY
	    || isa_irq_pending(dev)
	    || (inb(iobase + com_iir) & IIR_IMASK) != IIR_NOPEND)
		result = 0;

	in the sioprobe() routine for a couple of the ports on the 
	4-port card.  Again, the fix is simply to remove that particular 
	test and everything seems to be okay.  These are admittedly
	pretty ugly hacks, but when you're in a pinch to the system back
	up...

	What you need in the config file is:

	sio0	-> COM1 
	sio1	-> COM2

	(both should be recognized and work just fine)

	sio2	@ 0x1a0	irq 9 flags 0x0501
	sio3	@ 0x1a8	irq 9 flags 0x0501
	sio4	@ 0x1b0 irq 9 flags 0x0501
	sio5	@ 0x1b8 irq 9 flags 0x0501

	Other folks have reported that their configuration looks very 
	similar to this, though they are using irq 5 for the 4-port card.

	(above paraphrased from Bob Willcox, et al)

	Another configuration for this is when two AST Four Port cards
	are actually used in a system.  The configuration for that looks
	like this:


	#device  sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
	#device  sio2    at isa? port "IO_COM3" tty irq 5 vector siointr

	device   sio1    at isa? port 0x2a0 tty flags 0x0481
	device   sio2    at isa? port 0x2a8 tty flags 0x0481
	device   sio3    at isa? port 0x2b0 tty flags 0x0481
	device   sio4    at isa? port 0x2b8 tty irq 5 flags 0x0481 
				vector siointr

	device   sio5    at isa? port 0x1a0 tty flags 0x0881
	device   sio6    at isa? port 0x1a8 tty flags 0x0881
	device   sio7    at isa? port 0x1b0 tty flags 0x0881
	device   sio8    at isa? port 0x1b8 tty irq 4 flags 0x0881 
				vector siointr



	This is one of the areas where FreeBSD and NetBSD have
	diverged.  The actual semantics of the multiport boards have
	changed since this section was originally written (the flags
	are either no longer needed or are different in current NetBSD
	implementations, for example).


8.3.2	Now that I have FreeBSD 1.0 installed, how do I set up the 
	serial ports for bi-directional use?

	Thanks to Lyn Kennedy (lrk@k5qwb.lonestar.org) for the advice about 
	the cua devices and their minor numbers.  He worked out much of this 
	without docs.

	In order to get the comm ports working, I decided to run the sio 
	driver (heard it is faster and more capable than com).  In order to 
	get it set up, this is what I did.

	1. I have four com ports assigned to the addresses and interrupt
	lines that are standard for DOS COM1, COM2, COM3, and COM4.  I
	have the following lines in the file used to specify the config
	for the kernel build:

	device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
	device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr
	device		sio2	at isa? port "IO_COM3" tty irq 5 vector siointr
	device		sio3	at isa? port "IO_COM4" tty irq 9 vector siointr

	I also enabled the use of com ports for either call in or call out
	by selecting the bi-directional option.  The following line in the
	config file causes the proper code to be compiled in the driver.

	options	   "COM_BIDIR"	#Bidirectional support in sys/isa/sio.c

	2. After building the kernel, I made sure the devices were 
	represented in /dev.  MAKEDEV should be used to create the
	tty0[0-3] special devices.  It will result in entries such as
	the following:

	   0 crw-------    1 root     wheel     28,   0 Nov  8 06:28 tty00
	   0 crw-------    1 root     wheel     28,   1 Nov  8 10:09 tty01
	   0 crw-------    1 root     wheel     28,   2 Nov  7 01:13 tty02
	   0 crw-------    1 root     wheel     28,   3 Nov  8 03:02 tty03

	Then mknod and chown should be used to create the following four 
	entries:

	   0 crw-rw-r--    1 uucp     dialer    28, 128 Nov  8 03:45 cua00
	   0 crw-rw-r--    1 uucp     dialer    28, 129 Nov  7 18:34 cua01
	   0 crw-rw-r--    1 uucp     dialer    28, 130 Nov  7 17:29 cua02
	   0 crw-rw-r--    1 uucp     dialer    28, 131 Nov  8 03:15 cua03

	The tty0[0-3] entries are used to receive calls on (with the 
	bidirectional code, this is signalled because the most significant 
	bit in the minor number is 0).  The cua0[0-3] entries represent the 
	same ports as the corresponding tty ports, but with the most 
	significant bit of the minor number turned on.  This indicates to 
	the driver that this port is a call out port.

	The reason for the ownership being set to uucp:dialer is because 
	I have all programs that use dialers (uucico, kermit, tip, etc.) 
	set to operate as set-uid with uucp as owner.  Also all of these 
	programs are set up as being in group dialer with group dialer 
	membership being required to execute them.

	3.  One further step needs to be done to allow proper use of the 
	ports.  In rc.local, the last few lines include the following:

	    comcontrol /dev/tty00 bidir
	    comcontrol /dev/tty01 bidir
	    comcontrol /dev/tty02 bidir
	    comcontrol /dev/tty03 bidir

	4. Now I set up getty to use the incoming ports with the following
	entries in /etc/ttys:

	    tty00	"/usr/libexec/getty std.19200"	unknown	on secure
	    tty01	"/usr/libexec/getty std.4800"	unknown	on secure
	    tty02	"/usr/libexec/getty std.4800"	unknown	on secure
	    tty03	"/usr/libexec/getty std.19200"	unknown	on secure

	5. I set up the port file for uucp, the remote file for tip, and 
	the .kermrc file for kermit to refer to the cua0[0-3] devices for 
	call out targets.

	6. Note that I have modems on cua/tty 00 and 03.  My modems are set 
	up to adjust the baud rate of the call (in or out) by negotiating 
	with the other modem in the call.  However the modems always retain 
	the same speed (19,200 Kb) for the rs-232 port.  In order to make 
	the modems use the proper speed, I have to send them an AT sequence 
	at the desired speed.  They will then retain that setting for 
	incoming calls.  So, to do this, I include the following at the 
	end of my rc.local script:

	    /usr/local/bin/initcua00 
	    /usr/local/bin/initcua03

	and in /usr/local/bin, I have the two scripts like (this is the one 
	for initcua00):

	#!/usr/local/bin/kermit
	set modem hayes
	set line /dev/cua00
	set speed 19200 dial XXXXXXX    <----------- it's own number to get busy
	quit


8.3.3	What is the difference between baud and bits per second?

	It's important to remember that we're transmitting symbols. Does
	this apply to digital transmissions ? Yes. A digital message is
	simply an ordered sequence of symbols from a discreet source. This
	source has an alphabet 'M' of 2 or more symbols, and produces
	the symbols at some rate 'r'.

	If we allocate a finite amount time alloted to a symbol, and call
	that time 'D', we can for once and ever define what baud is. Having
	'D', our "signalling rate" is:

	    r = 1/D                       (1)

	measured in _symbols_per_second_ or baud. For binary transmissions,
	we have a bit duration Tb, and our "bit rate" is:

	    rb = 1/Tb                     (2)

	measured in _bits_per_second_, (bps, or b/s).

	Now we note that in the special binary (M=2) case, each bit is
	a symbol and thus D=Tb, and by (1) and (2) we have:

	    r (baud) = rb (bps)           (3)

	or in English, for *binary* transmissions, we have "the signalling
	rate, measured in baud, is the same as the bit rate, which is
	measured in bps."  For all other transmissions, the signalling
	rate (baud) is not equal to the bit rate (bps).

	Regards,
	
	-Ade "never wants to see this again" Barkah


8.3.4	How do I get a serial console to work?

	This answer provided by Simon Ritter (sritter@novell.co.uk)

	I've seen a couple of posts requesting this info, so here it
	is. Maybe this should be added to the FAQ's.

	Edit the file /etc/conf/pack.d/sysmsg/space.c.  At the bottom 
	of this you will find the following lines:

	extern int kdputchar(), kdgetchar();
	extern int asyputchar(), asygetchar();
	extern int asyputchar2(), asygetchar2();

	struct conssw conssw =
	{
    	    kdputchar,
    	    0,
	    kdgetchar
	};

	Change all occurences of kdputchar and kdgetchar to asycputchar 
	and asycgetchar.  Rebuild your kernel and reboot, connecting a 
	terminal to the first serial port.  Behold, all messages on the 
	serial port.

	(Ed Note...  I don't even know if this exists in NetBSD or
	FreeBSD, but what the heck, it's an answer :-)...  Either way,
	the method for this is pretty much the same, and will require
	some mucking about on the kernel.)


8.4	Disk Controller Problems

	There is no real list of supported wd-driver controllers.  The listx
	would be far longer than I am willing to type.  Suffice it to say 
	that virtually every know IDE/ESDI/MFM/RLL hard drive controller
	available works.  There are occasional reports that the driver
	for this particular type of disk drive is "broken", but it is hard
	to substantiate this.  There are a few known "gotchas" with this
	particular controller type, but they are fixed as soon as they are 
	found.


8.4.1	IDE controller problems

	The code in the original 386BSD had some serious problems
	dealing with the wd controller.  In addition, changes to the
	controller code which have made improvements in other areas of
	the driver have made the wd driver (in 386BSD with the
	patchkit) even less trustworthy.  The wd driver in NetBSD 0.9
	is better but still has to deal with occasional hard drive bus
	hangs.  The wd driver in the -current code is much more
	reliable.  The FreeBSD code is also greatly improved, and
	likewise does not suffer from these bus hangs.

8.4.2	SCSI controller problems

	Every once on a great while, someone will post a problem with a
	SCSI controller.  Almost all of these are attributed to either
	a) bad cables (or out of spec cables), b) bad termination, or
	c) incorrect irq/drq setup.  Here is an excerpt of a message
	that provides some insight into one man's problems with the
	Adaptec controller, and one with the BusLogic 445.


	From: witr@rwwa.com (Robert Withrow)

	Problem: When the bus hangs, all devices have their access
	lights off, the AHA his its light on. 

	If anyone cares:

	Being in a hurry, I made several changes and the problem went
	away. Normally, I would change one thing at a time, but, like I
	said, I was in a hurry.  Below, I list the changes I made:

	  1) I replaced the AHA with an older one I keep as a spare.

	  2) I *inserted* the the ``synchronous negotiation'' jumper in 
	  the aha.

	  3) I removed the terminator power jumper from two of the hard
	  drives. 

	  4) I removed and reinserted all of connectors into all of the
	  drives. 

	If I had to guess, I bet #2 was the thing that fixed the
	problem. Perhaps this should be a FAQ answer? (Assuming this is 
	a requirement)...

	The system has compiled X11 three times as well as done all 
	sorts of other things including all of the drives (cdrom, disk, 
	and tape) for three days now without a single hang.

	 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430
 	 R.W. Withrow Associates, 319 Lynnway, Lynn MA 01901 USA
	 Net: witr@rwwa.COM

	wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen) writes:

	=>  =>  The BT kernel requires the controller to be configured 
	=>  =>  for IRQ 12.  That is a strange default.  The default for 
	=>  =>  the BT445S is 11, the same as for the 1542.  You probably 
	=>  =>  just need to reconfigure the controller.
	=>  
	=>  So I redid the switches and the BT kernel recognises it on 
	=>  int 12.  Either with or without EISA DMA (switch 2-10)
	=>  
	=>  it no longer generates the strayintr 7.
	=>  But it still doesn't boot after the message 
	=>  	'changing root device to fd0d'
	=>  
	=>  So what's going on here. Is there anyway to find out more?
	=>  Or should I go to one of the FreeBSD lists and discuss it there?

	I was browsing thru the hardware manual of the BT 445S and there 
	it was on the next page :-( I was just misguided by the nice 
	switches on the card edge. 

	To set the interrupts not only the dip-switches need to be changed.
	More important is the actual and physical connection of intr 12 to
	the ISA bus connector.

	After taking the board out, and really connecting intr 12, the 
	system booted the BT kernel without a glitch.  I'm now compiling a 
	new kernel with all our options set as we'd like them to be. 

	The current config:
		16 Mb
		BT 445S with intr 12 and switch 2-10 in default state, 
		giving dma on channel 5.

	Things I'm going to test:
		toggling the 2-10 switch
		adding 16 MB more.


8.5	SCSI Controllers

	The list of "supported" hard drive controllers is very short.
	Basically, it is any hard drive controller that emulates a
	standard IDE/ESDI/MFM controller and a few SCSI controllers.  
	The short list is included below:

	These boot with the kcaha floppy:
		Adaptec 1522		ISA	SCSI	Experimental
		AIC-6260 based		ISA	SCSI	
		AIC-6360 based		ISA	SCSI
		Adaptec 1540[ABC]	ISA	SCSI	No Floppy
		Adaptec 1542[ABC]	ISA	SCSI
		Adaptec 174x		EISA	SCSI
		Adaptec 294x		????	SCSI	Not supported
		Ultrastore 14F		ISA	SCSI
		Ultrastore 24F		EISA	SCSI
		Ultrastore 34F		VLB	SCSI
		Buslogic BT542		ISA	SCSI	
		Buslogic BT545		ISA	SCSI	(Old ones only)
		Buslogic BT946C		PCI	SCSI
		NCR 53C810 based	PCI	SCSI

	These boot with the kcbt floppy:
		Buslogic BT742A		EISA	SCSI
		Buslogic BT747A		EISA	SCSI	(modified 742 driver)
		Buslogic BT445S		VLB	SCSI

	Note that the Ultrastore 24F is supported with an experimental
	driver or in IDE emulation mode only.  Any controller that
	purports to be a clone of one of the cards listed above will
	usually work as well.

	The Adaptex 294x cards are a particular problem.  They are based
	on the AIC7770 chipset, for which there is an experimental
	driver.  In addition, several people have reported very limited
	success getting the Linux driver top work.  This is a continuing
	project that is being undertaken without the support of Adaptec.

	The '{something} based' cards above are special in that many 
	controllers use these controller chips as the basis for their 
	implementation.  The AIC-6260 is the chip set in the Adaptec 
	1522 series controllers, and the AIC-6360 is the chipset used 
	in the Soundblaster SCSI controller.  There are several PCI 
	controllers that are using the NCR chipset.

	In addition, there is a special note for Buslogic card users.

	The card should be configured to use ioaddr 0x330 and IRQ 12.
	There are two places the IRQ needs to be set.  The first is a
	bank of dip switches, and te next is a jumper.  See your hard
	drive controller documentation for the exact settings.

	Once you've got the controller on the right settings.  As it
	says in the README.INSTALL file, after all:

	BT742 SCSI Cntlr.       0x330   12               [kcopy-bt-floppy]

	So I can only conclude that you've probably not configured the
	card for EISA DMA!  From the /usr/src/KNOWNBUGS file:

	/sys/1/isa/bt742a.c
            The Bt445S and Bt747 controllers can cause problems when
	    ISA DMA is selected as an option.  With the EISA controller
	    the remedy is easy - simply turn it off using your EISA 
	    configuration utility.  With the Bt445S, which is a VLB
	    card, you must switch the undocumented "SW10" on "SB2" to
	    the off position.  Also note that certain revisions of the
	    Buslogic board (Revision C or earlier, firmware revision
	    <3.37) will cause DATA CORRUPTION with systems containing
	    more than 16MB of memory.  If you find this to be the case, 
	    temporarily remove your extra memory and contact Buslogic
	    for an upgrade!

	The BT946C PCI card works flawlessly.  The only thing that needs
	to be done to it is to ensure that the the two jumpers that
	control how and if to autoconfig are removed.  This allows the
	system to autoconfigure everything in the card.  The best thing
	to do is simply set the card to use the "Autoconfig to default"
	option.

		
8.6	Network Cards

	Common misconception number 1: Why does BSD still support such 
	a small selection of network cards?

	Depends on what you mean by `small'.  Here is the 'short list'.

	3c501                   isa     if_el           (kimmel@cs.umass.edu)
	3c503			isa	if_el		(mycroft) 
	3C507			isa	if_el		(mycroft) 
	3c509  			isa	if_ep   bnc/aui/utp.      (tdr)
	3c579			eisa	if_ep		  (tdr)
	WD 8390-based cards 	isa	if_ed		  (mycroft)
	SMC 8390-based cards 	isa	if_ed		  (mycroft)
	NE1000, NE2000    	isa	if_ed		  (mycroft)
	NE2100/BICC Isolan/DEPCA isa	if_le		  (mycroft)
	AT&T StarLAN (82586-based cards)		  (mycroft)

	These are all in NetBSD, and FreeBSD (by inference)

   	Common question number 2: I have a 3Com 3c509 - is it supported?

	The 3C509 works well under NetBSD-current, and has been clocked
	at full ethernet speed.  To use the UTP connection, you will need
	to specify the link0 and link1 options in the ifconfig command.

		-link0  disable AUI/UTP. enable BNC.
		link0   disable BNC. enable AUI.
		link1   if the card has a UTP connector, and link0 is
			set too, then you get the UTP port.


8.7	Printers
	
	In the original 386bsd system, there were problem with the
	interrupt driven parallel printer driver.  These problems were
	solved by the use of a work around called the interruptless
	printer driver (worked on the theory that once it knew how your
	printer reacted to printing it could configure itself to your
	printer).

	This code has also been deprecated through the use of a new
	printer driver in the {Free,Net}BSD systems that use the same
	source code for either 'interrupt' or 'polled' operation.  The
	closest thing to a 'common' question about printers involves
	questions about CR+LF emulation on some laser printers and some
	questions about some of the filters that 'lpd' talks about, but
	do not seem to be avaiable normally.

	The first is easy.  Set up your printer so that it uses the
	'LF' code as its CR+LF (End of line) character.  If you use
	your machine for operations in more than one OS (like some of
	us that HAVE to use DOS :-( ) then you can include a control
	sequence in the 'ff' control in your /etc/printcap file.

	Here is an example printcap to show you how simple it is:

	lp|ljgpc_deskjet|HP DeskJet Plus:\
		:lp=/dev/lpt0:mx#0:\
		:sd=/var/spool/ljgpc_deskjet:\
		:lf=/var/log/lpd-errs:\
		:ff=\033E\033&k2G:fo:sh:tr=\033E:


	For the HP LaserJet III (running PostScript) or the Deskjet 540 
	printers, the sequence is a little more involved:

	First, it looks like you will need to install ghostscript.  I have 
	a Desk Jet 540 that I use with the printcap entry and filter 
	included below.  You could hack the filter slightly to produce 
	output for your Laser Jet III (try changing "-sDEVICE=djet500" to 
	"-sDEVICE=ljet3").

	You'll need perl and gs installed on your system.  You also need to
	ensure that gs has the ljet3 driver installed.  You can find out by
	running "gs -h" and looking to see if the driver is listed.

	--- printcap entry ---
	lp|HP Deskjet 540:\
	    :lo=/var/spool/lpd/lp-lock:\
	    :lp=/dev/lpt0:\
	    :lf=/var/log/lpd-errs:\
	    :of=/var/spool/ps-filter:\
	    :sd=/var/spool/lpd:\
	    :sh:

	--- /var/spool/ps-filter ---
	#!/usr/bin/perl
	# Filter which detects postscript files and appends cr to lines of text.
	# $Id: ps-filter,v 1.3 1995/02/14 01:05:59 brian Exp $
	
	$cat="/bin/cat";
	$gs="/usr/local/bin/gs";
	
	$_ = <STDIN>;
	if (/^%!/)
	    {
    	    # Pipe the file as-is to the ghostscript interpreter.
    	    # Postscript files have their pages reversed because my
    	    # DeskJet 540 stacks them in reverse order if I don't.
    	    $old_dir=`pwd`;
    	    $tmp_dir = "/tmp/lp-gs.$$";
    	    mkdir($tmp_dir,0700);
    	    chdir $tmp_dir;
    	    open(PIPE, "|$gs -q -sDEVICE=djet500 -sOutputFile=%03d.lj -")
		|| die "$0: can't run ghostscript: $!";
    	    print PIPE $_;
    	    while (<STDIN>)
    	    {
		print PIPE $_;
    	    }
    	    close PIPE;
    	    @pages=reverse(sort(<*.lj>));
    	    system $cat, @pages;
    	    unlink @pages;
    	    chdir $old_dir;
    	    rmdir $tmp_dir;
	}
	elsif (&isprint() && !/\r\n$/)
	{
    	    # Send the text to the printer with trailing lf converted to crlf.
    	    s/([^\r])?\n$/\1\r\n/;
    	    print;
    	    while (<STDIN>)
    	    {
		s/([^\r])?\n$/\1\r\n/;
		print;
    	    }
	}
	else
	{
    	    print;
    	    while (<STDIN>)
    	    {
        	print;
    	    }
	}
	sub isprint
	{
    	    ($c) = split(//,$_);
    	    return ($c =~ /[\s\n]/) || (ord($c) >= 32 && ord($c) < 127);
	}

8.7.1	How can I print big files (especially from SAMBA, the WfWg
	network program)?

	First step:  Add ":mx#0:" to the printer's entry in /etc/printcap.

	Once you have "mx#0" in your /etc/printcap entry, make
	sure you have enough disk space in the "/var" filesystem to 
	handle the job.  Also beware that "lpr -s" can fail obscurely
	if the file you are printing (and the path to it) are not accessible
	by the user daemon.


8.8	Tape Drives.
8.8.1	What are the jumper configurations for the Exbyte 8200 DAT tape
	drive?

	Jumpers/switches are on the MX board. I think that the top of the 
	case and the board must be removed to access jumpers/switches.  
	Per a November 1989 8200 Spec there are at least two different MX 
	boards. Level 1, part no 724021-xxx has jumpers. Level 2, part no 
	724022-xxx has switches.

	Level 1 Jumper Configuration:

	J1 L-M Bypass Memory Test - 8 Second Startup
    	   M-R Run Memory Test - 65 Second Startup

	J2 L-M Parity Checking Enabled
   	   M-R Parity Checking Disabled

	J3 L-M Even Byte Disconnect
           M-R Odd or Even Byte Disconnect

	J4 L-M No Busy Enable
           M-R Report Busy Status

	J5 L-M P6 Cartridge Type - Domestic
    	   M-R P1 Cartridge Type - International

	J6 L-M Reserved for future use

	J7 L-M Normal Operations
   	   M-R No Disconnect in Data Phase

	J8 L-M Fixed Block Mode on Power Up
   	   M-R Variable Block Mode on Power Up

	Level 2 Switch Configuration:

	SW1 Off Run Memory Test - 65 Second Startup
    	    On Bypass Memory Test - 8 Second Startup

	SW2 Off Parity Checking Disabled
     	    On Parity Checking Enabled

	SW3 Off Odd or Even Byte Disconnect
    	    On Even Byte Disconnect

	SW4 Off Report Busy Status
    	    On No Busy Enable

	SW5 Off Fixed Block Mode on Power Up
    	    On  Variable Block Mode on Power Up

	SW6 Off Normal Operations
    	    On No Disconnect in Data Phase

	SW7 Off Reserved for Future Use
    	    On 

	SW8 Off P6 Cartridge Type - Domestic
    	    On P1 Cartridge Type - International


8.9	QIC-40/80 tape drives

	Steve Gerakines has released a series of patches for FreeBSD that
	allow the use of the QIC-40/80 tape drives through the floppy
	controller.  Get them from ftp.gte.com:/pub/ft/dist0.3/dist0.3.tgz
	or a similar mirror site, if there are any.  Archie will be able
	to tell you for certain.

	I have been playing with Steve's patches for FreeBSD to get
	them hooked into NetBSD for the past year.  The best I
	have ever been able to get is a kernel that doesn't recognize
	any of my floppy drives.


8.10	CD-ROMs

	The Sony Multispin drives work well for Charles Hannum using NetBSD
	and an SCSI controller.

	The Sony CDU 561 works well, as do the Toshiba 401 and 4101.  The
	4101 is a double speed SCSI-2 device and allows 'grabbing' of
	music tracks.

	Many folks have announced that they had problems with Mitsumi
	CD-ROM drives.  It seems that there are nearly as many releases
	of the firmware as there were drives sold.  Many of the firmware
	versions were incompatible with each other.  A generic Mitsumi
	driver will be a hard act to accomplish, if it is possible at all.

	There are native (non-EIDE) Mitsumi CD-ROM drivers for NetBSD and 
	FreeBSD.  They are available in the latest release version of each.
	If your CD-ROM is not recognized by the kernel, and uses a Mitsumi
	controller, you will need to make changes to the mcd.c source
	file to change the behaviour of the first getreply() function.
	Instead of exitting immediately, the check for whether the
	getreply was successful should be commented out and assumed to
	be correct.  While this is a brute force method (it may find a
	CD-ROM that isn't even there) it will help many Mitsumi
	controllers probe correctly.  The brute force method is
	included below:

	The answer is to replace the probe code which was broken with
	an old version.  The old version will detect mcd0 even if it
	isn't there :-) Doesn't matter!  Warren Toomey (wkt@cs.adfa.oz.au)

	int mcd_probe(struct isa_device *dev)
	{
        	int port = dev->id_iobase;      
        	int unit = dev->id_unit;
        	int st;
	
        	mcd_data[unit].flags = MCDPROBING;
	
	#ifdef NOTDEF
        	
        	mcd_data[unit].config = irqs[dev->id_irq] 
				       ;
	#else
        	mcd_data[unit].config = 0;
	#endif
	
        	
        	outb(port+mcd_reset, MCD_CMDRESET);
        	mcd_delay(300000);
	
        	
        	st = mcd_getstat(unit,1);
        	mcd_data[unit].flags = 0;
	
        	return (st<0) ? 0 : 4;
	}

	Note that this should not be a problem with either NetBSD 1.0 or
	FreeBSD 2.0, since both are using an even newer Mitsumi Driver
	for their interface.

	The EIDE ATAPI CD-ROM drive is now supported in the -current
	version of FreeBSD, and is supported experimentally in NetBSD.

	FreeBSD also supports the Masushita (Panasonic) CD-ROM drives.  

	The only other commonly available CD-ROM drive that is not
	supported is the SONY CD-ROM.  

8.10.1	How can I mount my CD-ROM so that it appears to be writable?

	There are two ways.  If the version of *BSD you have supports
	the union file system, you can use the following:

	    mount -t union -o -b /cdrom/ports /usr/ports
	    cd /usr/ports
	    make all install

	If your version of *BSD doesn't support union file systems, you
	could use something like this:

	    mount /dev/cd0a /cdrom
	    mkdir /usr/ports
	    cd /usr/ports
	    lndir /cdrom/ports .
	    <wait for dirs to link up>

	    cd /usr/ports/mail/elm
	    make all install

-- 
Dave Burgess  (The man of a thousand E-Mail addresses)
386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean that there isn't someone
that wants to do it...."