Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Best practice IRQ recovery
2021-06-10 20:30
Trap

Registered: Jul 2010
Posts: 221
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....
 
2021-06-13 18:01
Oswald

Registered: Apr 2002
Posts: 5007
2021-06-13 18:20
TWW

Registered: Jul 2009
Posts: 541
Quoting Groepaz
you forgot the second SEI


If a NMI is executed between the SEI and the DD0D disable code, the Processor Status Register (PSR) gets pushed to the stack. When the inevitable RTI is executed the PSR is pulled from stack, the I-flag is restored without the need to set it a second time.
2021-06-13 18:21
Trap

Registered: Jul 2010
Posts: 221
Wow. This sure sparked a discussion :) I read the thread a few times, but I honestly still don't feel I am any bit closer to knowing how I should deal with my problem?

Thank you all for dishing in - truly wonderful and much appreciated though :)
2021-06-13 18:21
chatGPZ

Registered: Dec 2001
Posts: 11088
But what if the NMI handler manipulates the Stack? Are you assuming it doesnt?
2021-06-13 18:35
Trap

Registered: Jul 2010
Posts: 221
I am not using NMI or reading any keyboard presses. Just a normal IRQ running with kernal off ($01=$35).
2021-06-13 18:56
chatGPZ

Registered: Dec 2001
Posts: 11088
To answer your question we'd still need to know what exactly you are trying to do - there is no universal answer :)
2021-06-13 18:57
ChristopherJam

Registered: Aug 2004
Posts: 1359
Quoting Trap
I 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)
2021-06-13 18:58
ChristopherJam

Registered: Aug 2004
Posts: 1359
Quoting TWW
When 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.
2021-06-13 19:19
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.
2021-06-13 19:32
TWW

Registered: Jul 2009
Posts: 541
Quote: Quoting TWW
When 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.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Jucke
deetsay
hedning/G★P
Airwolf/F4CG
fandenvoldsk
jmin
tlr
t0m3000/ibex-crew
wil
Bansai/BSILabs
LightSide
iceout/Avatar/HF
algorithm
K-reator/CMS/F4CG
Guests online: 344
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.058 sec.