65C816 Interrupt Processing Technical Article

[BigDumbDinosaur]

Investigating 65C816 Interrupts.  Also linked at Garth Wilson's website on his Links page.

[scotws]

Wow. I guess that's my evening's reading. Thanks for all the work!

[BigDumbDinosaur]

scotws wrote:

Wow. I guess that's my evening's reading. Thanks for all the work!

You're welcome.

[scotws]

Quote:

The abort interrupt is used in systems that have specialized memory management logic to cope with unusual hardware conditions that may arise during program execution.

At the risk of exposing even more of my happy ignorance in these matters -- I had always assumed, though without thinking about, that ABORT would be used in a multitasking context, not so much for memory management: A clock signal asserts ABT in regular intervals, and the CPU tears the process away from what it is doing with a cry of (insert Soup Nazi accent) "No cycles for you!"

Given the high priority of ABORT (just below RESET, but above IRQ), would this still be possibility? I know the 65816 is not really made for serious multitasking -- no protected mode, for one -- but whereas memory stuff would need a MMU ("the required hardware logic" as I understand from the text), what else would you need for preemptive multitasking, however primitive?

Thanks again for the text, I learned a lot. The second computer will definitely be a '816.

[barrym95838]

Thanks for a nice write-up BDD!

I stumbled across a small typo ... do a search for "already be discussed" and you'll find it.

Since you are a hardware and software guy with a lot of experience, can you provide me with any insight with regards to the edge-sensitive behavior of NMI? Why isn't it just like IRQB? It seems to me that it would be potentially more useful that way, but there could be a good reason that it is not, that I simply don't understand.

Mike

[Edit: Upon further thought, I guess that the hardware triggering the NMI would have to be designed in such a manner as to be able to de-assert itself, since the software wouldn't be able to do so, or make any headway otherwise. In that light, it would be more related to RESETB than IRQB, but could still have some interesting synchronization uses.]

[PaulF]

NMI is edge-triggered for a simple reason. If it were level-triggered, the NMI interrupt would immediately re-interrupt its own service routine after the service routine had executed its first instruction. This process would continue over and over again, locking the machine into an endless loop as the service routine would not be processed to the point where it could disable the interrupt source!

[ElEctric_EyE]

In hardware (verilog), edge-trigger makes a FF, like a 74374. A level-trigger makes a latch like a 74373.
I remember on the C-64, the certain combination keypress would trigger an NMI 'master' interrupt. IRQ's were a lesser priority.

[barrym95838]

PaulF wrote:

... process would continue over and over again, locking the machine into an endless loop as the service routine would not be processed to the point where it could disable the interrupt source!

... hence my edit admitting/implying that extra hardware handshaking would be necessary. Thinking about it further, I suppose that the three original 6502 vector-invoking inputs all had different protocols to provide the best mix of options for the hardware of the time, and my initial post here is starting to look a bit silly.

Mike

[BigDumbDinosaur]

PaulF wrote:

NMI is edge-triggered for a simple reason. If it were level-triggered, the NMI interrupt would immediately re-interrupt its own service routine after the service routine had executed its first instruction. This process would continue over and over again, locking the machine into an endless loop as the service routine would not be processed to the point where it could disable the interrupt source!

Paul saved me the trouble of explaining.

My earliest recollection of the use of NMI was on an ancient BASIC Four mini from the early 1970s, which received its power from a humongous UPS. When the power failed the UPS had a set of contacts that would close and pull an input on the mini to ground if power remained off for more than 10 minutes. That turned out to be an NMI that directed the computer to shut itself down. Obviously, as Paul described, if the NMI had been level-sensitive the interrupt would have kept interrupting and the shutdown would not have happened.

[BigDumbDinosaur]

barrym95838 wrote:

Thanks for a nice write-up BDD!

You're welcome.

Quote:

I stumbled across a small typo ... do a search for "already be discussed" and you'll find it.

Fixed. Why is it the computer won't type what I'm thinking when I'm writing this stuff?

Quote:

Since you are a hardware and software guy with a lot of experience, can you provide me with any insight with regards to the edge-sensitive behavior of NMI? Why isn't it just like IRQB? It seems to me that it would be potentially more useful that way, but there could be a good reason that it is not, that I simply don't understand.

Paul explained.

[nyef]

BigDumbDinosaur wrote:

Why is it the computer won't type what I'm thinking when I'm writing this stuff? :evil:

Because automatic spelling correction is more than aggravating enough to a fast typist who learned to type without it (or possibly even with it). Automatic grammar correction would just lead to utter gibberish when faced with someone who types three or four words before they realize that they messed up, sometimes completing a sentence that then gets auto-corrected, yet still knowing exactly how many times to hit backspace to return to where they made the mistake so that they can correct it, only making the problem worse because not only has the computer changed what was typed, but it changed it to make even less sense. The better approach would be to somehow highlight sentences (or parts thereof) that the computer thinks are somehow wrong.

Oh, wait, was that meant to be rhetorical? My bad. :oops:

[BigDumbDinosaur]

scotws wrote:

Quote:

The abort interrupt is used in systems that have specialized memory management logic to cope with unusual hardware conditions that may arise during program execution.

At the risk of exposing even more of my happy ignorance in these matters -- I had always assumed, though without thinking about, that ABORT would be used in a multitasking context, not so much for memory management: A clock signal asserts ABT in regular intervals, and the CPU tears the process away from what it is doing with a cry of (insert Soup Nazi accent) "No cycles for you!"

Given the high priority of ABORT (just below RESET, but above IRQ), would this still be possibility?

The high priority of ABORTB, which is a non-maskable interrupt, would create intractable problems if used as a task switching mechanism. Suppose the following code (an excerpt from the DUART driver code in POC V1.1's interrupt handler) is being executed:

Code: Select all

.iirq070 bit #u92atirq         ;transmitter interrupting?
         beq .iirq110          ;no, goto next channel
;
         ldx e32tixga          ;buffer "get" index
;
.iirq080 cpx e32tixpa          ;buffer "put" index
         beq .iirq090          ;no data in buffer
;
         lda sr_92a            ;channel A status
         bit #u92txdr          ;FIFO full?  <————————————— ABORTB IS ASSERTED HERE
         beq .iirq100          ;yes, defer next datum
;
         lda e32bufta,x        ;no, get datum from buffer &...
         sta txd_92a           ;write to FIFO
         txa                   ;current buffer position
         ina                   ;new buffer position
         and #e32xmask         ;deal with wrap
         sta e32tixga          ;set next position
         tax
         bra .iirq080          ;send another byte

and let's suppose that just as the bit #u92txdr instruction is being executed ABORTB is toggled because it's time to switch tasks. What do you think would happen when the MPU resumed execution at that instruction? Consider that "aborting" an instruction causes the 65C816 to discard computational results.

Quote:

I know the 65816 is not really made for serious multitasking -- no protected mode, for one -- but whereas memory stuff would need a MMU ("the required hardware logic" as I understand from the text), what else would you need for preemptive multitasking, however primitive?

In that paragraph in my article, "required hardware logic" actually refers to whatever is needed to create a protected mode environment, not just the logic needed to generate the A16-A23 address component.

Oddly enough, preemptive multitasking doesn't required a protected environment. The first generation Commodore Amiga, which was powered by the MC68000, had no memory protection whatsoever, yet was a preemptive multitasking machine. However, the MC68000 does have "user" and "supervisor" modes. Therefore, as long as a user-written program wasn't allowed to wedge into the interrupt system, supervisor mode instructions could not be executed, which made it difficult, but not impossible, for one program to step on something that it shouldn't.

Later Amigas made use of the MC68851 MMU and then the 68030 and 68040 MPUs to implement a virtual memory system that created a true protected environment.

It can be done with the 65C816 by using complex logic to police memory accesses, instruction fetches and such. It's not simple.

Quote:

Thanks again for the text, I learned a lot. The second computer will definitely be a '816.

The ability to do 16 bit loads, stores and arithmetic with a single instruction is compelling in itself. The stack functions however, are the icing on the cake.

[BigDumbDinosaur]

ElEctric_EyE wrote:

I remember on the C-64, the certain combination keypress would trigger an NMI 'master' interrupt. IRQ's were a lesser priority.

That was the STOP-Restore combination. The Restore key on the C-64 had to whacked to get the desired effect. The result culminated in a jump to BASIC's cold start vector.

CIA #2 was also wired to NMI, as that was how the fake RS-232 functions came about. Looking back at it, it was a house of cards, but worked reasonably well.

[BigDumbDinosaur]

nyef wrote:

BigDumbDinosaur wrote:

Why is it the computer won't type what I'm thinking when I'm writing this stuff?

Because automatic spelling correction is more than aggravating enough to a fast typist who learned to type without it (or possibly even with it). Automatic grammar correction would just lead to utter gibberish when faced with someone who types three or four words before they realize that they messed up, sometimes completing a sentence that then gets auto-corrected, yet still knowing exactly how many times to hit backspace to return to where they made the mistake so that they can correct it, only making the problem worse because not only has the computer changed what was typed, but it changed it to make even less sense. The better approach would be to somehow highlight sentences (or parts thereof) that the computer thinks are somehow wrong.

Oh, wait, was that meant to be rhetorical? My bad.

I do use spell checking, since it catches typos. I would never consider using grammar correction. How would the machine know what I was thinking? Sometimes I don't even know what I'm thinking.

[barrym95838]

RE: NMI. Not to beat a dead horse, but what I'm envisioning is a device that needs to be serviced with an understandable delay, but with no jitter. I don't know if there are devices out there with synchronization needs that are so strict, but if one did exist, it could assert NMI and hold it long enough to guarantee that the processor had finished the current instruction, stacked the state, and loaded the NMI vector into PC. It would then release NMI and 'know' that the ISR would begin execution with EXACT timing precision. It would be kind of like a reset, but with an RTI available. Or like a hardware-triggered version of WAI. Am I making any sense?

Mike