| |
Krill
Registered: Apr 2002
Posts: 3098 |
Stable raster with just polling for VBL ($D011)
I'm on another platform again and find myself needing to set some video registers with cycle-exact accuracy.
Now, there's only a bit to poll that flags a new video frame - no $D012 equivalent to check for current raster line.
Question is how to set up a stable raster timer for a clock-slide in a nice way.
The naive method, of course, being to wait for VBL in a polling loop, with a jitter of 7 cycles, then delay a frame's worth of cycles minus a few cycles, check VBL flag, add or subtract a few cycles around the video frame delay, check for VBL again, etc., and get the variance down to 0 cycles after about 4 or 5 frames.
Are there more elegant methods? |
|
... 5 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting chatGPZIf you have an irq too, maybe some variation of double-interrupt can work within one (or two?) frames? Hmm, that's a nice idea. Only need to determine a proper point to JMP (3 cycles) back on the NOP desert. |
| |
Jetboy
Registered: Jul 2006
Posts: 363 |
Looking forward to see what you are cooking. Sorry, no more ideas than already mentioned. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting JetboyLooking forward to see what you are cooking. Thanks! :) Come to Deadline! (Hope we'll make it in time.) |
| |
tlr
Registered: Sep 2003
Posts: 1814 |
Quote: Quoting chatGPZIf you have an irq too, maybe some variation of double-interrupt can work within one (or two?) frames? Hmm, that's a nice idea. Only need to determine a proper point to JMP (3 cycles) back on the NOP desert.
It's a great idea actually! As for the nop's you could just use a timer to busy wait until a few cycles before the next vb, and then do the nop's. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting tlrAs for the nop's you could just use a timer to busy wait until a few cycles before the next vb, and then do the nop's. Sure, but there's little difference in outcome, both in time and code size.
And you'd need to know the frame length (not difficult, but still) and not just the length of a rasterline.
(Both are very freely adjustable on that platform, so things like slightly lowering the frame rate are possible - if your effect almost but not quite updates in a single standard 50-Hz-ish frame. :D) |
| |
Slammer
Registered: Feb 2004
Posts: 449 |
I'm curious as to how it is used. As it takes frames to do the stabilizing, Perhaps you just do it once and then make sure the timing is constant the rest of the time? (If so, then the simpler stabilizer code the better - doesn't matter if you do it in a couple of frames less if the code gets unecesary complex.) |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 114 |
Never did anything for the PET, but my guess is to make it stable once and then setup a timer for a whole frame or a smaller part like a "raster" line and use the common known routines to make it stable. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting Krillset up a stable raster timer for a clock-slide So yeah, only setting up a timer once at init-time, then use it whenever you need to get to a specific beam X position. That part is just like on C-64. |
| |
tlr
Registered: Sep 2003
Posts: 1814 |
Quote: Quoting tlrAs for the nop's you could just use a timer to busy wait until a few cycles before the next vb, and then do the nop's. Sure, but there's little difference in outcome, both in time and code size.
And you'd need to know the frame length (not difficult, but still) and not just the length of a rasterline.
(Both are very freely adjustable on that platform, so things like slightly lowering the frame rate are possible - if your effect almost but not quite updates in a single standard 50-Hz-ish frame. :D)
good point, but you could quite easily measure the frame time for one frame, then do the sync the next frame. Then you don't need to calculate anything to know how many cycles a frame or line is. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting tlrgood point, but you could quite easily measure the frame time for one frame, then do the sync the next frame. Then you don't need to calculate anything to know how many cycles a frame or line is. Needless overhead. :) Line length in cycles is a direct register setting, known pretty much by definition. Frame length... is complex and must be measured or computed, yeah... but for no noteworthy gain in this case.
Edit... hmm... but then the double-irq method pretty much demands knowing exact frame length. But either way, no real difference, i guess. |
| Previous - 1 | 2 - Next |
