Moving parallel ports to IRQ 11 and IRQ 12

Steven H. Izen izen at amelia.nas.nasa.gov
Thu Sep 7 14:55:49 AEST 1989


	Since a couple have people sent mail asking for details on how I got 
My parallel ports working on the upper interrupts, I thought I'd post the
details.

First, I recommend as a hardware reference (and a software reference for
(yuck)DOS) , "The Programmers PC Sourcebook" by Thom Hogan, MS press.

Anyway, from pages 508-9 of the above reference, I realized that to redirect
interrupt 5 to IRQ11, the trace leading to pin B23 on the io bus would have
to be directed to the connector going into D4 on the io bus.  Unfortunately,
my IO card was only an 8 bit card.  SO an EE friend of mine took a 16 bit
prototyping card, and fashioned from it an add on piece to my 8 bit card
which fit into the 
secondary 36 pin connector of the AT bus, on which D4 is located.  He also
did the (IMHO) delicate electrical remapping.  He seemed to think that it was
a fairly easy job, but not being a hardware hacker myself, I was impressed.

He also remapped the trace on my lpt1 card from 7 to 12.(pin B21 -> D5).
This was easier because lpt1 is on the floppy controller card, which
already was an AT card (16 bits), so it was just a question of rewiring.  Also,
My friend put jumpers on the cards, so that I could easily restore
the hardware to its normal state (in the event that I had problems getting unix
to find the new interrupts).  As a side note, I learned the hard way that this
trick will NOT work with async ports and ended up needing to restore the async
interrupts. (@#%!* ISC async drivers we all know and love :-().

So now the hardware config that I had was:
Lpt1 at addresses 3bc-3bf on interrupt 12
lpt2 at addresses 278-27f on interrupt 11

I set /etc/conf/sdevice.d/lp to look like:
lp      Y       1       3       1       12      3BC     3Bf     0       0
lp      Y       1       3       1       11      278     27f     0       0

and rebuilt the kernel.

I access lpt2 as /dev/lp2 (minor device 2)
and lpt1 as /dev/lp0 (minor device 0)

I think that if I'd set the addresses for the second port to 378-37f instead
of 278-27f then I'd address it as /dev/lp1, but I'm not sure as once I got the
above configuration to work I was reluctant to mess with it.

If something is screwed up, your stuff will still print but it will take *forever*
because the lp driver will time out.  If that happens check
your interrupts and sdevice.d/lp file.

I have used this setup successfully with the following hardware and interrupt
configuration on a compaq deskpro 386/20 running ISC 386/ix 2.0.1:

IRQ 2/9 vga retrace interrupt
IRQ 3&4 com2/com1 com2 on the jameco board (see below) and com1 on compaq's
	multipurpose floppy controller i/o board
IRQ 5 logitech hirez bus mouse
IRQ 6 floppy controller (compaq's own)
IRQ 7 Archive 60 meg tape drive.
IRQ 11 lpt1 (on compaq's floppy-i/o board)
IRQ 12 lpt2 on a Jameco I/O card (je1065)
IRQ 14 adaptec 2320 esdi disk controller.

SIDE EFFECTS:

I have seen no side effects affecting printing under native (real mode) DOS.
Apparently DOS printing is not interrupt driven, so the relocated interrupts
don't cause any problems.

The one side effect I have seen is that under realmode DOS, the logitech mouse
driver can't seem to find its interrupt!  I think the problem is that it finds
com1 and com2 , lpt1 and lpt2 i/o addresses taken and decides (without
actually checking) that therefore there is no place where its interrupt jumper
can be located, and exits.  However, under vpix it works fine!

Any more questions, send email to izen at cwru.cwru.edu or 
{uunet,sun}!cwjcc!skybridge!izen386!steve.


One question for any hardware developers reading this:  Why doesn't someone
sell a board with parallel ports which use the upper interrupts?  There has to
be a market for them since there aren't that many interrupts between 2 and 7.
Also, Why not do this with ethernet boards as well?
-- 
Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve
or steve%izen386.uucp at skybridge.scl.cwru.edu
or izen at cwru.cwru.edu		"My second bike is a car."



More information about the Comp.unix.i386 mailing list