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: 2980
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-11 04:09
ChristopherJam

Registered: Aug 2004
Posts: 1409
Quoting Krill
Since the succeeding opcode is merely fetched, and not executed, then the pipeline flushed and the interrupt handled, then the opcode re-fetched and finally executed...
I can only imagine some arcane anti-cracking/debugging/reverse-engineering setup there, nothing demo-worthy.


Yes, you'd have to be running code stored in read-sensitive IO registers, at the precise cycle an IRQ is expected. I find it hard to imagine any kind of scenario where that would save you any cycles or memory.
2017-11-11 06:59
Oswald

Registered: Apr 2002
Posts: 5094
Quote: Quoting TWW
Morale of the story is:

SEI/CLI your init.


You appear to have forgotten the word "don't"

Just use MagerValp's routine from comment 26, and you'll be fine. SEI/CLI does nothing but create a problem that requires additional handling.


good luck with that when an irq midst your interrupt setup interferes with your initialization.
2017-11-11 07:09
lft

Registered: Jul 2007
Posts: 369
The only interrupt source that is enabled at program start is CIA1. And we disable all CIA1 interrupts. So where would the interference come from again?
2017-11-11 07:58
Oswald

Registered: Apr 2002
Posts: 5094
Quote: The only interrupt source that is enabled at program start is CIA1. And we disable all CIA1 interrupts. So where would the interference come from again?

assumption is the root of all bugs. if you change enviroment you're facing hrs of debugging until you find the faulty non sei/cli irq setup, that relies on having the system in a known state.
2017-11-11 08:38
Oswald

Registered: Apr 2002
Posts: 5094
anyhow I realise this is a religious argument, everyone should just do it as he likes. doesnt really matter.
2017-11-11 09:48
ChristopherJam

Registered: Aug 2004
Posts: 1409
Oswald, if there's a source you don't know about to disable, you're going to have bugs regardless of whether you SEI/CLI or not, as it's going to hit while your code isn't expecting it.

And if you do know about it, you can disable it, in which case an SEI before you disable it will create extra work for you, or an SEI after you disable it will do nothing.

Either way all you are doing is adding extra bytes to your init code with zero improvements to reliability.

It may even cause your raster interrupt to have it's first occurrence on the wrong line altogether, which can occasionally produce a frame of garbage at the start of your routine.
2017-11-11 10:28
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:
Yes, you'd have to be running code stored in read-sensitive IO registers, at the precise cycle an IRQ is expected. I find it hard to imagine any kind of scenario where that would save you any cycles or memory.

it could be a fun riddle for obfuscation though :)
2017-11-11 10:40
ChristopherJam

Registered: Aug 2004
Posts: 1409
(actually scratch that "it may even" para from the end of my last comment, I didn't quite think that one through - if a CIA interrupt goes off during setup unacknowledged, the consequences are going be considerably worse than a single frame...)
2017-11-11 10:45
Krill

Registered: Apr 2002
Posts: 2980
Quoting Oswald
this is a religious argument
This may be an academic discussion (unless you need the size, 4K and all), but it's certainly nothing to do with religion. Well, unless you are a cargo cultist. :)
2017-11-11 10:56
Oswald

Registered: Apr 2002
Posts: 5094
"Either way all you are doing is adding extra bytes to your init code with zero improvements to reliability."

An IRQ may destroy A while you try to lda #$7f sta $dc0d. another irq from the other CIA may re-enable $dc0d. You may have interrupt sources from VICII too, fucking you up in all sorts of ways. (rewriting fffe/f after you've set them up for example).

"if there's a source you don't know about to disable, you're going to have bugs regardless of whether you SEI/CLI or not, as it's going to hit while your code isn't expecting it."

you may just forget about your super size effective irq setup and it will backfire when you least expect it.
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
csabanw
Metal Maniac/Dual Crew
Dan
MWR/Visdom
El Jefe/Slackers^sidD
E$G/HF ⭐ 7
Brataccas/HF
Morpheus/IPC+C64.COM
Icon/TRIAD
Guests online: 125
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

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