rmfowler@texrex.uucp (Rex Fowler) (03/17/91)
This article never showed up on my machine at work so I am reposting it.
Sorry if you already saw it.
-Rex
========================================================================
Article 706 of comp.sys.3b1:
Xref: texrex comp.sys.3b1:706 unix-pc.general:1510
Newsgroups: comp.sys.3b1,unix-pc.general
Path: texrex!rmfowler
>From: rmfowler@texrex.uucp (Rex Fowler)
Subject: 3b1 add-on boards
Message-ID: <1991Mar9.233823.29027@texrex.uucp>
Date: Sat, 9 Mar 91 23:38:23 GMT
Status: RO
Hardware hackers,
Why don't you have to set Interrupt Request vectors on boards
for the 3b1 like you do on boards added to PCs. Is this just
one of the pains in the PC architecture, or does the 3b1 know
how to avoid interrupt conflicts? I've been wondering if maybe
this has something to do with certain boards not working in some
3b1s but working ok in others.
Any thoughts?
--
Rex Fowler <rmfowler%texrex@cirr.com>
UUCP: egsner!texrex!rmfowlerbotton@i88.isc.com (Brian D. Botton) (03/19/91)
In article <1991Mar16.211250.7736@texrex.uucp> rmfowler%texrex@cirr.com writes: >This article never showed up on my machine at work so I am reposting it. >Sorry if you already saw it. > It showed up here, I just didn't have time to answer the first time. > >Hardware hackers, > >Why don't you have to set Interrupt Request vectors on boards >for the 3b1 like you do on boards added to PCs. Is this just >one of the pains in the PC architecture, or does the 3b1 know >how to avoid interrupt conflicts? I've been wondering if maybe >this has something to do with certain boards not working in some >3b1s but working ok in others. > >Any thoughts? If you happen to have a copy, get out your S4bus - AT&T UNIX PC Expansion Bus Specifications document. On page 34 they explain the interrupt protocol. Basically, of the 7 possible interrupt levels on a 680x0, level 1 and 5 are shared with all expansion cards, with level 5 being the highest. The philsophy of the 3B1 expansion bus is to never have to set jumpers, all boards are self configuring. This is what they (AT&T) does with their switching equipment. Because of this, each board has an ID, which the kernel reads and matches up with its device driver. In the land of crappy architectures, you know what I'm talking about, ;-), the boards are not autoconfigurable, so you have to set things like interrupt vector, I/O address, memory address, and DMA channel. All of these things are taken care of for you by the 3B1. Now, you could argue that you loose some flexibility because you are forced to live with some engineer's view of the system's resources. But if you compare the limits the 3B1 places on you vs. the PC, the 3B1 very similar limits. As for why some boards work and others don't, I'll have to pass on that one. -- ... ___ *** _][_n_n___i_i ________ ******* Brian D. Botton (____________I_I______I_I_______I laidbak!botton or /ooOOOO OOOOoo oo oooo oo oo laidbak!bilbo!brian
ahh@glyph.kingston.ny.us (Andy Heffernan) (03/26/91)
In article <1991Mar19.023406.20620@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes:
->>This article never showed up on my machine at work so I am reposting it.
->>Sorry if you already saw it.
[...]
->>Hardware hackers,
->>
->>Why don't you have to set Interrupt Request vectors on boards
->>for the 3b1 like you do on boards added to PCs. Is this just
[...]
-> Basically, of the 7 possible interrupt levels on a 680x0, level 1 and 5 are
->shared with all expansion cards, with level 5 being the highest. The philsophy
->of the 3B1 expansion bus is to never have to set jumpers, all boards are self
->configuring. This is what they (AT&T) does with their switching equipment.
More basically, isn't it true that things like interrupt request
vectors flying into the processor from interrupting devices is
an Intel-ism? Motorola-style memory-mapped I/O doesn't do that.
--
-------------------------------------------------------------------------
Andy Heffernan $BJ8;z(J uunet!glyph!ahh