| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting TrapI am not using NMI or reading any keyboard presses. Just a normal IRQ running with kernal off ($01=$35).
Then you can ignore almost all of the last 50 comments, and just
lda #$7f
sta $dc0d
ldx #0
stx $d01a
no SEI/CLI required. (that said, you do still need to ack the interrupt you're responding to if you do this in an ISR instead of in your main) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting TWWWhen the inevitable RTI is executed
We already covered this - the RTI is not at all inevitable if the interrupt in question is just setting up for another interrupt. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: But what if the NMI handler manipulates the Stack? Are you assuming it doesnt?
If the NMI code messes with the stack, the RTI won't work, and chances are any previously running code prior to this would not have worked either.
@ Trap: If you setup and have control of your interrupts as I posted above, it should be straight forward to handle unpacking and transitions since you only need to handle Raster IRQs (assuming no funky memory banking).
// space is pressed inside a raster IRQ or whatever
// I-Flag is set since it's handled inside the IRQ
ldx #0
stx $d01a
inx
stx $d019
cli
// no more (internal) interrupts can happen here
jmp depack
PS. STACK is messed up at this point, so you cannot have any rti/rts. If the depacker sei/cli or not should not matter as long as it doesn't activate any IRQs. Finally ensure that there is no mem-bank trickery going on which may mess things up. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: Quoting TWWWhen the inevitable RTI is executed
We already covered this - the RTI is not at all inevitable if the interrupt in question is just setting up for another interrupt.
If the interrupt in question is just setting up for another interrupt, you do not need to do anything except handle the ongoing *known* interrupt and it's source, assuming you *know* that no other internal interrupts may occur. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
You are assuming quite a bit now - wasnt your code about not assuming anything and work always?
Quote:If the NMI code messes with the stack, the RTI won't work, and chances are any previously running code prior to this would not have worked either.
no?
nmiend:
bit flag
bmi notyet
plp
and #~4
php
notyet:
rti
(yes the working code looks a bit more elaborate, you get the idea) |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quoting Groepaz(yes the working code looks a bit more elaborate, you get the idea)
Yes I get the idea. Interesting argument technique, I use it myself sometimes...
So by your reasoning, would the 2nd sei in the code above mean that you consider it 100% safe?
If yes - Are you sure someone couldn't tailor some code to break it anyway if they really wanted to :)
If no - Why did you make the argument, knowing it's pointless?
Edit:
It just occurred that you could move the sei after disabling/ack'ing $dc0d. No need to have one before so you still only need one sei to counter the evil GPZ code above hehe :) |
| |
Trap
Registered: Jul 2010
Posts: 222 |
In case somebody has the same question, I'll post what I finally found to work. Thanks a million to all the great input from you guys.
Not 100% what I'm doing here, but it works :)
sei
lda #$36
sta $01
jsr vsync
lda #$0b
sta $d011
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$48
sta $fffe
lda #$ff
sta $ffff
ldx #0
stx $d01a
inx
stx $d019
cli
jmp nextthinghappening
Thank you.
Trap |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:If yes - Are you sure someone couldn't tailor some code to break it anyway if they really wanted to :)
If no - Why did you make the argument, knowing it's pointless?
Oh, its not me who is saying his code is totally safe and makes no assumptions. Step back and look at what you posted in #62 - it will work pretty much exactly the same for all practical purposes, without the sei/cli :) Except when you try hard to break it, which will require exploiting similar uncommon scenarios as the one i posted.
trap: do the vsync (better: wait a frame) after setting d011 to $0b - then you can be sure it will really be blanked (the flag is only checked once per frame ~line f8 or sth) |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quoting Groepazits not me who is saying his code is totally safe and makes no assumptions. Step back and look at what you posted in #62
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"
If you're going to paraphrase, at least do it right.
Besides, it still only took to move one sei to counter your example of destructive code;
ldx #$7f
stx $dd0d
lda $dd0d
sei
stx $dc0d
lda $dc0d
Thanks for contributing to improve it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
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) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
