Proper /IRQ handling for multiple devices
Proper /IRQ handling for multiple devices
I'm sure this has been mentioned before (I searched but didn't find anything conclusive), but I'm curious how to design multiple devices that each need to connect to the /IRQ line.
I've read the primer (http://wilsonminesco.com/6502primer/IRQconx.html) and it "sorta" makes sense with the open-drain vs. open-collector. But I was confused on the "C = Total /IRQ Capacitance" bit. Guess I got some more learning to do.
But what I'm trying to do is basically connect two 65C22's, one 65C51 (or maybe vintage NMOS version) and one TMS9918 for raster interrupt.
I haven't decided what /NMI will be used for yet but I'm 99.99% sure it will just be one device that would use it.
Any tips or places to read up on would be appreciated.
Thanks!
I've read the primer (http://wilsonminesco.com/6502primer/IRQconx.html) and it "sorta" makes sense with the open-drain vs. open-collector. But I was confused on the "C = Total /IRQ Capacitance" bit. Guess I got some more learning to do.
But what I'm trying to do is basically connect two 65C22's, one 65C51 (or maybe vintage NMOS version) and one TMS9918 for raster interrupt.
I haven't decided what /NMI will be used for yet but I'm 99.99% sure it will just be one device that would use it.
Any tips or places to read up on would be appreciated.
Thanks!
Cat; the other white meat.
Re: Proper /IRQ handling for multiple devices
The approach I used with SBC-4 was similar to the AVR microcontrollers. I integrated an interrupt status register and interrupt mask register into the board's CPLD. That way, each device IRQ was connected to the CPLD and the CPLD could mask or allow the IRQ to the processor. The processor could then read the status register to determine which device was signaling.
SBC-2 used diodes to allow multiple devices to "share" the IRQ input. The ISR had to poll each device to determine who caused the interrupt.
Daryl
SBC-2 used diodes to allow multiple devices to "share" the IRQ input. The ISR had to poll each device to determine who caused the interrupt.
Daryl
Please visit my website -> https://sbc.rictor.org/
- BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
I'm sure this has been mentioned before (I searched but didn't find anything conclusive), but I'm curious how to design multiple devices that each need to connect to the /IRQ line.
I'm not sure I understand your question. Garth's explanation of wired-OR on the IRQ line seems to be more than adequate—it's basically what I would write if it were me explaining it.
Are you thinking about priority encoding IRQs for faster servicing?
As for NMI, the only thing I use it for is a panic button circuit to regain control if a program I'm running accidentally puts the MPU into an unbreakable loop.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
it "sorta" makes sense with the open-drain vs. open-collector.
(Old TTL technology uses bipolar transistors, and one of the three terminals on a bipolar transistor is called the Collector. In our 65xx context we use Metal Oxide Semiconductors, and corresponding transistor terminal is called the Drain. But it has the same function.)
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: Proper /IRQ handling for multiple devices
Thanks everyone for the fast responses.
I know I don't always use the correct terminology (I'm a software guy).
That sounds like what I would need to do. I'm using your SBC-2 computer as inspiration for my next build. I don't want to use CPLD at the moment. So if I have two VIA's, and the first one causes the interrupt, how would I "ask it" if he was the one?
His explanation was sound. I'm just slow when it comes to this stuff. 
No, I basically just want to know how I can service whichever device caused the interrupt. Speed is not a huge issue at the moment.
The real unknown for me is going to be the TMS chip. I've never worked with it and interrupts before.
Thanks.
I know I don't always use the correct terminology (I'm a software guy).
8BIT wrote:
SBC-2 used diodes to allow multiple devices to "share" the IRQ input. The ISR had to poll each device to determine who caused the interrupt.
Daryl
Daryl
BigDumbDinosaur wrote:
I'm not sure I understand your question. Garth's explanation of wired-OR on the IRQ line seems to be more than adequate—it's basically what I would write if it were me explaining it.
Are you thinking about priority encoding IRQs for faster servicing?
Are you thinking about priority encoding IRQs for faster servicing?
No, I basically just want to know how I can service whichever device caused the interrupt. Speed is not a huge issue at the moment.
The real unknown for me is going to be the TMS chip. I've never worked with it and interrupts before.
Thanks.
Cat; the other white meat.
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
I'm sure this has been mentioned before (I searched but didn't find anything conclusive), but I'm curious how to design multiple devices that each need to connect to the /IRQ line.
I've read the primer (http://wilsonminesco.com/6502primer/IRQconx.html) and it "sorta" makes sense with the open-drain vs. open-collector. But I was confused on the "C = Total /IRQ Capacitance" bit. Guess I got some more learning to do.
But what I'm trying to do is basically connect two 65C22's, one 65C51 (or maybe vintage NMOS version) and one TMS9918 for raster interrupt.
I haven't decided what /NMI will be used for yet but I'm 99.99% sure it will just be one device that would use it.
Any tips or places to read up on would be appreciated.
Thanks!
I've read the primer (http://wilsonminesco.com/6502primer/IRQconx.html) and it "sorta" makes sense with the open-drain vs. open-collector. But I was confused on the "C = Total /IRQ Capacitance" bit. Guess I got some more learning to do.
But what I'm trying to do is basically connect two 65C22's, one 65C51 (or maybe vintage NMOS version) and one TMS9918 for raster interrupt.
I haven't decided what /NMI will be used for yet but I'm 99.99% sure it will just be one device that would use it.
Any tips or places to read up on would be appreciated.
Thanks!
(I have another reason for feeding them through the GAL, but that's not important here)
See page 31 of the WDC 65C22 data sheet.
-Gordon
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
I've read the primer (http://wilsonminesco.com/6502primer/IRQconx.html) and it "sorta" makes sense with the open-drain vs. open-collector. But I was confused on the "C = Total /IRQ Capacitance" bit.
The capacitance spoken of is the small amount that's in the circuit that you cannot get rid of. Every IC input, every socket, every trace that's anywhere near another conductor, etc. will have a few picofarad of capacitance, and it adds up. The rise time is produced by the resistor trying to charge up that capacitance.
A totem-pole output can bring it up much faster; but you don't want two or more totem-pole outputs connected together, since the current will be very high if one is trying to pull down while another is trying to pull the same line up. You won't damage anything if the situation is only microseconds long, but the sudden current spike might yank a chip's VDD and Vss internal voltages around enough to shift input thresholds enough to crash the system.
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
That sounds like what I would need to do. I'm using your SBC-2 computer as inspiration for my next build. I don't want to use CPLD at the moment. So if I have two VIA's, and the first one causes the interrupt, how would I "ask it" if he was the one?
If it's not set, then check the next device the same way.
Daryl
Please visit my website -> https://sbc.rictor.org/
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Proper /IRQ handling for multiple devices
There's also my 6502 interrupts primer which is more complete.
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: Proper /IRQ handling for multiple devices
drogon wrote:
One thing to note is that modern 65C22's (Specifically the more common W65C22S, but not the 'N' variant) are not designed to have their IRQ output be wire-or'd.
GARTHWILSON wrote:
I'm sure you mean open-drain versus totem-pole. As Jeff explained, open-drain and open-collector outputs do the same thing. They can only pull down; so if two or more outputs disagree, there's no contention. A totem-pole output OTOH can pull up as well as down. In the open-drain or open-collector situation, the only thing that can pull up is the pull-up resistor.
8BIT wrote:
You would read the IFR of each VIA and check bit 7 to see if it is set. If it is, then check the other bits to see what action caused the interrupt (Timer1, Timer2, CB1, CB2, Shift Register, CA1, or CA2).
If it's not set, then check the next device the same way.
If it's not set, then check the next device the same way.
So this brings up another question...what if literally all four devices threw an interrupt at the same time? I assume at this point, it's just a matter of designating a desired order. So, the video chip always comes first...VIA #1 comes second...etc.
GARTHWILSON wrote:
There's also my 6502 interrupts primer which is more complete.
Thanks to all of you. I couldn't build this without you!
Cat; the other white meat.
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
drogon wrote:
One thing to note is that modern 65C22's (Specifically the more common W65C22S, but not the 'N' variant) are not designed to have their IRQ output be wire-or'd.
Note that there are more differences than that. The N version cannot pull up as hard on its outputs as the S version can, and it does not have the bus-holding devices like the S version does. The bus-hold devices are good if there's a chance that for a significant time after power up nothing will drive the port inputs, meaning the line is basically floating.
Quote:
GARTHWILSON wrote:
I'm sure you mean open-drain versus totem-pole. As Jeff explained, open-drain and open-collector outputs do the same thing. They can only pull down; so if two or more outputs disagree, there's no contention. A totem-pole output OTOH can pull up as well as down. In the open-drain or open-collector situation, the only thing that can pull up is the pull-up resistor.
If you don't plan to run at the higher speeds, you can do that; but there is a good reason they went to the totem-pole IRQ\ output on the S version, it again being the time the IRQ\ line takes to float up with the N version and just a passive resistor. As I wrote in the articles on my website, I've been bit by it.
Quote:
I was thinking the wiring/hardware was somehow telling the CPU which device interrupted it. But the reality is you just simply ask everyone in the room. 
There's no sense in wasting time asking sources that are not enabled. If which sources are enabled keeps changing, it might require having your software partially write its own ISR (which doesn't have to be as complicated as it sounds). If a particular IC has no interrupts at all enabled, then don't bother asking it. If it only has one interrupt enabled, you don't have to ask it which one, since there's only one possibility. If there's more than one, you might first test for the higher-priority one, or maybe the one that's most likely to interrupt. (The interrupts primer goes through all these scenarios.)
All the interrupt-service routines (ISRs) I've seen in books are far lengthier than they need to be. I suppose much of that is that the authors just wanted to cover all their bases when they don't know the applications the reader will have. The Apple IIGS ISR is absolutely horrendous.
Quote:
So this brings up another question...what if literally all four devices threw an interrupt at the same time? I assume at this point, it's just a matter of designating a desired order. So, the video chip always comes first...VIA #1 comes second...etc.
Yes, again, probably order of priority. You may need to poll more than one bit before finishing up the service though, to avoid problems like I describe in Tip #14 in my "Tip of the Day" column.
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
- BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Proper /IRQ handling for multiple devices
cbmeeks wrote:
So this brings up another question...what if literally all four devices threw an interrupt at the same time? I assume at this point, it's just a matter of designating a desired order. So, the video chip always comes first...VIA #1 comes second...etc.
As Garth said, in such a case you poll the devices in the order of importance.
Keep in mind that the MPU's IRQB input is level-sensitive. This simply means an IRQ is assumed to have occurred if IRQB is low. Until all possible IRQ sources are cleared, IRQB will stay low. Hence if only one source is cleared and the interrupt handler returns control to the foreground another interrupt will immediately occur. Therefore, all programmed interrupt sources should be checked before the interrupt handler returns to the foreground.
On the other hand, NMIB is edge-sensitive. This means a transition from high to low triggers the interrupt. If NMIB remains low, no further interrupts will be recognized. This is why NMIB is normally tied only to one interrupt source.
Polling chip registers to find out who's interrupting can get slow if you have a lot of hardware. Obviously, and again as Garth noted, you should only check sources that have been programmed to interrupt.
If all possible interrupt sources have been enabled, polling can start to take a significant amount of time. In such a case, additional hardware that can indicate who's interrupting is useful. In my POC V1.2 unit, the virtual QUART can generate a total of 10 distinct interrupts, four receivers, four transmitters amd two timers. As the receivers and transmitters are where the bulk of the interrupts comes from, I have their individual IRQ outputs wired to a 74AC540 buffer whose outputs can be read. Set bits indicate an active IRQ. This makes it possible to identify only active interrupts without having to poll all possible sources.
Last edited by BigDumbDinosaur on Mon Feb 15, 2021 6:40 pm, edited 1 time in total.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Proper /IRQ handling for multiple devices
Polling chip registers for finding the /IRQ source might get slow when there are a lot of chips.
Some time ago we had a topic about vectored /IRQ interrupts,
but implementing something like this in a 6502 computer might require some hardware tinkering,
and I think maybe it's a bit too much for this project.
Some time ago we had a topic about vectored /IRQ interrupts,
but implementing something like this in a 6502 computer might require some hardware tinkering,
and I think maybe it's a bit too much for this project.
Re: Proper /IRQ handling for multiple devices
Mightn't be too hard to register a number of IRQ lines, in parallel with ANDing them, so the CPU gets a conventional IRQ and can then read an 8 bit register to see which one fired.
Although, the combination of tactics, whereby the most time-critical potential source is checked first, and where the ISR has knowledge of which IRQs are enabled, is probably enough for most cases.
Although, the combination of tactics, whereby the most time-critical potential source is checked first, and where the ISR has knowledge of which IRQs are enabled, is probably enough for most cases.
Re: Proper /IRQ handling for multiple devices
Thanks again everyone for the great information.
I'm re-reading the IRQ primer again. Also, I've found some designs online that I will study as well.
Once I get that all wrapped up, I may ask for constructive criticism later on.
I'm re-reading the IRQ primer again. Also, I've found some designs online that I will study as well.
Once I get that all wrapped up, I may ask for constructive criticism later on.
Cat; the other white meat.