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 > TIL: The instruction after SEI can be executed before a pending IRQ is handled
2017-11-07 15:56
Krill

Registered: Apr 2002
Posts: 2804
TIL: The instruction after SEI can be executed before a pending IRQ is handled

As described here: http://visual6502.org/wiki/index.php?title=6502_Timing_of_Inter..

I never knew this, after all those years, and thought i'd share this as a heads-up.

Thanks to Bubis for pointing it out to me!
 
... 89 posts hidden. Click here to view all posts....
 
2017-11-12 18:11
Oswald

Registered: Apr 2002
Posts: 5007
Quote: It's not uncommon that bugs cause erroneous behaviour only in the presence of other bugs. Fix only either, and the other lies dormant until some later time, fix both and you win. :)

sei/cli wasnt there to fix a bug.
2017-11-12 18:29
chatGPZ

Registered: Dec 2001
Posts: 11088
time for some classic rock
2017-11-12 23:02
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Krill
Hmm, what does that setup from timer IRQ save? I don't see the shortening (and you'd also have to ack the IRQ yourself). :)
Ah, you're right with that acknowledging of the IRQ which would come "on top".

Quoting Krill
And please explain your notion of "irq-levels". How many are there? Are interrupt handlers themselves interrupted? Are there more banking settings than all-RAM ($30/$34) for main loop and with IO ($35) for interrupt handlers? Something going via $0314/15?
Yes, what did I mean with "irq-level" *questioningmyself*? I just wanted to distinguish between a "level=0" situation which would be code running outside any irq (which usually is the main loop) and a "level>0" situation for code running inside an IRQ. As there is a certain priority among the different IRQ triggers (e.g. NMI beats Raster), one could define the "irq-level" along these priorities; alternatively, an irq-level could also describe the "depth" of the IRQ trigger chain which occurs when an IRQ is triggered on code running inside an IRQ and so on, but...

...but for the case I had in mind, the terms "main loop" and "inside Raster IRQ" suffice, so I better switch to these now. Usually, I have a main loop running and a raster irq set up. I want a clear separation between the memory access: full ram ($01=$34) in the main loop and IO ($01=$35) in the irq code. As there are usually some IO-registers to be initialised during init, I at least need $01=$35 once in the main loop. By misusing the CIA1-irq as stated in one of my former postings I could avoid this and have all IO accesses inside the IRQ.

Which leaves me with a little question. Is it possible to have an IRQ execution directly after the write cycle of that STA $D019?
...
sta $d019
-> irq possible _before_ the next instruction?? <-
dec $01
...
(has influence on the irq code, i.e. wether an INC $01 at the beginning suffices or a LDA#$35:STA$01 is a must -> +2 bytes :/)


Even more benefit would most probably come together when misusing that CIA1-IRQ of the basic startup for init when using timer irqs instead of raster irqs. But I'll stop now, toooo much text already :)
2017-11-13 12:41
Krill

Registered: Apr 2002
Posts: 2804
Quoting Copyfault
Is it possible to have an IRQ execution directly after the write cycle of that STA $D019? [...] (has influence on the irq code, i.e. wether an INC $01 at the beginning suffices or a LDA#$35:STA$01 is a must
You ack a possibly pending raster IRQ with the write access to $d019, but any potentially arising subsequent raster IRQ condition should not trigger an actual IRQ before you enable the raster IRQs via $d01a. This will be when you have already set up your IRQ handler, and that one will behave and properly backup and restore $01. So i guess INC $01 works.
2017-11-13 14:14
spider-j

Registered: Oct 2004
Posts: 443
Quoting Krill
but any potentially arising subsequent raster IRQ condition should not trigger an actual IRQ before you enable the raster IRQs via $d01a.

Do I understand correctly that when setting up a raster IRQ without SEI/CLI the write to $d01a is the "pendant" to CLI?

So according to you guys the correct way (coming from BASIC) would be:
lda #$7f
sta $dc0d

; ...
; do init stuff ( $01 config etc. )
; setup $fffe/$ffff and $d011 / $d012 for raster IRQ
; ...

lda #$01
sta $d01a  ; raster IRQ is able to fire after this (?)

?!?

No need for $d019 in this case, is that correct?
2017-11-13 15:42
chatGPZ

Registered: Dec 2001
Posts: 11088
correct
2017-11-13 15:49
TWW

Registered: Jul 2009
Posts: 541
Quote: Quoting Krill
but any potentially arising subsequent raster IRQ condition should not trigger an actual IRQ before you enable the raster IRQs via $d01a.

Do I understand correctly that when setting up a raster IRQ without SEI/CLI the write to $d01a is the "pendant" to CLI?

So according to you guys the correct way (coming from BASIC) would be:
lda #$7f
sta $dc0d

; ...
; do init stuff ( $01 config etc. )
; setup $fffe/$ffff and $d011 / $d012 for raster IRQ
; ...

lda #$01
sta $d01a  ; raster IRQ is able to fire after this (?)

?!?

No need for $d019 in this case, is that correct?


I guess you could time the raster to trigger at line #$80 and then enable raster IRQs at VSYNC and see if the raster IRQ triggers immediately or only when raster compare = 80.

This should depend on VIC behaviour, and exactly how the internals deal with the IRQ line (i.e. does the IRQ masking override the output or inhibit the input).

Too lazy to test though but should be straight forward. Same question really regarding the CIAs. And I am sure there is someone with inner detailed knowledge who could answer this straight out.

Nevertheless, SEI/CLI your shit or I will break into your house and take a "huge" crap at your can and leave it for you guys and torment your dreams ever after. I mean HUGE crap, not the spiral peewee ones, no a god dam rhino size pile of stinking CRAP!


DO YOU HEAR ME????
2017-11-13 15:49
TWW

Registered: Jul 2009
Posts: 541
Ok, that was perhaps a bit much... sorry... lolz
2017-11-13 16:16
Krill

Registered: Apr 2002
Posts: 2804
Quoting spider-j
No need for $d019 in this case, is that correct?
If you scroll up a bit to some of MagerValps comments:
Quoting MagerValp
Clearing pending IRQs with $d019 is not strictly necessary if you run from a freshly reset machine (the kernal writes $0f to $d019 on reset), but if something else ran before and exited to the basic prompt there may be an unacknowledged raster IRQ pending. [...] Hmm, I wonder if the soft reset before the ready prompt clears it... Just checked, and afaict, nope. [...] Clearing $d019 is necessary, and testing a bit more it seems like it's necessary even on a freshly reset machine.
2017-11-13 17:59
spider-j

Registered: Oct 2004
Posts: 443
Quoting Krill
If you scroll up a bit to some of MagerValps comments:

Ah okay, saw his code example also now. Didn't see that earlier. That probably happens when you're half-assed reading csdb threads while working... Thx.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - 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
Andy/AEG
Laurent
Sixx
Klegg/Fairlight
skull
Guests online: 327
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 Webmasters
1 Slaygon  (9.7)
2 Perff  (9.6)
3 Morpheus  (9.5)
4 Sabbi  (9.5)
5 CreaMD  (9.1)

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