Re: 65816 abort line on the AppleIIgs

[Matthew Montchalin <mmontcha@OregonVOS.net>]

On 31 Oct 2002, Michael J. Mahon wrote:
|>I've heard conflicting information about just what happens when the
|>Abort pin is pulled low.  Is it true that it wipes out the instruction
|>currently being executed?  Someone told me that it tries to 'resume'
|>the instruction when you finally RTI and get out of the Abort handler.
|>Obviously a ROR <memory address> instruction, if interrupted in the
|>middle of the rotation, is going to result in something odd after
|>the processor resumes from the Abort.
|
|The intent is that it cancels the effect of the in-process instruction,
|and it should work if asserted during the first memory-access
|cycle of an instruction.

Can you be more explicit?  If ror <address> involves a read of a
specified memory address, and then rotate some internal register
+carry, before write-back, are you suggesting that it makes no
difference how far into the execution we go, if the abort occurs
prior to the write-back, the whole instruction is executed over
again, after we get back from the Abort handler?

|This is consistent with it's intended use for a virtual memory
|implementation,

I was just thinking it would be more useful for implementing
a copy-protecting mechanism to be used in conjunction with
copy-protected software.

|where it would be used to interrupt & cancel the current instruction
|if it referred to un-mapped memory--a page fault.
|
|After the page has been made present by an interrupt service
|routine,

Sure, the Abort handler itself would have to save stuff to disk,
bring something else in from disk, and then restore registers
and RTI.

|the program would be resumed at the aborted instruction
|so that it could re-execute to completion.

Hmmmmmmm....  Okay.