Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Free online presentation about Stabilizing Raster Interrupts!
2019-02-14 12:25
mehowte

Registered: Jun 2014
Posts: 2
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....
 
2019-02-16 13:44
Zirias

Registered: Jan 2014
Posts: 36
Quote: Quoting Zirias
Therefore, 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)
2019-02-16 13:55
Krill

Registered: Apr 2002
Posts: 1159
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.
2019-02-16 13:58
Oswald

Registered: Apr 2002
Posts: 4371
"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.
2019-02-16 14:02
Zirias

Registered: Jan 2014
Posts: 36
Quoting Krill
So, 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 :)
2019-02-16 14:05
Zirias

Registered: Jan 2014
Posts: 36
Quoting Oswald
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.

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 ;)
2019-02-16 17:40
Oswald

Registered: Apr 2002
Posts: 4371
Quote: Quoting Oswald
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.

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.
2019-02-17 17:32
Copyfault

Registered: Dec 2001
Posts: 252
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;)
2019-02-18 09:07
Count Zero

Registered: Jan 2003
Posts: 873
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.
2019-02-18 20:45
AlexC

Registered: Jan 2008
Posts: 256
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 ;)
2019-02-19 12:08
Slajerek

Registered: May 2015
Posts: 33
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
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
hedning/G★P
Dymo/G★P
morphfrog
Pushead/Hokuto Force
bugjam
Medicus
CA$H/TRiAD
Gargaj/Conspiracy
Flavioweb/🇮🇹ASR/HF🇮🇹..
Deev/Onslaught
Guests online: 57
Top Demos
1 Uncensored  (9.7)
2 Unboxed  (9.7)
3 Edge of Disgrace  (9.7)
4 Coma Light 13  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 The Shores of Reflec..  (9.6)
8 X Marks the Spot  (9.5)
9 Old Men in Used Cars  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Bad Boy  (9.7)
2 Smile to the Sky  (9.6)
3 Daah, Those Acid Pil..  (9.5)
4 Dawnfall V1.1  (9.4)
5 FMX Music Demo  (9.4)
6 Rewind  (9.4)
7 Crystal Gazer  (9.4)
8 Official X2018 Report  (9.4)
9 Arok 20 Invitation  (9.4)
10 Pandemoniac Part 2 o..  (9.4)
Top Groups
1 PriorArt  (9.7)
2 Oxyron  (9.5)
3 Booze Design  (9.4)
4 Censor Design  (9.3)
5 Performers  (9.3)
Top Diskmag Editors
1 Newscopy  (9.4)
2 Jazzcat  (9.4)
3 A Life in Hell  (9.2)
4 Remix  (9.2)
5 Peter  (9.1)

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