Proper /IRQ handling for multiple devices

For discussing the 65xx hardware itself or electronics projects.
User avatar
cbmeeks
Posts: 1254
Joined: 17 Aug 2005
Location: Soddy-Daisy, TN USA
Contact:

Proper /IRQ handling for multiple devices

Post by cbmeeks »

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!
Cat; the other white meat.
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Proper /IRQ handling for multiple devices

Post by 8BIT »

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
Please visit my website -> https://sbc.rictor.org/
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Proper /IRQ handling for multiple devices

Post by BigDumbDinosaur »

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!
User avatar
Dr Jefyll
Posts: 3526
Joined: 11 Dec 2009
Location: Ontario, Canada
Contact:

Re: Proper /IRQ handling for multiple devices

Post by Dr Jefyll »

cbmeeks wrote:
it "sorta" makes sense with the open-drain vs. open-collector.
Open-drain and open-collector are basically the same thing -- it's not a decision you need to make. Is that what's confusing the matter?

(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
User avatar
cbmeeks
Posts: 1254
Joined: 17 Aug 2005
Location: Soddy-Daisy, TN USA
Contact:

Re: Proper /IRQ handling for multiple devices

Post by cbmeeks »

Thanks everyone for the fast responses.

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
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?
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?
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.
Cat; the other white meat.
User avatar
drogon
Posts: 1671
Joined: 14 Feb 2018
Location: Scotland
Contact:

Re: Proper /IRQ handling for multiple devices

Post by drogon »

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!
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. so I had spare pins on the GAL I use on the Ruby boards to create a simple 3-input OR gate with the output going to the 65c02/816 /IRQ pin. software polls each device with the most important one (the 1000Hz ticker) being checked for first on each IRQ. A side effect is that there is no need for the pull-up resistor on the 65C02's /IRQ input pin.

(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/
User avatar
GARTHWILSON
Forum Moderator
Posts: 8775
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Proper /IRQ handling for multiple devices

Post by GARTHWILSON »

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.
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.

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?
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Proper /IRQ handling for multiple devices

Post by 8BIT »

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?
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.

Daryl
Please visit my website -> https://sbc.rictor.org/
User avatar
GARTHWILSON
Forum Moderator
Posts: 8775
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Proper /IRQ handling for multiple devices

Post by GARTHWILSON »

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?
User avatar
cbmeeks
Posts: 1254
Joined: 17 Aug 2005
Location: Soddy-Daisy, TN USA
Contact:

Re: Proper /IRQ handling for multiple devices

Post by cbmeeks »

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.
Ah, thanks for pointing that out. "S" is what I have in stock. So I will need to order some "N" versions to do an wire-or'd setup.
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.
Yeah, I meant totem-pole. So from what I am gathering, totem-pole is much faster but more complex. Especially with adding additional components (AND) and possible contention. I assume the smarter move for me (at least for now) is to stick with the wire-or'd setup?

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.
AH! OK, this was the obvious bit I was missing. 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. :-)

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.
Yep, I've been reading through that again. I've read it before but it's been a while.

Thanks to all of you. I couldn't build this without you!
Cat; the other white meat.
User avatar
GARTHWILSON
Forum Moderator
Posts: 8775
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Proper /IRQ handling for multiple devices

Post by GARTHWILSON »

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.
Ah, thanks for pointing that out.  "S" is what I have in stock.  So I will need to order some "N" versions to do an wire-or'd setup.

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.
Yeah, I meant totem-pole.  So from what I am gathering, totem-pole is much faster but more complex.  Especially with adding additional components (AND) and possible contention.  I assume the smarter move for me (at least for now) is to stick with the wire-or'd setup?

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?
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Proper /IRQ handling for multiple devices

Post by BigDumbDinosaur »

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!
User avatar
ttlworks
Posts: 1464
Joined: 09 Nov 2012
Contact:

Re: Proper /IRQ handling for multiple devices

Post by ttlworks »

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.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Proper /IRQ handling for multiple devices

Post by BigEd »

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.
User avatar
cbmeeks
Posts: 1254
Joined: 17 Aug 2005
Location: Soddy-Daisy, TN USA
Contact:

Re: Proper /IRQ handling for multiple devices

Post by cbmeeks »

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. :-)
Cat; the other white meat.
Post Reply