3rd parallel port

3rd parallel port

Post by joe mc coo » Wed, 10 Jan 1996 04:00:00



SCO OES 3.2v4.2.  If I want to add a third parallel port, which IRQ
should I stipulate.  SCO defaults to 5, but that is already in use on my
system.

As far as I can see multi i/o cards only provide for IRQ's of 5 and 7 on
their parallel ports.

My hwconfig is as follows:

name=fpu vec=13 dma=- type=80387
name=serial base=0x3F8 offset=0x7 vec=4 dma=- unit=0 type=Standard nports=1
name=serial base=0x2F8 offset=0x7 vec=3 dma=- unit=1 type=Standard nports=1
name=floppy base=0x3F2 offset=0x5 vec=6 dma=2 unit=0 type=135ds18
name=floppy vec=- dma=- unit=1 type=96ds15
name=console vec=- dma=- unit=vga type=0 12 screens=68k
name=console vec=- dma=- unit=mono type=2
name=parallel base=0x378 offset=0x2 vec=7 dma=- unit=0
name=parallel base=0x278 offset=0x2 vec=5 dma=- unit=1
name=BusLogic base=0x330 offset=0x2 vec=11 dma=5 type=btk ha=0 id=7 fts=s ver=1.40
name=io8+ base=0x200 offset=0x3 vec=15 dma=- ver=2.00
name=tape vec=- dma=- type=S ha=0 id=2 lun=0 ht=btk
name=disk vec=- dma=- type=S ha=0 id=0 lun=0 ht=btk fts=sdn
name=Sdsk vec=- dma=- cyls=1006 hds=64 secs=32
name=disk vec=- dma=- type=S ha=0 id=4 lun=0 ht=btk fts=sdn
name=Sdsk vec=- dma=- cyls=631 hds=64 secs=32

Thanks

--
joe mc cool
                                   May your shadow stay long - Irish Maxim
========================================================================

Benburb                               compuserve: 100117,2613
N. Ireland                            voice     : (044) 861 548074
BT71 7LN                              fax       : (044) 861 549860
========================================================================

 
 
 

3rd parallel port

Post by Bela Lubki » Sat, 13 Jan 1996 04:00:00



> SCO OES 3.2v4.2.  If I want to add a third parallel port, which IRQ
> should I stipulate.  SCO defaults to 5, but that is already in use on my
> system.

> As far as I can see multi i/o cards only provide for IRQ's of 5 and 7 on
> their parallel ports.

