| |
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 ;) |
|
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Friday, 15 February 2019, at 8:00 PM
written on the site? |
| |
mehowte
Account closed
Registered: Jun 2014
Posts: 3 |
Don't know what you mean by that. It will be alive streamed presentation. |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
You said TOMORROW EVENING (14th feb) while 14th it's already today. On the site you linked you have written Friday, 15 February 2019, at 8:00 PM
Make up your mind. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Just pretend its friday already :) |
| |
Taskmaster
Account closed
Registered: Feb 2018
Posts: 22 |
Already on my calendar ... looking forward to it! :) |
| |
Smasher
Registered: Feb 2003
Posts: 520 |
why stable rasters? me loves ze flickering! <3 |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
nobody needs help to making flickering, they can all do it on the own merits. |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
Time zones, anyone? :D |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
What timezone is Zagreb, possibly +1 ? |
| |
Taskmaster
Account closed
Registered: Feb 2018
Posts: 22 |
https://64bites.com/webinar
The link has a countdown clock as well as a time zone converter. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
That was fucking terrible. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Sorry, was busy, anywhere I could watch the recording/rerun? |
| |
alwyz
Registered: Dec 2011
Posts: 32 |
Replay here
https://www.youtube.com/watch?time_continue=15&v=fn5JKNc-NfA |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Quote: That was fucking terrible.
I wouldn't say terrible but...
For beginners, explanations were complicated. For c64 coders like us, stable raster subject is a basic knowledge. I'm not sure who is the target audiance and whether they can benefit from this session.
Still, thank you for making a video on such a subject. Next time, please be more prepared. Presentation mistakes, not showing emulator on the screen and not noticing it etc are lowering the quality. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Well, it's a nice idea to explain this thing with a presentation. Still, I always have mixed feelings about simplifying things in explanations. Of course, it makes it easier to understand without prior knowledge, but it also often introduces things that are in fact wrong, just for the sake of simplification...
Having watched the first ~ 30 minutes, I have two remarks:
- An interrupt not being handled immediately (meaning: in the middle of an instruction) is NOT a CPU design flaw. In general, interrupts just do not need timing precision down to the cycle, they should just be serviced ASAP. Peripheral devices signal interrupts to let the CPU know they finished something and the CPU should react "some time soon". Designing a CPU that could interrupt in the middle of an instruction and properly resume later would need a lot more circuitry for no gain at all in general. Therefore, the design of the 6502 (or 6510) WRT handling interrupts is mostly sane.
- The explanation that the CPU has to finish the *next* instruction when an interrupt occurs at the last cycle of the current instruction is not entirely correct. It isn't wrong either, but it's one of these simplifications .... what really happens is the 6502/6510 has an internal flag for "IRQ requested" (same for NMI, but let's ignore that one here). In every cycle, the level of the IRQ line is checked during the second half of this cycle. If the level is "low" at that point of time, the internal flag will be set during the next CPU cycle. Instructions check that flag, normally during their last cycle. Because the VIC-II is in sync with CPU cycles (it creates the CPU clock after all), it will always start signalling an IRQ (by pulling the line low) at the start of a cycle. So, the CPU will notice this low level during the second half of this cycle, therefore the flag will be available only in the next cycle. As most instructions check the flag for IRQ during their last cycle, they will miss an IRQ signaled during that last cycle, because the flag isn't set yet. Of course, this has the effect described in the presentation.
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. |
| |
Knight Rider
Registered: Mar 2005
Posts: 131 |
I was fascinated by the suggestions about sticking his KNOB in at various and random places. Seems NOP and KNOB are nearly the same.
It went downhill after I realised I'd signed up for the hard sell timeshare / pyramid scheme. Thankfully, I could just close my browser, and was not driven to the ATM to force me to pay the $144 usd. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
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 |
| |
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. |
