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 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.
2021-06-13 20:27
chatGPZ

Registered: Dec 2001
Posts: 11088
You are assuming quite a bit now - wasnt your code about not assuming anything and work always?

Quote:
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.

no?

nmiend:
  bit flag
  bmi notyet
  plp
  and #~4
  php
notyet:
  rti


(yes the working code looks a bit more elaborate, you get the idea)
2021-06-13 21:03
TWW

Registered: Jul 2009
Posts: 541
Quoting Groepaz
(yes the working code looks a bit more elaborate, you get the idea)


Yes I get the idea. Interesting argument technique, I use it myself sometimes...

So by your reasoning, would the 2nd sei in the code above mean that you consider it 100% safe?

If yes - Are you sure someone couldn't tailor some code to break it anyway if they really wanted to :)
If no - Why did you make the argument, knowing it's pointless?

Edit:
It just occurred that you could move the sei after disabling/ack'ing $dc0d. No need to have one before so you still only need one sei to counter the evil GPZ code above hehe :)
2021-06-13 23:02
Trap

Registered: Jul 2010
Posts: 221
In case somebody has the same question, I'll post what I finally found to work. Thanks a million to all the great input from you guys.

Not 100% what I'm doing here, but it works :)

sei
lda #$36
sta $01
jsr vsync
lda #$0b
sta $d011
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$48
sta $fffe
lda #$ff
sta $ffff
ldx #0
stx $d01a
inx
stx $d019
cli
jmp nextthinghappening

Thank you.

Trap
2021-06-13 23:21
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
If yes - Are you sure someone couldn't tailor some code to break it anyway if they really wanted to :)
If no - Why did you make the argument, knowing it's pointless?

Oh, its not me who is saying his code is totally safe and makes no assumptions. Step back and look at what you posted in #62 - it will work pretty much exactly the same for all practical purposes, without the sei/cli :) Except when you try hard to break it, which will require exploiting similar uncommon scenarios as the one i posted.

trap: do the vsync (better: wait a frame) after setting d011 to $0b - then you can be sure it will really be blanked (the flag is only checked once per frame ~line f8 or sth)
2021-06-14 00:03
TWW

Registered: Jul 2009
Posts: 541
Quoting Groepaz
its not me who is saying his code is totally safe and makes no assumptions. Step back and look at what you posted in #62


Here is what was actually said in post #62:

"Here is the full code I use to setup a safe raster IRQ without presuming too much"

If you're going to paraphrase, at least do it right.

Besides, it still only took to move one sei to counter your example of destructive code;

    ldx #$7f
    stx $dd0d
    lda $dd0d
    sei
    stx $dc0d
    lda $dc0d

Thanks for contributing to improve it.
2021-06-14 00:21
chatGPZ

Registered: Dec 2001
Posts: 11088
you cant just move it, you must sei first to prevent that an irq triggers right after the stx $dd0d and then enables the NMI again.

Quote:

Here is what was actually said in post #62:

"Here is the full code I use to setup a safe raster IRQ without presuming too much"


Thats a really weak argument. How would anyone know exactly what you mean? Finding out how to do it "without assuming an undefined too much" (whatever it means) is not an interesting question at all. Making it 100% safe is. And if not - then what matters most of the time. And most of the time all those scenarios where one interrupt(source) triggers and enables another interrupt(source) as a result does not matter at all - making sei/cli or even ACKing the sources in the setup code a pointless exercise in most scenarios. Those things are only needed when trying to write code that considers those special edge cases. (And then... not considering all of them is ... a bit lame :=P)
2021-06-14 10:27
Krill

Registered: Apr 2002
Posts: 2804
So... how about guarding a safe interrupt disable routine against a malicious VM running on 6502 itself, so any of the routine's instructions would be made ineffective if an attempt to disable interrupts (SEI, disable bits in an interrupt mask register, etc.) is detected? =)
2021-06-14 10:32
ChristopherJam

Registered: Aug 2004
Posts: 1359
I'm still with groepaz on this one. For 99% of the parts out there, even if they don't shut themselves down properly all wrapping your cleanup code in SEI/CLI does is to add complexity. If I is clear, you can just turn off the sources and you're done - no acks required.

For the remaining 1%, TWW's solutions will work for some and not others - you really need to study the routine in question to see what you need, and honestly any routine with requirements so weird as to need anything more complex really should be responsible for cleaning up its own shit.


edit - and cf Krill's comment for an example of why there really is no such thing as a bulletproof routine :D
2021-06-14 10:47
Krill

Registered: Apr 2002
Posts: 2804
Yeah, repeating myself: if you need to set interrupt masks from within an ISR, you're most likely doing it wrong and asking for trouble. =)
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
Fungus/Nostalgia
Mason/Unicess
t0m3000/ibex-crew
Freeze/Blazon
Guests online: 349
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 Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

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