PC parallel ports only support IRQs 5 and 7.  (You might find a board
that violates this rule *somewhere*, but I've never seen one).  So the
only thing you can do is to double up on one of the IRQs.  Try it on 5,
try it on 7, see which works better.  Make sure the card is actually
jumpered to match the driver config.  In general, what seems to happen
is: as long as only one printer is active at once using a particular
IRQ, everything is smooth.  With both active, it *might* be smooth,
depending on the parallel port hardware and the printers.  If not, one
or both of the printers may run astonishingly slowly while the other one
is printing.  Also make sure you have installed uod391a, the updated
parallel drivers for 3.2v4.2.

There do exist intelligent (and expensive) parallel port options.  The
only one I know of offhand is one of the add-on modules for the Digi C/x
line.

Quote:>Bela<


 
 
 

3rd parallel port

Post by Robert Li » Mon, 15 Jan 1996 04:00:00




>> SCO OES 3.2v4.2.  If I want to add a third parallel port, which IRQ
>> should I stipulate.  SCO defaults to 5, but that is already in use on my
>> system.

>> As far as I can see multi i/o cards only provide for IRQ's of 5 and 7 on
>> their parallel ports.
>PC parallel ports only support IRQs 5 and 7.  (You might find a board
>that violates this rule *somewhere*, but I've never seen one).  So the
>only thing you can do is to double up on one of the IRQs.  Try it on 5,
>try it on 7, see which works better.  Make sure the card is actually

When paintr() gets called in the kernel will it really go roam over all
the ports to see which of th einstalled cards has posted the interrupt?

Quote:>jumpered to match the driver config.  In general, what seems to happen
>is: as long as only one printer is active at once using a particular
>IRQ, everything is smooth.  With both active, it *might* be smooth,

Actually, It depends on who has the bigger pull ups on the IRQ line
compared to who has the strongest drivers.  ISA doesn't do shared
interrupts.  This means each card can either drive the line high or
drive it low.   If I'm a burly card with giant manly drivers and you're
a girly card with little wimpy drivers, you probably can't drive in int
line [ or anything else ] high when I'm sitting idle and driving it low
So even though you're trying to post the interrupt, all you're doing is
making heat in my drivers and your drivers.  This is why you don't want
outputs connected together.

I could bore you with slightly more accurate explanations of the
electronics here, but this suffices for the average system admin.

So how do shared interrupts work on, say, EISA or MCA?  Glad you asked.
There are three states an ouput can be in [ hence the name "tristate" ]

        You can drive high.
        You can drive low.
        You can not drive at all - effectively being an input.

This allows others to drive the bus when you don't want to.

Quote:>There do exist intelligent (and expensive) parallel port options.  The
>only one I know of offhand is one of the add-on modules for the Digi C/x
>line.

I think it's called something like the X/emp series.  It's a module
that can either be attached to the X/em family of host adapters or
set on top of the EPC concentrators.  The EPC is like a C/X on steroids.  

You're correct - it's not inexpensive, but it will rock-and-roll your
data out [ and IN! ] a parallel port without destroying your host
performance.  If you need a high speed parallel *input* port for
some wierd app, this is a neat solution, too.

Since it's all I can do to keep up with what awful letters marketing sticks
on the products before they go out the door, I certainly can't scoff
at Bela for getting that close to the answer! :-)   Thanx for the plug.


612-943-9020 should be able to help you out.

--
Robert Lipe

 
 
 

3rd parallel port

Post by Sean Embr » Tue, 16 Jan 1996 04:00:00



Quote:>SCO OES 3.2v4.2.  If I want to add a third parallel port, which IRQ
>should I stipulate.  SCO defaults to 5, but that is already in use on my
>system.

>As far as I can see multi i/o cards only provide for IRQ's of 5 and 7 on
>their parallel ports.

    Easy corp (formally Black Box) sells parrallel ports that you can
select the IRQ from 3 to 15. I do not know if the kernel supports this. I
am using them in a application to poll for data from meters, but its DOS
based and I'm playing heck, west and crooked with it.

   Bella should be able to tell you if you can change what IRQ the kernel
looks at.

---
Sean "I will always engage brain before Posting" Embry.

 
 
 

3rd parallel port

Post by Bela Lubki » Tue, 16 Jan 1996 04:00:00



> > > When paintr() gets called in the kernel will it really go roam over all
> > > the ports to see which of th einstalled cards has posted the interrupt?

> > Yes, it will.  It looks through the list of all configured parallel
> > ports; for each that is configured, if it's configured for the IRQ we've
> > just fielded, further checking is done to see if the port needs to be
> > serviced.  

> Does this imply that you can run three parallel printers over IRQ 7,
> decent hardware assumed? Does this checking bypass all PCI/EISA
> configuration? (It's impossible to assign IRQ 7 three times with most (all?)
> EISA/PCI configuration utilities, so you have to add two of the parallel
> ports without EISA/PCI knowing they use IRQ 7.)

Yes, but...

For it to work well, you'd need three parallel ports all of which knew
to tristate their IRQ outputs when not in use.  Otherwise, as Robert
Lipe explained, probably only one of the three would be able to get its
interrupts through.  The three line drivers might even fight badly
enough to damage the hardware.  I've seen two on the same IRQ work
(where "work" doesn't mean "work perfectly" -- you'll probably have at
least one Slow Printer).  Three on the same IRQ greatly enhances the
probability of various bad things happening.

Someone better qualified at electrical stuff needs to chime in here
(Robert?  Jeff?)  The question: assuming they do fight, how likely are
they do damage themselves?  More importantly, is there any chance of
other parts (the bus, etc.) being damaged?  Parallel cards are cheap
enough I could imagine sacrificing a few as experimental subjects.  I
wouldn't want to toast a motherboard...

A real hardware hacker would modify his parallel cards to tristate the
IRQ output -- should be pretty easy.  Me, I have enough trouble with
plain old unmodified hardware...

Quote:>Bela<

 
 
 

3rd parallel port

Post by Craig Macbri » Tue, 16 Jan 1996 04:00:00



Quote:>SCO OES 3.2v4.2.  If I want to add a third parallel port, which IRQ
>should I stipulate.  SCO defaults to 5, but that is already in use on my
>system.
>As far as I can see multi i/o cards only provide for IRQ's of 5 and 7 on
>their parallel ports.

I know they're rare, but the simplest answer is to find an older IO
card that can handle other IRQs. I've seen several that do it. The
old Everex PCs used to have onboard parallel ports that could be
jumpered to IRQ 5,7 or 9. (Not that this helps in this case.)

If you want to be really brutal, find an IO card with all the slot
connectors present and do a bit of track breaking and soldering to
shift it from using IRQ 7/5 to using something more convenient.

--


\_.--.*/        "Computers in the future may weigh no more than 1.5 tons."
      v                 ... Popular Mechanics, 1949

 
 
 

3rd parallel port

Post by Bela Lubki » Tue, 16 Jan 1996 04:00:00



> >PC parallel ports only support IRQs 5 and 7.  (You might find a board
> >that violates this rule *somewhere*, but I've never seen one).  So the
> >only thing you can do is to double up on one of the IRQs.  Try it on 5,
> >try it on 7, see which works better.  Make sure the card is actually

> When paintr() gets called in the kernel will it really go roam over all
> the ports to see which of th einstalled cards has posted the interrupt?

Yes, it will.  It looks through the list of all configured parallel
ports; for each that is configured, if it's configured for the IRQ we've
just fielded, further checking is done to see if the port needs to be
serviced.  Which reminds me of another common misbehavior of multiple
parallel ports on the same IRQ: sometimes what happens is that printer A
prints slowly *unless* printer B is active at the same time.  Printer
A's interrupts are suppressed by B's stronger driver circuits.  Only if
B is actively generating interrupts does A get looked at often enough to
perform decently...
Quote:>Bela<

 
 
 

3rd parallel port

Post by Kees Hendrik » Tue, 16 Jan 1996 04:00:00




> > When paintr() gets called in the kernel will it really go roam over all
> > the ports to see which of th einstalled cards has posted the interrupt?

> Yes, it will.  It looks through the list of all configured parallel
> ports; for each that is configured, if it's configured for the IRQ we've
> just fielded, further checking is done to see if the port needs to be
> serviced.  

Does this imply that you can run three parallel printers over IRQ 7,
decent hardware assumed? Does this checking bypass all PCI/EISA
configuration? (It's impossible to assign IRQ 7 three times with most (all?)
EISA/PCI configuration utilities, so you have to add two of the parallel
ports without EISA/PCI knowing they use IRQ 7.)

--

                                             |
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax:   +31 (0)53 43 37 415

 
 
 

3rd parallel port

Post by Bela Lubki » Tue, 16 Jan 1996 04:00:00



>     Easy corp (formally Black Box) sells parrallel ports that you can
> select the IRQ from 3 to 15. I do not know if the kernel supports this. I
> am using them in a application to poll for data from meters, but its DOS
> based and I'm playing heck, west and crooked with it.

The `mkdev parallel` script only accepts interrupts between 1 and 9.
This is easily remedied (search for "[1-9]", replace with
"[1-9]|1[0-5]").  I've never tried anything but 5 or 7, but I just
checked the driver source: I can see nothing that would prevent other
IRQs from working, as long as nothing else was on that IRQ.  (That means
you can't use 0, 1, 2, 6 (usually), 8, 13 (usually))...
Quote:>Bela<

 
 
 

3rd parallel port

Post by Robert Lip » Wed, 17 Jan 1996 04:00:00


Quote:> Does this imply that you can run three parallel printers over IRQ 7,
> decent hardware assumed? Does this checking bypass all PCI/EISA

I wouldn't think so at all on an ISA card.  IF you have a PCI/EISA/MCA
parallel port, the odds are better, but I can't imagine that many of
those even exist.

Quote:> For it to work well, you'd need three parallel ports all of which knew
> to tristate their IRQ outputs when not in use.  Otherwise, as Robert
> Lipe explained, probably only one of the three would be able to get its
> interrupts through.  The three line drivers might even fight badly

Hmmm.  Let me try another analogy.  For this to work, you have to know
that on tandem bikes the front and rear cranksets [ the things the
pedals are attached to ] always turn at the same rate becuase the
synchronizer chain (the one on the left) holds them locked together.  
Actually, it probably works better if you imagine clipless pedals
[ where your shoe is locked to the pedal ].  It works better yet
if the bikers in my little fairy tale only have one foot, but
let's not get crazy. :-)

Quote:> enough to damage the hardware.  I've seen two on the same IRQ work
> (where "work" doesn't mean "work perfectly" -- you'll probably have at
> least one Slow Printer).  Three on the same IRQ greatly enhances the
> probability of various bad things happening.

Imagine ISA interrupts being like bike pedals.   Each can be either up
or down [ active or inactive ].  Like the rear cassette on your bike,
the ISA bus doesn't really care if it's up or down, only that it moved on
it's way to being up or down.  [ Think about pedaling vs. coasting vs. just
jiggling the pedals around ] This is what "edge triggering" is all about.  
The bus senses an interrupt "happening" when it changes from active to
inactive (a turn of the pedal), not the level of it being active or
inactive.

Now, let's imagine a tandem bike being ridden by two people that aren't
communicating .  Each biker is a card.  If each biker only has two
states for their pedals (push up/push down, active/inactive) it's very
hard for the other one to change the other's state.  If you have a
stronger biker in one position, the other may not be able to change it
at all.  If you have evenly matched/weighted bikers, you can each probably
change it, but you're going to bonk the other person's knees.  

Twentieth century [ everything except ISA ] machines allow the bikers
to relax.  They can "tristate" their legs.  In this state, they're
neither pushing up nor down, but are just going with the flow.  These
computers sense that the interrupt line is active, then roam around
all the cards whacking them until it goes away.  After all the cards
have been satisified, the interrupt request goes away.

You earlier mentioned one of the printers being dog slow while the
other was printing.  The dog slow one isn't getting the interrupts
through, becuase it's "pedals" are being bullied by the other.  The
pa driver, as I recall, knows that most PC parallel ports are garbage
and if it doesn't get an interrupt in some * amount of time (a
second?) assumes it's been lost and sticks out the next byte.

The interaction here depends on whether the "bully" can push down
harder than he can pull up.  You can get silly with my example and
put a fat person with an untied shoe, for example...  So depending on
whether he was on an up or a down stroke, the other one may be able
to change it.

Quote:> Someone better qualified at electrical stuff needs to chime in here
> (Robert?  Jeff?)  The question: assuming they do fight, how likely are
> they do damage themselves?  More importantly, is there any chance of

I don't recall there being a current limit specified in the AT specs
for max current sink, but it's been a long time since I looked and, being
a software guy, probably wouldn't remember it anyway.

On paper, every vendor is going to tell you "don't do that".   In
reality, have I ever seen it make a fatal difference?  Only once or
twice.

Most of the time, you just generate a little extra heat, but since
heat is probably the #1 enemy of silicon, you should probablyh not
do this long term.

Quote:> other parts (the bus, etc.) being damaged?  Parallel cards are cheap
> enough I could imagine sacrificing a few as experimental subjects.  I
> wouldn't want to toast a motherboard...

No promises from me either. :-)

