| |
Trap
Registered: Jul 2010 Posts: 223 |
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.... |
| |
Krill
Registered: Apr 2002 Posts: 3070 |
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: 1423 |
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: 3070 |
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: 2038 |
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: 3070 |
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: 11499 |
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: 1423 |
Samples plus FLI? Now that is brave. |
| |
JackAsser
Registered: Jun 2002 Posts: 2038 |
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: 549 |
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 |
| |
Krill
Registered: Apr 2002 Posts: 3070 |
Quoting JackAsserOfcourse u can, but less elegant and not really less error prone. A 4th line NMI is 100% predictable when it will trigger anyway. Sure, but my point was to avoid setting interrupt masks in ISRs (without drawbacks, except maybe elegance, which is somewhat subjective).
Avoid the main cause for disabling without SEI/ACK/CLI wrapper failing. =) |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |