ABORTB and the 65C816

[BigDumbDinosaur]

The 65C816's ABORTB input is described on page 7 of the data sheet as being able to "...interrupt the currently executing instruction without modifying internal register..." Elsewhere, the data sheet says:

• 2.13 Abort (ABORTB)
  The Abort negative pulse active input is used to abort instructions (usually due to an Address Bus
  condition). A negative transition will inhibit modification of any internal register during the current
  instruction. Upon completion of this instruction, an interrupt sequence is initiated. The location of the
  aborted opcode is stored as the return address in stack memory.

These seemingly-conflicting statements lead me to try to determine just what it is that an ABORTB interrupt is doing. Literally interpreted, it turns out that both of the above descriptions are only partially correct. The '816 doesn't "abort" an instruction in response to an ABORTB interrupt—all instructions are completed, even if ABORTB is toggled during the opcode fetch cycle. An ABORTB interrupt can be relied upon to prevent an instruction from modifying a register, assuming timing requirements are met. Whether memory would be modified is open to discovery, as the data sheet sheds no light on whether a memory access does occur despite the instruction having been "aborted."

However, my interpretation is that an ABORTB interrupt doesn't actually abort an instruction and thus cannot be expected to prevent an "aborted" instruction from changing the MPU's internal state, as would occur with the control instructions STP and WAI, neither of which modify a register or memory. Trying to empirically determine what would happen if ABORTB were toggled during the opcode fetch cycle of STP or WAI isn't possible on my POC hardware, so my suppositions are just that. If they are true, then my plan to set up virtual privileged instructions by using a CPLD to read the data bus during the opcode fetch cycle and toggle ABORTB if the opcode is not allowed isn't going to work as expected.

[GARTHWILSON]

Quote:

Whether memory would be modified is open to discovery, as the data sheet sheds no light on whether a memory access does occur despite the instruction having been "aborted."

Could you add a little logic to your CPLD between the processor's R/W\ output and the R/W\ to the bus, keeping the latter from going down during an instruction that was ABORTed? The instructions are different lengths, but you could leave this in effect until VPA tells you that the next instruction is starting, right?

[Dr Jefyll]

Interesting topic! But I think some of the mystery disappears if we accept that, in this context, the word "abort" simply means "render null." Otherwise, the word "abort" tends to suggest there will be some clock cycles missing, and that's probably incorrect. I expect an aborted instruction will still consume the expected number of cycles -- and so, in that sense, the instruction does "complete." However, the aborted instruction will not alter the state of the machine. That would include memory, I should think. (Otherwise the ABORTB input would be ineffective for its intended purpose.)

I've just suggested that the number of cycles would remain the same -- meaning that if a write to memory would normally have occurred, then the cycle for that write operation will still be scheduled. However, its effect can be rendered null if, during that cycle, the CPU simply omits the assertion of RWB and/or VDA. Meanwhile, the same thing is happening internally: writes to internal registers are likewise inhibited.

cheers,
Jeff

ps- Oops, missed reading your post while writing my own, Garth. I suspect the extra logic you suggest is unnecessary; however, I'd like to see the matter proven one way or the other.

[BigEd]

You say toggled, BDD, but I trust you mean you hold AbortB low until the vector fetch?

[Dr Jefyll]

Intriguing point about STP and WAI -- would an abort render them null?

BDD wrote:

Trying to empirically determine what would happen if ABORTB were toggled during the opcode fetch cycle of STP or WAI isn't possible on my POC hardware

Does the POC not have a timer you could set to expire (and generate an ABORT) just as a STP or WAI op-code (included as part of a test routine) is fetched? Failing that, you could tie the ABORTB input to address line A14 (for example), and map your test code so that the preamble is just below $8000 and the STP or WAI op-code is located exactly at $8000. Other address lines & addresses could work. There'd be some details to iron out, but you get the idea. It's goofy, but for a one-off experiment it might be satisfactory! Just a suggestion

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

Whether memory would be modified is open to discovery, as the data sheet sheds no light on whether a memory access does occur despite the instruction having been "aborted."

Could you add a little logic to your CPLD between the processor's R/W\ output and the R/W\ to the bus, keeping the latter from going down during an instruction that was ABORTed? The instructions are different lengths, but you could leave this in effect until VPA tells you that the next instruction is starting, right?

That could work. According to the instruction operation detail in the data sheet (page 43, section 22a), the expression VDA & VPA is true during the first cycle of an interrupt response, even though there isn't an opcode to be fetched. So, my little dinosaur brain is thinking that if the CPLD decides to toggle ABORTB it could also tell itself to ignore the actual state of RWB until VDA & VPA goes true again, indicating that the MPU is responding to the interrupt. Such a sequence should suppress any attempt by the MPU to write to memory while completing the aborted instruction.

Dr Jefyll wrote:

I expect an aborted instruction will still consume the expected number of cycles -- and so, in that sense, the instruction does "complete."

Which is what the data sheet says at one point.

Quote:

However, the aborted instruction will not alter the state of the machine. That would include memory, I should think. (Otherwise the ABORTB input would be ineffective for its intended purpose.)

The data sheet's wording is ambiguous in this regard. Early on, it is said:

• The ABORTB input can interrupt the currently executing instruction without modifying internal register, (sic) thus allowing virtual memory system design.

The key phrase is "...without modifying internal register". As ABORTB is an interrupt, it is implied (and later stated) that the current instruction will be completed. Indeed, the detailed operation section shows that ABORTB and the other hardware interrupts are alike in that regard. What isn't said is what RWB is up to after ABORTB has been toggled but before the abort interrupt is processed.

Quote:

I've just suggested that the number of cycles would remain the same -- meaning that if a write to memory would normally have occurred, then the cycle for that write operation will still be scheduled. However, its effect can be rendered null if, during that cycle, the CPU simply omits the assertion of RWB and/or VDA. Meanwhile, the same thing is happening internally: writes to internal registers are likewise inhibited.

The data sheet gives no specific indication if RWB is negated during what would normally be the write cycle of a write or R-M-W instruction. However, a caveat in the data sheet may give a clue:

• 7.4.1.1 Read-Modify-Write: Processor status modified if ABORTB is asserted after a modify cycle.

One could interpret this to mean that write-suppression occurs if ABORTB is toggled early enough in the instruction sequence. If that were the case every time then Garth's suggestion about having the CPLD inhibit a write operation would be belts-and-suspenders, but nevertheless a wise precaution.

BigEd wrote:

You say toggled, BDD, but I trust you mean you hold AbortB low until the vector fetch?

No, I did mean toggle. The data sheet recommends that ABORTB be asserted for only one clock cycle:

• 7.4 ABORTB Input
  7.4.1 ABORTB should be held low for a period not to exceed one cycle. Also, if ABORTB is held
  low during the Abort Interrupt sequence, the Abort Interrupt will be aborted.

Dr Jefyll wrote:

Intriguing point about STP and WAI -- would an abort render them null?

This just in! (Sounds like a news flash but I got E-mail from WDC as I was typing this.)

I had queried WDC on that exact thing, since the data sheet doesn't go into specifics. WDC ran a simulation of an abort occurring during the opcode fetch cycle of STP and WAI and determined that both instructions will ignore ABORTB and halt the MPU. So it isn't possible to prevent either instruction from being executed. An unwanted WAI isn't a real problem if a jiffy IRQ is present, as all that will happen is some time will be wasted. As long as WAI is not preceded by SEI, the next interrupt will resume operation and be serviced as expected. Aborting SEI will block an attempt to disable IRQs, since SEI modifies a register.

STP is an altogether different matter... Urk!

[GARTHWILSON]

Quote:

7.4.1 ABORTB should be held low for a period not to exceed one cycle. Also, if ABORTB is held
low during the Abort Interrupt sequence, the Abort Interrupt will be aborted.

So it's kind of like a level-sensitive IRQ that does not set an interrupt-disable bit. I wonder if that could have other interesting uses.

[BigDumbDinosaur]

GARTHWILSON wrote:

So it's kind of like a level-sensitive IRQ that does not set an interrupt-disable bit. I wonder if that could have other interesting uses.

An abort interrupt does set the I bit in the status register after PB, the aborted instruction's address and SR have been pushed. In that respect it's almost like any other interrupt. The two differences are in what is being pushed for a program counter value and the hardware vector taken by the MPU.

Given the rather specific purpose of ABORTB and the relatively strict timing requirements for its usage, I'm drawing a blank on using it for any other purpose.

[Dr Jefyll]

BDD wrote:

WDC ran a simulation of an abort occurring during the opcode fetch cycle of STP and WAI and determined that both instructions will ignore ABORTB and halt the MPU.

Wow, really? Doesn't that constitute a bug?! ABORTB should allow you to implement virtual memory -- to create the illusion of having 16 MB of RAM when in fact there's less. IOW you alias the existing RAM, and rely on aborts generated by your mapping hardware. When a program makes reference to something not currently resident in RAM, an abort intervenes to access mass storage and make it resident. Usually that means overwriting some existing RAM contents from earlier. But the program should never "see" the stale content if virtual memory is working properly.

There'd be no problem making reference to data which is non-resident. But if the reference is a code fetch (for instance you've just made a JML or JSL) and the first byte of yet-to-be-updated RAM you touch happens to contain $DB or $CB then you're sunk! Although ABORTB will be asserted the CPU won't obey. Instead, a STP or WAI will erroneously be executed. Am I missing something? This makes me wonder whether virtual memory for '816 has ever been realized in practice, or is just a theoretical potential.

One workaround would be to ensure that code accesses to non-resident addresses not only trigger an abort but also force a known value (such as $EA) onto the data bus. The non-response of STP & WAI to ABORTB should be noted in the Caveats of Section 7.4 !!

cheers,
Jeff

[BigEd]

Thanks for the clarification on the single-cycle, BDD. Also for the note that it's the unmodified PC which is stacked (interesting, as it could presumably have been incremented up to three times in fetching operand bytes)
Are WDC able to say anything about turning writes into reads, or suppressing VDA?

[BigDumbDinosaur]

BigEd wrote:

Thanks for the clarification on the single-cycle, BDD. Also for the note that it's the unmodified PC which is stacked (interesting, as it could presumably have been incremented up to three times in fetching operand bytes)

The theory is that if ABORTB is being toggled due to a memory fault you'd want to be able to re-execute the instruction after the memory fault had been corrected. On the other hand, if ABORTB was toggled due to a memory access violation or similar you could retrieve the aborted instruction's address from the stack and report it to the user in an error routine.