| |
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....
|
| |
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 |
| Previous - 1 | 2 | 3 - Next |
