| |
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....
|
| |
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: 11108 |
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: 11108 |
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? |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
If there was code running that used two or more interrupt sources to operate correctly, then using SEI/CLI would be advisable. This is because the code below without SEI/CLI is not atomic:
lda #$7f
sta $dc0d
sta $dd0d
ldx #0
stx $d01a
In other words, there are a few cycles between switching off IRQ source from CIA1, CIA2 and VIC2 where such complex code could misbehave, say for example by enabling the source in the IRQ that you've just switched off.
So using SEI/CLI is the correct bullet proof way of tackling that issue. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: If there was code running that used two or more interrupt sources to operate correctly, then using SEI/CLI would be advisable. This is because the code below without SEI/CLI is not atomic:
lda #$7f
sta $dc0d
sta $dd0d
ldx #0
stx $d01a
In other words, there are a few cycles between switching off IRQ source from CIA1, CIA2 and VIC2 where such complex code could misbehave, say for example by enabling the source in the IRQ that you've just switched off.
So using SEI/CLI is the correct bullet proof way of tackling that issue.
Yes!
// Unknown state of VIC/CIA
sei
ldx #0
stx $d01a
lda #$7f
sta $dc0d
sta $dd0d
cli
// IRQ May happen here if one was triggered between the SEI and the write to the IRQ reg to diasble them.
// Unknown state of VIC/CIA
sei
lda #0
sta $d01a
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #1
sta $d019
cli
// No URQ can trigger now from VIC/CIA.
@ GPZ: "// perhaps wait for rasterline here to avoid glitching"
Instead, just ack any pending IRQ's and you don't have to wait. Don't overthink it.
Edit: Typos |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
so, the following would work, but it's hella overengineered.
Quoting TWWYes!
// Unknown state of VIC/CIA
sei
ldx #0
stx $d01a
lda #$7f
sta $dc0d
sta $dd0d
cli
// IRQ May happen here if one was triggered between the SEI and the write to the IRQ reg to diasble them.
Given that you're still allowing the triggered IRQ to go ahead, the only effect of wrapping the above in SEI/CLI is that you're potentially delaying the response to the IRQ to after
the write, hence giving the IRQ handler an opportunity to undo it.
Quote:
// Unknown state of VIC/CIA
sei
lda #0
sta $d01a
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #1
sta $d019
cli
// No URQ can trigger now from VIC/CIA.
^the entire sequence of re-disabling CIA interrupts and acknowledging any that occured is only required in this section because you wrapped the first section in SEI/CLI |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quote: If there was code running that used two or more interrupt sources to operate correctly, then using SEI/CLI would be advisable. This is because the code below without SEI/CLI is not atomic:
lda #$7f
sta $dc0d
sta $dd0d
ldx #0
stx $d01a
In other words, there are a few cycles between switching off IRQ source from CIA1, CIA2 and VIC2 where such complex code could misbehave, say for example by enabling the source in the IRQ that you've just switched off.
So using SEI/CLI is the correct bullet proof way of tackling that issue.
The sequence doesn't need to be atomic.
Interrupts could occur before you enter the sequence regardless of whether the sequence itself is wrapped, and leaving the I flag clear just allows them to occur as late as just before the instruction performing the write.
Once the write occurs however, as long as you *didn't* execute an SEI, no CIA interrupts will occur afterwards.
And if you're concerned about a VIC interrupt reenabling your CIA interrupt, then wrapping that your code with SEI/CLI will only defer that to the end of the section; it does nothing to protect you against that. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
argh, damn it. Give the possibility of "some other coder's VIC interrupt setting up a CIA interrupt or vise versa" I might actually need to reconsider my stance.
How hostile an environment do I want to guard against is the question I guess.. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