Quote:> A real hardware hacker would modify his parallel cards to tristate the
> IRQ output -- should be pretty easy.  Me, I have enough trouble with
> plain old unmodified hardware...

The problem is that you may have to teach the board how to relax it's
knees.  I know some hardware [ at least two of our designs ] the
embedded software has to go whack a latch to make this happen.  On
something  like an IRQ line where you probably don't have to really
drive a line inactive, but could let it float inactive with the help
of some pulldowns, you might get away with it.  But how that you're
talking about sticking three of those pullups in parallel on the same
line, you're surely back in the same tar pit.

The m*of this story is:  Shared interrupts on ISA don't work.  
You can*around with it and find combinations that might flail
around, but it's not an exercise for the faint at heart, and not likely
to be something that'll work with reproducable consistency.

The other m*of this story is to not let overstressed computer
geeks try to explain things in non-computer terms. :-)

 
 
 

3rd parallel port

Post by david.. » Tue, 23 Jan 1996 04:00:00




|     Easy corp (formally Black Box) sells parrallel ports that you can
| select the IRQ from 3 to 15. I do not know if the kernel supports this. I
| am using them in a application to poll for data from meters, but its DOS
| based and I'm playing heck, west and crooked with it.

What I would *really* like a a parallel port with buffering, like the
16550 UART. That is, a port which could function as if it were an
external "printer buffer," but in both directions, since parallel ports,
particularly the new 8 bits guys, can be used for many things other than
talking to printers.

