Suppose for the sake of argument that I just so happen to be using a new kind of UART designed to run specifically with the 6502 and 65816 microprocessors. However, the designer of said UART decided to use a PH2-synchronized pulse for the interrupt instead of a constant level, usually cleared only after reading the interrupt pending register. Basically:



Now, if the 6502/65816 does NOT have interrupts masked, it will respond to this, since it samples the IRQ line on every falling edge of PH2.

But what happens if the 6502/65816 has interrupts masked? Will it remember that an interrupt has occured, and dispatch the interrupt handling routine once interrupts aren't masked anymore? Or will it just blithely ignore that an interrupt ever happened, and never realize that the UART needs some kind of servicing?

Knee-jerk analysis warning...

I'd assume that it would forget the interrupt--remembering it would require the implementation of a flip-flop in the 6502, and it seems like the 6502 is just as simple as it could possibly be. As you said, interrupt sources typically hold the line low until they've been serviced, so it'd be far easier for the 6502 to just keep running ISRs until the line went high again.

But I'd only give that answer 60% certainty; it'd be fun to find out which way it works, if someone can run a quick test.

I'm 99% certain that it would not 'remember' it. Because, as far as the 6502 knows, the IRQ line went back up because the device does not need to be serviced anymore.

The only thing that stops the 6502 from infinitely reentering the IRQ code while an IRQ is signaled, is that it automatically sets the interrupt mask bit when an IRQ occurs. That is the only way it has for knowing that an interrupt is being serviced. And since it can't differentiate between the bit being set because of an interrupt being serviced or being set with an sei opcode to ignore interrupts, it can't know if it's supposed to remember an interrupt signal. So it doesn't.

It'll do the blithely ignore thing.

Hi Everyone,

Level triggered IRQ's are better in general though. When people design a peripheral they want edge-triggered because it saves a flip-flop in their design. When people are designning a CPU, they want level triggered because it saves THEM a flip flop.

The IBM PC started with edge-triggered IRQ's (which was a shorted-sited idea) then switched to level-triggered when the PCI bus created. I'm not sure if micro-channel had level triggered IRQ's but it probably did.


Cheers,

Paul

Absolutely no argument here. I was just wondering because I'm working on my first bit of programmable logic design -- a simple UART written in Verilog. Of course, I have no way to realize the chip in hardware yet, but maybe someday...

I personally prefer the level-triggered interrupt for peripheral design because it's actually easier to generate. It's the logical OR or AND of a set of bits in an interrupt pending register. With an edge-triggered interrupt scheme, you still need that interrupt pending register *anyway*. Might as well go with a purely combinatorial solution to generating the final IRQ signal.



I find this to be untrue in my experience. I still need an interrupt pending register, so if I use an edge-triggered IRQ generator, I require even more logic.



If memory serves me correctly, MicroChannel was programmable in this respect.

Also remember that ISA bus was intended to have a unique interrupt line going to a programmable interrupt controller chip, which limited the number of slots to 8 or 15 (depending on the XT or AT motherboard standards). Of course, since some interrupts were used by on-board devices, this could never be realized. Nonetheless, the interrupt controller chip was responsible for generating the interrupt signal to the microprocessor (which I believe is level triggered), since it served as the system-wide "interrupt pending register", so to speak. It makes sense when viewed in that light.

That being said, thanks for the responses. It has cleared up some confusion, and I should be posting a preliminary data sheet shortly.

Hi kc5tja,

What is ironic is that the 8259 (int controller in original PC) was programmable and could be set to level or edge triggered interrupts!

The edge level interrupts really held the PC bus back in industrial-control
(until the compact PCI bus came along) because many cards had multiple interrupt sources. How nice it would have been to take a card with eight UARTS on it and let them share just one IRQ on the PC AT bus (sorry I started dreaming for a moment).
If you are looking for amusement, search on multiple edge-triggered interrupts for PC AT plug-in cards. There was an approach that was proposed by some card vendors that allowed two different cards to share a single edge-triggered interrupt. I am not sure if it became popular.

Cheers,

Paul

I would like to now repeat my question relating to the NMI and ABORT inputs to the 65816. The NMI behavior, I know, is the same as the 6502. So that question ought to be a bit easier to understand. But I'm thinking the ABORT pin must be pulsed. to prevent the ABORT handler from itself ABORTing.

Does the CPU maintain an internal "NMI Disable" flag that is cleared only when RTI is executed? Examining the schematics to the Commodore 128 seems to suggest that this is the case, as the output of one of the CIA's _IRQ signal ties directly to the CPU's NMI input. I know that the CIA's _IRQ output, like its VIA predecessor, remains low until the CPU reads from its interrupt pending register.

Thanks.

The book says the ABORT input should only be held low for one cycle, as to indicate there was bus contention in that cycle. It also says it initiates an interrupt sequence, which I'm sure means the interrupt-disable flag gets set. Once in the ABORT service routine though, the processor does not care how it got there, and NMI can interrupt it, as far as I can tell.

NMI is edge triggered and for a new interrupt to be recognised the NMI really needs to be high for just over 1 clock cycle. It can be less but this is the minimum needed to ensure that the interrupt is recognised.

I found this out the hard way when working on the Vic 20 ethernet network interface.

Lee.

Thanks for the responses. My own response to the above can be summarized as, "Oh great! Now I need to deal with level-triggered, edge-triggered, AND pulsed outputs." Oh well. I should have enough macrocells in the CPLD device I'm developing for to handle this.

Thanks!