| |
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....
|
| |
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: 2821 |
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 ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Krill[...]
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. Exactly what I thought when reading all the comments on "Kickass-scripting". I think you, Oswald, are totally right in stating that most (if not all) golden optimization nuggets will solely be found when looking at the code on a monitor-level (be it via Vice, C64Debugger, on the real deal, whatnot).
But expecially when it comes to data preparation (which I think is the main purpose for the nowadays oh so popular "scripting"), I'm not willing to do this manually nor write everything as 6510-native-code if it can be avoided. But maybe I'm just getting old and lazy, idk... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Quote:And Frantic is even more correct in stating that the SEI considered harmful-article has to be added to codebase asap'st ;)
another volunteer! |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quoting Copyfaultacknowledging should be in the realm of the irq handler.
Even if you disable new CIA IRQ's from occurring, existing ones isn't cleared and may trigger a premature interrupt.
Simply put:
// You do not know the state of the CIA here
sei
// a CIA interrupt may activate here
lda #$7f
sta $dc0d
sta $dc0d
// CIA maintain the IRQ signal, but don't generate new ones
lda #100
sta $d012 // This is where you want the IRQ to happen
lda #1
sta $d01a
fffe/ffff vetor = IRQ_Code
cli
// latent CIA IRQ triggers here instead of @ line 100
jmp *
IRQ_Code:
blablabla
Avoided by ack'ing the CIAs prior to cli'ing |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
we *really* need this rant :)
// switch off irq sources
lda #$7f
sta $dc0d
sta $dd0d
ldx #0
stx $d01a
// whatever irq was pending triggers here and the old handler handles it
// setup irq sources and change pointers
lda #100
sta $d012
lda #$1b
sta $d011
lda #>handler
sta $ffff
lda #<handler
sta $fffe
// perhaps wait for rasterline here to avoid glitching
// enable irq sources
inx
stx $d01a
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Groepazwe *really* need this rant :) We do, but I won't volunteer as I'm not worthy enough to tickle this sensitive topic!
Quoting Groepaz
// switch off irq sources
lda #$7f
sta $dc0d
sta $dd0d
ldx #0
stx $d01a
// whatever irq was pending triggers here and the old handler handles it
// setup irq sources and change pointers
lda #100
sta $d012
lda #$1b
sta $d011
lda #>handler
sta $ffff
lda #<handler
sta $fffe
// perhaps wait for rasterline here to avoid glitching
// enable irq sources
inx
stx $d01a
Yes, this is the way to do it. Only detail I'm not sure about is when the potentially still pending IRQs might happen: my guess is that the irq acknowledging will still be in place, i.e. any "old" irq routine might be called at different spots.
// switch off irq sources
lda #$7f
sta $dc0d
//if an irq condition happens before cycle 3 of this opcode, it will be
//triggered directly after the STA-opcode has been processed...
sta $dd0d
//...if not, it will take until this 2nd STA-opcode before the irq is triggered
ldx #0
//same here: any pending IRQs of CIA2 will happen here the latest
stx $d01a
// whatever irq was pending triggers here...
// setup irq sources and change pointers
lda #100
//..or here if the raster IRQ condition occured at cycle 3 or 4 of the STX-opcode
[...]
Is this correct or do I mix things up? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
