| |
mehowte
Account closed
Registered: Jun 2014
Posts: 3 |
Free online presentation about Stabilizing Raster Interrupts!
Hi, some of you might find it interesting :)
https://64bites.com/webinar
I'm doing a free online presentation tomorrow evening (14th Feb) about programming Commodore 64.
Specifically about Raster IRQ Stabilisation - the most important technique used in most demos.
Bonus: Q&A about programming & KickAssembler source code for both PAL & NTSC
I'll be covering two-interrupt routine it will be beginner-friendly talk.
If you are a hard-core coder it might be boring for you ;) |
|
... 19 posts hidden. Click here to view all posts....
|
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quote: Quoting ZiriasTherefore, the maximum possible jitter is 10-2 = 8 cycles. Unless you have a raster IRQ on line 0. :) Cycles to get into IRQ routine
AFAIK, the VIC signals IRQ just one cycle later in line 0, but this doesn't change the jitter -- earliest possible reaction will be in cycle #3 and latest possible reaction in cycle #11, which (again) comes to a jitter of 8 ... (and, if you add the cycles for starting the ISR (7), it's earliest #10 and latest #18) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
In a worst-case scenario, you'd have interrupts on different raster lines, including 0, but not limited to it. Ultimately it comes down to handling all possible timer values for correct compensation to always end up at the same cycle, and preferably with the same routine.
So, unless i'm mistaken, there are 10 different possible timer values in the worst case, which is a jitter of 9 cycles. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"The explanation that the CPU has to finish the *next* instruction when an interrupt occurs at the last cycle of the current instruction"
I never heard of this behaviour, but cant we just think the interrupt occured when the flag was set and be done with it ? It doesnt change anything I guess. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting KrillSo, unless i'm mistaken, there are 10 different possible timer values in the worst case, which is a jitter of 9 cycles.
If the goal is to compensate jitter with the same routine for raster line #0 and any other raster line, this is of course correct :) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting OswaldI never heard of this behaviour, but cant we just think the interrupt occured when the flag was set and be done with it ? It doesnt change anything I guess.
Well, if you want to *calculate* where to put your NOP-slide and your comparing of $d012 (when using the double-IRQ method to stabilize), this *is* important. Of course, you can also achieve correct timing by trial-and-error ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Quoting OswaldI never heard of this behaviour, but cant we just think the interrupt occured when the flag was set and be done with it ? It doesnt change anything I guess.
Well, if you want to *calculate* where to put your NOP-slide and your comparing of $d012 (when using the double-IRQ method to stabilize), this *is* important. Of course, you can also achieve correct timing by trial-and-error ;)
yeah if I'd know where irq is triggered :) in practice I guess just simple to use some visual cues and get it done in a few minutes. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting Zirias[...]
An interesting question in this context is: what's the maximum possible jitter for a VIC-II raster IRQ? To answer this, one has to know that branch instructions are special. They take 2 cycles when the branch isn't taken, but 3 cycles when it is. The catch is: the internal flag for IRQ is always checked during the second cycle, even if there follows a third one. You could maybe call that one a "design flaw". So, if the VIC-II signals an IRQ during the second cycle of a branch, it is missed, because the internal flag is only set in the following cycle. If the branch is taken, this makes for a waiting time of 2 cycles plus the whole duration of the following instruction. The maximum duration of any documented opcode is 7 cycles. BUT there are unintended opcodes that take 8 cycles. So, in the worst case, a branch that is taken is followed by an 8-cycle instruction -> the total wait time until the IRQ is serviced is 10 cycles.
In the "best" case, the IRQ is signaled two cycles before the end of a "normal" instruction. The internal flag will be set during the last cycle, the instruction will check it and the IRQ is serviced directly after that instruction. Therefore, the maximum possible jitter is 10-2 = 8 cycles. It feels really good to read these lines :) Gives me a feeling that this ~15yrs old the discussion Stable Raster via Timer was not completely in vain... (and Krill already pointed to the follow-up-discussion \o/) Let's see if there'll be another "follow-up" in about twelve years 8|
But back ontopic: wonder for what kind of target audience this "webinar" was supposed to be. Missed the beginning (in which there was some "real" content as Henne told me afterwards -> thx Henne;)) but this seemed to be more some kind of live advertising than anything else.
As the talker (mehowte) did not answer to those "Did you already do a demo"-questions during the Q&A-session me wonders how he's involved in the C64 scene. Not that I'm hyperactive atm, just asking;) |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
You guys are hijacking the talkers monetization thread with tech talk - that's surely not funny! Pls behave.
Then again - what compyx said ... :(
Are all episodes accompanied by the same speaker btw? Just so I know before spending on all the BASIC talks. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
It is a very sad day for the community when somebody tries to sell such a poor content (poorly prepared as well judging on material available on YT) for such amount.
Advertising such product on site like csdb isn't a great idea either.
And I love the argument that we don't have a time due to other duties to read 20+ years old books ;) Now I know I've lost forever those 10 minutes of my life watching this. Thanks for nothing ;) |
| |
Slajerek
Registered: May 2015
Posts: 63 |
I'm sure you are not the target guys :)
I would say it is targeted to a newbie coders who may understand a bit of assembly, but the rest is magic for them and are not sure how things are done. I know some people who enjoyed this. Of course, it is understandable that for you old masters of C64 programming this might be boring :D anyway, I would rather be happy that such events take place, although I agree some of the things might be a bit messed up (and it seems that can be fixed), the main outcome looks OK for new C64 coders... I think. |
| Previous - 1 | 2 | 3 - Next |