Talking to fast modem, as a for instance, a little light environment
monitoring... more than "paper out" stuff.
--
Stupidity, like virtue, is its own reward.

TMR does UNIX and other systems stuff, some real time, network and
system admin, security, C and other good stuff.

 
 
 

3rd parallel port

Post by Robert Li » Wed, 24 Jan 1996 04:00:00



>What I would *really* like a a parallel port with buffering, like the
>16550 UART. That is, a port which could function as if it were an
>external "printer buffer," but in both directions, since parallel ports,
>particularly the new 8 bits guys, can be used for many things other than
>talking to printers.

The Digi International PC/Xemp8 supports up to 32K each of input and
output buffering, depending on the configuration of RAM on the card
and the number of ports.  It looks to the Digi drivers much like one
of the X/em serial ports.  To the user, it acts like a tty when driving
a printer.  For unidirectional use, it acts like a tty.

Quote:>Talking to fast modem, as a for instance, a little light environment
>monitoring... more than "paper out" stuff.

We have folks using them for process control stuff.  Sure beats
bit-banging it yourself.  

One gotcha with making it talk to a modem is that it really doesn't act
very much like a tty when you're trying to get "full duplex" from it.
You have to issue an ioctl to flip the direction.  The other is that
the makers of the parallel modems seem to be unwilling to part with
the interface specs on it...

We've done one end.  The other is left as an exercise for the reader. :-)

--
Robert Lipe