| |
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....
|
| |
TWW
Registered: Jul 2009
Posts: 541 |
GPZ: This is done inside a sei-cli raster IRQ setup to ensure no accidental CIA IRQ triggers after cli'ing which may have activated between the sei and the point you actually disable them. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
so DONT USE SEI/CLI. *sigh* |
| |
TWW
Registered: Jul 2009
Posts: 541 |
This was posted in response to the discussion above regarding $dc0d vs CIA1_REG whatever above by Oswald/Krill.
*sight* yourself... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
>_< |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
GPZ: How about writing that SEI/CLI rant at https://codebase64.org/doku.php?id=base:interrupts ? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
Should do that, some day. Better yet, trick cjam into doing it :o) |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
@CJam: Groepaz said you had promised to write that anti SEI/CLI rant at https://codebase64.org/doku.php?id=base:interrupts We are waiting. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Quote: Best of both worlds :)
// Disable all CIA interrupts
lda #$7f
sta $dc0d
sta $dd0d
// Acknowlege any pending CIA iterrupts
lda $dc0d
lda $dd0d
winner :) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Krill, too much macroing / kickassing when people write a code that spits out sourcecode which gets assembled. and often we get questions here, which shows the guy thinks he writes the code that runs on c64, and not a code that generates src :D anyway, there's no way good of doing it just different tastes, and I like to voice my dislike for some of these. My other point against script src generation, is that often staring at your code in monitor (without label resolving!) gives the best ideas for optimising it, hence finally you see it at "matrix level", and not the assembler shit which is few steps away from what the cpu really sees. Either you have to be the cpu for good optimisation, so see the problem from an extremely low level, my other excersize to finding faster ways is to try to find a simpler solution to solve the problem. NOT always but 10 times out of 9 it will be faster.
the downside is that these two most of time doesnt gives you a better algoritmic solution, just good to shave off a few instructions.
ahyeah I also used to think stuff like "okay how to end up with the same result without having to do this or that" that mostly end up in crazy table shit, and not much win. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quoting OswaldMy other point against script src generation, is that often staring at your code in monitor (without label resolving!) gives the best ideas for optimising it
This is a good point. I often catch myself doing this especially since I perhaps rely a little much on scripts/macros. If I really need to get down and dirty, the monitor is where it's at. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
