BigEd notes that 65816 /ABORT pin functionality may be completely unexplored within a practical system. BigDumbDinosaur notes that use of /ABORT for memory protection may cause an infinite loop if stack memory faults. BigDumbDinsaur is also fond of re-purposing vectors, such as using COP as a operating system entry point possibly in conjunction with raised privileges via /VP pin. BigDumbDinsaur and Alarm Siren note that /ABORT is insufficient to avert an unprivileged application from executing WAI or STP, intentionally or not. (Detection of this case may be similar to the rather inelegant Linux x86 F00F workaround.)

Given that /ABORT is insufficient for all cases of privilege enforcement, it may be desirable to re-purpose /ABORT as a general purpose interrupt unrelated to any specific instruction or memory cycle. In this case, /ABORT would be more significant than /IRQ or /NMI but less significant than /RESET. Like /NMI, /ABORT would be unmaskable. The typical use case would be a programmer's diagnostic tool. A debounced button (using BigDumbDinsaur's favorite technique of a DS1813 reset circuit or the functionally similar MCP101) may be used to execute diagnostic software, such as a monitor program. For cost conscious development, a 65816 with three interrupt levels may be used for development of software deployed on 6502 with two interrupt levels. This arrangement places many conditions on compatible software. Thankfully, the extra interrupt level does not affect hardware which uses both /IRQ and /NMI. In particular, it does not slow interrupt response during normal operation.

Any idiot who can get NOPs running can test the trivial case. For every assertion of /ABORT, /VP should go low once or twice. To test more advanced cases, we only require a short chain of flip-flops operating at processor frequency. This would allow testing of /IRQ, /NMI and/or /ABORT which occurs simultaneously or staggered by one cycle or more. If /VP count doesn't match then the inference is that /ABORT gets ignored. Hopefully, /VP count always matches.

The problem that I foresee is semantic. Are we aborting memory cycles or instructions? Probably instructions. Is interrupt handling an interruptable instruction? Probably not - and this is where we get the ambiguity about a memory access fault during interrupt handling. If the processor is not inside an instruction cycle or in an abortable state, /ABORT might be entirely ignored. Maybe. Or perhaps it is correctly implemented such that simultaneous IRQ/NMI/ABORT nests as expected. This would only be a minor extention of simultaneous IRQ/NMI handling. Although, it does raise a question about worse case response time on 65816. Given that /ABORT is a negative edge interrupt, it is likely to have all desirable behavoir. However, it is possible that only IRQ/NMI and IRQ/ABORT interact correctly.

In the optimistic case, we effectively have /IRQ, /NMI0 and /NMI1. In the pessimistic case, a horrible hack may be required, such as making NMI/ABORT mutually exclusive or deriving a signal from /VP, A1, A2 and A3 to ensure that the correct vector has been followed and then re-asserting /ABORT if it hasn't.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

My expectation is that ABORT is intended to detect unwanted memory accesses and to abort instructions. It's likely that whatever raises ABORT is expected to lower it too. I would expect that to be on a cycle by cycle (access by access basis), in which case when the abort handler usurps the following instruction, we might or might not have ABORT re-signalled, we could conceivably get ABORT re-signalled on the three stack pushes (although that would be a very odd system design) but by the time the vector pulls come around all memory accesses would surely be legal ones: the vector reads will be legal and the ISR they point to will all be legal. In which case we won't be seeing ABORT affecting the ISR at all.