| |
Trap
Registered: Jul 2010
Posts: 222 |
Best practice IRQ recovery
Hi,
Here's a little newbie question. Sorry, I'm still learning this shit and it's really complicated :(
I have kernel off ($01=$35) and I am running IRQ's using the normal $fffe/$ffff vectors.
I want to exit from this and call a prepacked piece of code (in this case something packed with TinyCrunch).
I tried restoring the IRQ vectors and jump to the packer. However, it just hangs. I tried some other things but all gave the same result. The only thing that worked was when I did this:
sei
lda #$36
sta $01
jsr $ff81
jmp unpacker
The problem of course is that it resets the VIC which isn't really great for my situation.
So, my question:
What is the correct/proper way to exit from a part and go to the next? preferably not using kernal routines :|
Thank you.
Trap |
|
... 78 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
you cant just move it, you must sei first to prevent that an irq triggers right after the stx $dd0d and then enables the NMI again.
Quote:
Here is what was actually said in post #62:
"Here is the full code I use to setup a safe raster IRQ without presuming too much"
Thats a really weak argument. How would anyone know exactly what you mean? Finding out how to do it "without assuming an undefined too much" (whatever it means) is not an interesting question at all. Making it 100% safe is. And if not - then what matters most of the time. And most of the time all those scenarios where one interrupt(source) triggers and enables another interrupt(source) as a result does not matter at all - making sei/cli or even ACKing the sources in the setup code a pointless exercise in most scenarios. Those things are only needed when trying to write code that considers those special edge cases. (And then... not considering all of them is ... a bit lame :=P) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
So... how about guarding a safe interrupt disable routine against a malicious VM running on 6502 itself, so any of the routine's instructions would be made ineffective if an attempt to disable interrupts (SEI, disable bits in an interrupt mask register, etc.) is detected? =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1377 |
I'm still with groepaz on this one. For 99% of the parts out there, even if they don't shut themselves down properly all wrapping your cleanup code in SEI/CLI does is to add complexity. If I is clear, you can just turn off the sources and you're done - no acks required.
For the remaining 1%, TWW's solutions will work for some and not others - you really need to study the routine in question to see what you need, and honestly any routine with requirements so weird as to need anything more complex really should be responsible for cleaning up its own shit.
edit - and cf Krill's comment for an example of why there really is no such thing as a bulletproof routine :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Yeah, repeating myself: if you need to set interrupt masks from within an ISR, you're most likely doing it wrong and asking for trouble. =) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yeah, repeating myself: if you need to set interrupt masks from within an ISR, you're most likely doing it wrong and asking for trouble. =)
I enable/disable NMs from raster IRQs by messing with the mask. F.e. have a stable 4 line timer that I just mask/unmask in top / bottom border to enable the $d011 trickery needed. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsserI enable/disable NMs from raster IRQs by messing with the mask. F.e. have a stable 4 line timer that I just mask/unmask in top / bottom border to enable the $d011 trickery needed. Could the same effect be achieved by enabling/disabling the NMI handler's ack from a non-NMI context? (And acking previous NMI after re-enabling the handler's ack.)
Alternatively, have the 4-line timer not generate interrupts, but the other timer count just 1 underrun of the 4-line timer and generate interrupts. The latter can then be started and stopped from a non-NMI context without losing sync to VIC. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
I also did something like this in Mongobong to play samples in borders using NMI and then have FLI in the display area. Dont remember details, it probably _was_ stupid to do it like i did :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1377 |
Samples plus FLI? Now that is brave. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserI enable/disable NMs from raster IRQs by messing with the mask. F.e. have a stable 4 line timer that I just mask/unmask in top / bottom border to enable the $d011 trickery needed. Could the same effect be achieved by enabling/disabling the NMI handler's ack from a non-NMI context? (And acking previous NMI after re-enabling the handler's ack.)
Alternatively, have the 4-line timer not generate interrupts, but the other timer count just 1 underrun of the 4-line timer and generate interrupts. The latter can then be started and stopped from a non-NMI context without losing sync to VIC.
Ofcourse u can, but less elegant and not really less error prone. A 4th line NMI is 100% predictable when it will trigger anyway. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quoting Groepazyou cant just move it, you must sei first to prevent that an irq triggers right after the stx $dd0d and then enables the NMI again.
Enabling NMIs inside an IRQ... Never saw that myself, but not saying it doesn't exist.
Quoting Groepaz(And then... not considering all of them is ... a bit lame :=P)
Lame yourself :-D |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
