| |
Krill
Registered: Apr 2002
Posts: 2980 |
Shortest code for stable raster timer setup
While working on my ICC 2019 4K entry (now postponed to ICC 2020, but i hope it'll be worth the wait), i came up with this (14 bytes):initstabilise lda $d012
ldx #10 ; 2
- dex ; (10 * 5) + 4
bpl - ; 54
nop ; 2
eor $d012 - $ff,x; 5 = 63
bne initstabilise; 7 = 70
[...]; timer setupThe idea is to loop until the same current raster line is read at the very beginning (first cycle) and at the very end (last cycle) of a raster line, implying 0 cycles jitter.
With 63 cycles per line on PAL, the delay between the reads must be 63 cycles (and not 62), reading $d012 at cycle 0 and cycle 63 of a video frame's last line (311), which is one cycle longer due to the vertical retrace.
The downside is that effectively only one line per video frame is attempted, so the loop may take a few frames to terminate, and the worst case is somewhere just beyond 1 second.
The upside is that it always comes out at the same X raster position AND raster line (0), plus it leaves with accu = 0 and X = $ff, which can be economically re-used for further init code.
Now, is there an even shorter approach, or at least a same-size solution without the possibly-long wait drawback? |
|
... 177 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Rastah BarKrill, what is your opininion on the timer-based approach of post#91? Is it too dangerous to rely on a timer when loading the next part of a demo? Timers are not used by loaders usually, then there is no hazard for loading itself. Typical IRQ loaders load in a background thread, so they are interrupted themselves but don't interrupt other threads.
Some IRQ loaders exist which use timer or raster IRQs to periodically receive data from the drive, and it seems like that could disturb your approach, as it does not seem to like being interrupted.
Depending on how long a loader is not "scheduled" due to a long-running critical section, it could be starved and trigger a drive-side watchdog IRQ to reset the drive due to protocol violation. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Thanks for your detailed answer. None of the methods in this thread likes to be interrupted, but that is easy to guarantee since the routines only have to run once.
I phrased my question a bit clumsily, though. What I meant was: suppose you want to use the timer-based syncing routine not directly after the start from basic, but later, for some other part of a demo. Is there some risk in relying on $dc04? I suspect not, since the coder should know the state of the timers, but I don't know if there are some cases where you can't be sure of the state of the timers, because f.e. a loader has used it. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Rastah BarWhat I meant was: suppose you want to use the timer-based syncing routine not directly after the start from basic, but later, for some other part of a demo. Is there some risk in relying on $dc04? I suspect not, since the coder should know the state of the timers, but I don't know if there are some cases where you can't be sure of the state of the timers, because f.e. a loader has used it. I have understood your question exactly like this. Is there anything unclear in my answer? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
relying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting ChristopherJamQuoting CopyfaultThe 13-cycle-loop won't work :(((
Aww, that's a shame.
Kind of ironic to be derailed by W accesses, given the number of earlier approaches that relied on cycling stealing to work at all.
Thanks for doing the analysis! Had to be done;) And I kinda like rastercycle-joggling... really sad it did not "pay off". |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quote: Quoting Rastah BarWhat I meant was: suppose you want to use the timer-based syncing routine not directly after the start from basic, but later, for some other part of a demo. Is there some risk in relying on $dc04? I suspect not, since the coder should know the state of the timers, but I don't know if there are some cases where you can't be sure of the state of the timers, because f.e. a loader has used it. I have understood your question exactly like this. Is there anything unclear in my answer? :)
No, except that I did not see an argument against the timer-based approach that does not hold for the other approaches, but Groepaz' answer does. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quote: relying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does.
Thanks! Yes, that is a strong argument against it. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepazrelying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does. Cartridge and KERNAL stuff do not play much of a role in demos, so it's not unusual to have timers for IRQ jitter compensation run during the entire multi-side demo without re-initialisation.
It's different for games, of course, but there you rarely need stable interrupts.
But then both multiload demos and games do not have much of a space issue, so just re-initialise timers at strategic/natural points and be done with it. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting Rastah BarIt may still work, because the border can get it out of such an endless loop, but this should be checked. Hmm, at least my counter example from post#132 seems to get fixed: if we have loop-cycle#4 at cycle#11 of the last rasterline in one frame, we will get to loop-cycle
change | loop-cycle
starting situation | 4
W-cycle following "S" | +1 = 5
cycles to bl in next fr | +3 = 8
W-cycles of BRK | +2 = 10
cycle to next bl | +6 = 16 = 3
so the next loop-cycle (which is the S-cycle) hits raster-cycle #12 and the loop ends.
Similarly, when starting with loop-cycle#11:
change | loop-cycle
starting situation | 11
cycles to bl in next fr | +3 = 14 = 1
cycle to next bl | +6 = 7
W-cycles of BRK | +3 = 10
cycle to next bl | +6 = 16 = 3
Now we have to check all starting situations, since the routine might start at a last badline of a frame. But I'm warily optimistic ;) |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
I checked all starting situations and if I did not make a mistake, the loop always ends!
The next exercise is to check this for C64 models other than PAL. |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 - Next |
