Two things:

1. The Qlogic controller in question does exist; I have one, and I 
bet that WierdStuff is still selling them for $40/ea (they still had 
about a dozen when I was there a month ago). It has an ISP 1020 on 
it, Qlogic board assy PC2010404-01 rev D, copyright 1994. There are 
nothing but 50-pin SCSI connectors on it: one external, Sun-style, 
one internal IDC header. It probes on a 1.4ZD kernel as follows:

isp0 at pci0 dev 5 function 0
Qlogic ISP Driver, NetBSD (pci) Platform Version 0.997 Core Version 1.14
isp0: interrupting at eb164 irq 2
isp0: Board Revision 1020, loaded F/W Revision 4.65.0
isp0: Last F/W revision was 5.57.1
isp0: 243 max I/O commands supported
isp0: driver initiated bus reset of bus 0
scsibus0 at isp0: 16 targets, 8 luns per target

I'm using one in my Alpha PC164 to talk to three HP C3725S 2GB 
Fast/Narrow SCSI disks arranged in a ccd. Aside from making any 
single-port TULIP Ethernet board cough up blood (I've got a four-port 
21143/21152 board in there now; the second on-card PCI bus seems to 
make everything happy), the Qlogic controller works pretty well.

2. I made the change to isp.c during the period when you had "left 
the project" and I didn't expect that such a minimally invasive 
change was going to cause any problems. I preserved the functionality 
for anyone desiring to debug the controller interactions; I just made 
it not spew about SCSI ID's it was "skipping" (which means all IDs 
above 7 on this controller; it can't support ID's up there) for 
kernels not compiled with DEBUG or SCSIDEBUG, which is a problem for 
the controller I have. I'm slightly paranoid ("Can you prove that 
they're _not_ out to get me?") - I always use DIAGNOSTIC kernels.

I'm sorry if this change offended. Thank you for putting some of it back.

	Erik <fair@clock.org>