Uport tape driver ev.o disables line printer

L. Leslie Biffle les at anasaz.UUCP
Wed Feb 24 04:47:54 AEST 1988


In article <243 at oracle.UUCP> rbradbur at oracle.UUCP (Robert Bradbury) writes:
>
>
>...The point was made that the IBM Micro Channel was designed with a much
>different bus interface to get around this problem and allow exactly
>what Chris Lewis suggests (namely to be able to chain device interrupts
>at the same priority).
>
>I agree that there aren't very many interrupt lines on the PC, the
>question is can you daisy chain them or do you need to get a PS/2?
>

Yes, the int request lines can be daisy-chained, though it takes
thought on the part of the card designer.  Active-high vs. active-low
is not the issue here as much as the physical execution of the
hardware.  If the interrupt request line driver on an active-low bus
is not an "open collector" device, the same conflict would exist where
one device desires the signal to be high while another wants it to be
low.

Our intelligent data comm board uses a PNP transistor to drive the
selected interrupt request line high when an interrupt is desired.
When no board is driving the line high a simple resistor pulls the
line low.  This resistor is enabled on the last-or-only board (in the
spirit of the terminator on a disk drive).  In this way many of our 
boards may share the same interrupt vector, and may coexist with other 
boards that do the same.

In a similar light, our comm board's 4K-byte memory window (used for 
data and command transfers between the board and the PC's CPU) may be 
placed on any 4Kbyte boundary in the PC under PC software control.
This permits the device driver to slip it anywhere it will fit.
Many other boards with memory windows carve enourmous (64K or 128K)
chunks out of the PC's memory. This is unnecessary when most 
transfers are 512 bytes or less.  I'll admit it simplifies the coding,
but at the expense of configuration flexibility.  In most cases there
is no option as to the base address of this window, denying us the
ability to place it where it will not conflict with other memory
requirements.

The proliferation of new software packages and add-in hardware products
tells us that the PC is no longer simply a box to process our words
and spread our sheets.  When will the hardware design community stop
complicating our lives with these pointless limitations?

Les Biffle (WA5MAH)   UUCP:  hao!noao!mcdsun!nud!anasaz!les
                      TELCO: (602) 870-3330
		      USPS:  HC04 Box 10849
			     Cave Creek, AZ 85331



More information about the Comp.unix.microport mailing list