Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!samsung!balrog!ctron.com
From: dj@ctron.com (DJ Delorie)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: IRQ 2 on AT-class machines
Message-ID: <1481@balrog.ctron.com>
Date: 10 May 91 14:13:51 GMT
References: <22603@yunexus.YorkU.CA> <13340001@hpsciz.sc.hp.com>
Sender: news@balrog.ctron.com
Reply-To: dj@ctron.com
Organization: None whatsoever
Lines: 22
Nntp-Posting-Host: bragi

In article <13340001@hpsciz.sc.hp.com>, bich@hpsciz.sc.hp.com (Bich Tran) writes:
> The second one is true: on AT class, IRQ2 is used to cascade the first
> interrupt controller to the second one, so AT can handle more thatn
> just 7 IRQs Since IRQ2 is re-mapped to IRQ9, software must redirect
> any IRQ2 request (XT card) to IRQ9.

Not quite true.  On an AT, vector 2 (IRQ2 on XT) is used to cascade
the slave interrupt controller (IRQ8-IRQ15).  To make the system
backward compatible, they did two things:

1. The IRQ2 line on the AT-bus is really connected to IRQ9 on the
controller chip (vector 1 on slave).

2. The BIOS redirects interrupts on int 71h (IRQ9) to int 0Ah (IRQ2),
after clearing the slave's status.

Thus, from an application program's point of view, nothing has
changed, not even the hardware.  They unmask IRQ2, service IRQ2
interrupts, and clear IRQ2 events.

DJ
dj@ctron.com