| |
Krill
Registered: Apr 2002
Posts: 2854 |
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....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1060 |
Quote: Quoting MagerValpFor reference, here's a bog standard raster IRQ setup that'll work every time if run from basic.
Â…and if you also zero $d01a at the start of the routine, it should then behave itself if your predecessor left a raster interrupt installed :)
You wouldn't even be able to load stuff from disk with a raster IRQ running, so I don't think it's necessary for account for that. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
You can load fine from disk using KERNAL routines, with a raster IRQ running. You just need to do it right. And it loads even slower, of course. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
64er mag had some example for this.... it was slooooooooooow =) |
| |
MagerValp
Registered: Dec 2001
Posts: 1060 |
It's also possible to press restore while running, and to use SD2IEC. If you set yourself up for failure, don't be surprised when you fail :) |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
Quote: Clearing $d019 is necessary, and testing a bit more it seems like it's necessary even on a freshly reset machine. SEI/CLI is still useless though, and only creates the problem of having to clear $dc0d.
relying on things that are not under your control is usually a bad idea. (machine is in an after reset state). this is much more of a cargo cult, than using SEI/CLI. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 501 |
After all, why bother about those few wasted bytes, where's the highly optimized demo parts? :-D How can this behaviour finally be misused? By having the upcoming instruction of the SEI on a register being read or not? |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
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. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Morale of the story is:
SEI/CLI your init. take care of unwanted IRG/NMI events from smegging up your shit. Let the byte optimizers optimize^^ |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Quoting TWWMorale 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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Quoting KrillSince 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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
