| |
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....
|
| |
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: 11100 |
>_< |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
GPZ: How about writing that SEI/CLI rant at https://codebase64.org/doku.php?id=base:interrupts ? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Should do that, some day. Better yet, trick cjam into doing it :o) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@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: 5017 |
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: 5017 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting OswaldKrill, 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 I dunno, seems like just overusing the hammer that is Kickass scripting and wanting to make everything a nail. :) Scripting, offline code generation and external tools producing data to .incbin are all good things, when used right.
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 Source level and machine code level are two different things. I also like to look at the code in the monitor to spot low-level (non-algorithmic) performance or size optimisation opportunities, but translating the solutions back to the source code then results in a higher-level representation to produce the desired output. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting TWWBest of both worlds :)
// Disable all CIA interrupts
lda #$7f
sta $dc0d
sta $dd0d
// Acknowlege any pending CIA iterrupts
lda $dc0d
lda $dd0d
What about this ;)
ldx #$80
nop $dc8d,x
dex
stx $dc0d
stx $dd0d
Then again, Groepaz is right: once an irq-source is disabled, acknowledging should be in the realm of the irq handler.
And Frantic is even more correct in stating that the SEI considered harmful-article has to be added to codebase asap'st ;) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
