In article <3AD3B5AE.8A7674AA@mail.csuchico.edu> you write:
>> It would be nice if the code was easily structurable in a way that non-
>> PC-lpt- parallel ports can be attached and get at least some of the
>> functionality (really alien ones, not the ports at some other address).
>
>umm... how alien?  As the code stands there is optional support within the
>probe function to find specific chips and such, however I'm not sure how much
>an "alien" port would need to bend the rules.

I expect about as alien as (say) different kinds of Ethernet cards are to
one another, or different kinds of serial port.  They'll probably support
the same basic set of operations, but have their own set of functions to
perform them.

>  Do you have some example
>hardware I could reference to keep things in mind?

While I haven't written the driver for it yet, I've got a card that uses
port A on a 6522 as a bi-directional printer port, with two of the
flow-control lines wired to CA1 and CA2, and the other control lines wired
to pins on port B[1].  I'd like to be able to support any future ppbus
interface on it.

[1] These details are from memory -- I've got the schematics at home if
    anyone cares.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>