| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
NMI delay
How much is an NMI delayed if triggered during IRQ-setup? |
|
... 45 posts hidden. Click here to view all posts....
|
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
To really get an answer to this the PLA ROM needs to be understood.
http://www.visual6502.org/JSSim/expert.html
https://www.pagetable.com/?p=410
https://www.pagetable.com/?p=39
"At the end of each instruction, the PLA causes the T bitfield to reset, so that the next instruction starts with T1=1 again."
"All interrupt and NMI requests are always delayed until the current instruction is finished, i.e. until T gets reset." |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: To really get an answer to this the PLA ROM needs to be understood.
http://www.visual6502.org/JSSim/expert.html
https://www.pagetable.com/?p=410
https://www.pagetable.com/?p=39
"At the end of each instruction, the PLA causes the T bitfield to reset, so that the next instruction starts with T1=1 again."
"All interrupt and NMI requests are always delayed until the current instruction is finished, i.e. until T gets reset."
Given that and given that an IRQ really is a BRK-instruction under the hood we can assume the delay can be up to 7 cycles then? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11147 |
If only it was that simple :o)
It might be a good idea to simulate and iterate too all possible timings (ie trigger the nmi in every possible half cycle of that "BRK") and then see what happens. If i understood the wiki correctly, there are still special cases to consider. |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: If only it was that simple :o)
It might be a good idea to simulate and iterate too all possible timings (ie trigger the nmi in every possible half cycle of that "BRK") and then see what happens. If i understood the wiki correctly, there are still special cases to consider.
Yeah, someday. For now I simply made sure that my IRQs never collides with the NMIs. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11147 |
BAH! DO IT! :D |
| |
Martin Piper
Registered: Nov 2007
Posts: 645 |
Quote: Yeah, someday. For now I simply made sure that my IRQs never collides with the NMIs. :)
There's no real problem as both will trigger eventually. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11147 |
The problem is having predictable timing in all cases. Of course they trigger (except when they don't - see the wiki pages). |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: The problem is having predictable timing in all cases. Of course they trigger (except when they don't - see the wiki pages).
Exactly. My NMIs must NOT be delayed or this card house will fall completly and ungraceful. |
| |
Fungus
Registered: Sep 2002
Posts: 629 |
Quote: The problem is having predictable timing in all cases. Of course they trigger (except when they don't - see the wiki pages).
Yes this is what I was looking at too, to see in which instances the IRQ is "eaten". I need to do some simulations there too and see if this behavior can be documented so we know exactly when and how this can occur.
I was already aware of BRK can eat an IRQ and vice versa, but if NMI is also a BRK instruction then the same thing could happen. It's just a matter of under what circumstances... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11147 |
Yes. Those wiki pages are very confusing for that matter, because they also consider cases that can never happen - in a C64 anyway. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
