Page 1 of 4

Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 4:28 pm
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!

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 5:56 pm
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

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 6:09 pm
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.

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 6:46 pm
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.)

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 7:35 pm
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.

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 7:44 pm
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

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 7:49 pm
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.

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 8:54 pm
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

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 9:05 pm
by GARTHWILSON
There's also my 6502 interrupts primer which is more complete.

Re: Proper /IRQ handling for multiple devices

Posted: Fri Feb 12, 2021 10:43 pm
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!

Re: Proper /IRQ handling for multiple devices

Posted: Sat Feb 13, 2021 12:31 am
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.

Re: Proper /IRQ handling for multiple devices

Posted: Sat Feb 13, 2021 12:47 am
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.

Re: Proper /IRQ handling for multiple devices

Posted: Mon Feb 15, 2021 9:06 am
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.

Re: Proper /IRQ handling for multiple devices

Posted: Mon Feb 15, 2021 9:54 am
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.

Re: Proper /IRQ handling for multiple devices

Posted: Thu Feb 18, 2021 3:15 pm
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. :-)