root@qetzal.UUCP (Admin) (02/08/88)
Has anybody else noticed that you cannot use the Microport Everex tape drive (ev.o) and a line printer at the same time? I would appreciate confirmation on this; right now I have an extra kernel I run when I have to do some printing. I am quite sure that I have set up the kernel configuration files correctly. Robert White boulder!qetzal!rcw
clewis@spectrix.UUCP (Chris R. Lewis) (02/13/88)
In article <1206@qetzal.UUCP> root@qetzal.UUCP (Admin) writes: >Has anybody else noticed that you cannot use the Microport >Everex tape drive (ev.o) and a line printer at the same time? >I would appreciate confirmation on this; right now I have >an extra kernel I run when I have to do some printing. > >I am quite sure that I have set up the kernel configuration >files correctly. Chances are that they're using the same interrupt vectors. On 386/ix last I saw the Bell Tech Wangtek tape driver uses the same interrupt as LP1. Try switching the printer over to the other LP. Alternately, try altering conf.c during build so that the interrupt vector points at a new routine that has: myvector() { evintr(); lpintr(); } By now ISC has probably enhanced config so that multiple drivers can use the same interrupts. They'd better have - there aren't very many interrupts on those machines. It's easy - after all, we do it on Spectrix machines :-) -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
les@anasaz.UUCP (L. Leslie Biffle) (02/24/88)
In article <243@oracle.UUCP> rbradbur@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
clewis@spectrix.UUCP (Chris R. Lewis) (03/01/88)
In article <661@anasaz.UUCP> les@anasaz.UUCP (L. Leslie Biffle) writes: |In article <243@oracle.UUCP> rbradbur@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. Exactly. Quite a few boards will actually work in such a scheme. IBM hardware treats the interrupt lines ALMOST like upside-down open collector gates - except that there aren't any pull-ups (actually downs) on the mother board. The few real IBM boards I've examined, along with the one I designed, don't use transistors. They use tristate buffers (eg: 74125) who's input is hardwired to ground (or high in an inverting buffer) and you enable the buffer to fire the interrupt. Further, you have to put a pulldown somewhere.... Our solution for multiple cards with the same interrupt was to put a resistor with the highest possible reliable value on each board as a pull-down. If you had only one board, the pull-down was enough. If you had three boards and three simultaneous interrupts, the value was 1/3rd but 74125's have far more than enough drive. We did it this way to eliminate another (error-prone) jumper. Potential problems: 1) you have to be interrupting on *level* not edge. (I know 386/ix uses level - as do most other UNIXes if they have a choice, don't know about messydos) 2) You may be sharing the interrupt with some board that doesn't drive the line properly. One of the nastier things that arise out of this STUPID design of IBM's is that since interrupt lines aren't pulled inactive, you can sometimes get continous interrupts on a line that isn't connected. What makes this worse is that 386/ix's config (uPort too I imagine) does not notice interrupt clashes, nor do they do the "right" thing and create a dummy ISR that calls all clashing *real* ISRs. Multibus I has very few interrupts (if you're using the vast majority of boards that can only autovector but not bus vector) and most systems on Multibus will create a dummy ISR (eg: Tower and Spectrix machines). I'm glad that no IBM'ers were around when I found out this stuff the hard way. GRRRRR!!!!! STUPID IDIOTS! Ruined a perfect first-run of the PC board.... -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955