| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Force a queded IRQ
Is there a way to pogrammatically ( without the CIAs ) to en-queue an IRQ from within an NMI?
BRK will interrupt an NMI.But is there some other trick, maybe some stack fiddling? |
|
... 21 posts hidden. Click here to view all posts....
|
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
A software interrupt.
However it can if needed rely on the fact it is in a NMI.
I doubt its possible, but you never know there might be some fancy trick to get it ;) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
You can trigger a SW interrupt whenever you want by using BRK or SEI/CLI in combination with a timer or raster IRQ which always is set to trigger.
I think I still don't get what you are trying to do ;-) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
BRK won't force an interrupt, as it will invoke the break handler right then and there, even if you are in an NMI.
So the ideal path is
Enter NMI
Do stuff
Optionally Queue IRQ
Do other stuff
Exit NMI
IRQ triggers when it can, if queued. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
how about setting up a raster irq (outside of available raster range), and using d019 to artifically fire a raster irq ? not sure if d019 can be used in this way tho.
similar thing could be achieved via timer interrupts too. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
If you do a CLI as first instruction of your irq code, when another irq happens it will be triggered as well...
If it's what you mean... |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
If you wish to exit NMI directly to irq handler, you have to push the irq handler address to stack so that RTI fetches it correctly.
The irq handler then runs, but there is no flagged interrupt going on, so this execution can be interrupted, unless masked.
If you want some certain interrupt to take place, then set the conditions for that interrupt(VIC/CIA) etc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:BRK won't force an interrupt
in fact that is _exactly_ what a BRK does. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
It's faster to just tail-call right into the IRQ, than it is to exit the NMI and then fake entering the IRQ handler via stack munging.
Neither the stack nor the interrupted program see any difference whether or not it was interrupted via NMI or IRQ, or if it were interrupted twice (NMI falling into IRQ after RTI) instead of once. If the prologues of both interrupt handlers match (which normally would be pushing regs to stack, instead of STA'ing them), you can do a "real" tail call:
nmi:
prologue
process
test
JMP irq_noprologue
epilogue
irq:
prologue
irq_noprologue:
process
epilogue
If the prologue/epilogue don't match, then you should do a simple test & compare after restoring saved registers. Since the processor status flags are restored as part of RTI, you don't have to worry about them, so a BCS or a BIT+BNE can perform the test right before the RTI instruction of the NMI handler, depending on how you saved the result of the decision to branch to IRQ. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting GroepazQuote:BRK won't force an interrupt
in fact that is _exactly_ what a BRK does.
Fair I was loose with my terminology.
BRK won't force an IRQ.
It will force a jump to the FFFE/FFFF vector, but not under the rules of an IRQ. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: BRK won't force an interrupt, as it will invoke the break handler right then and there, even if you are in an NMI.
So the ideal path is
Enter NMI
Do stuff
Optionally Queue IRQ
Do other stuff
Exit NMI
IRQ triggers when it can, if queued.
Isn't this the normal behaviour of a maskable irq triggered during a NMI? |
| Previous - 1 | 2 | 3 | 4 - Next |
