_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

Intriguing point about STP and WAI -- would an abort render them null?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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!