| |
Krill
Registered: Apr 2002
Posts: 2845 |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
A 12-cycle-loop works, even when we have the three W-cycles of the BRK in the game. So one could argue that the following is kinda 0-byte-ish:
$ffd0 sta $d09e,y
$ffd3 isb $d000,x
$ffd6 brk
BRK-vector points to $ffd1, so the "loop-view" of the code is
$ffd0 .byte $99
$ffd1 shx $ffd0,y
$ffd4 brk
$ffd5 bne $ffd7
This offers several ways to end the loop; choosing X s.t. some store-opcode is put to $ffd4 when SHX hits the correct cycle gives an access to zp-adress $d0, but ideally, the ISB has already done a good job, thus also one of the NOP-opcodes like $1a at $ffd4 followed by the BNE can be ok. |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
I've been following this thread somewhat out of base personal interest... but so far, Quiss' original approach in https://csdb.dk/forums/?roomid=11&topicid=140414#143496 seems the most feasible for real-world purposes, imho.
Now, if the magic code could reside somewhere at $08xx... =) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Krill[...]
Now, if the magic code could reside somewhere at $08xx... =) Well, it can, see f.e. post#76 ;) |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting CopyfaultQuoting Krill[...]
Now, if the magic code could reside somewhere at $08xx... =) Well, it can, see f.e. post#76 ;) Oh okay, sorry, seem to have missed that!
So same assertion with https://csdb.dk/forums/?roomid=11&topicid=140414#146475 instead!
8 bytes, excellent! =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting 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! |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
It may still work, because the border can get it out of such an endless loop, but this should be checked. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting CopyfaultQuoting Krill[...]
Now, if the magic code could reside somewhere at $08xx... =) Well, it can, see f.e. post#76 ;) Oh okay, sorry, seem to have missed that!
So same assertion with https://csdb.dk/forums/?roomid=11&topicid=140414#146475 instead!
8 bytes, excellent! =)
this post link doesnt work when csdb is also set to display only a set nr of posts from a topic. |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting Oswaldthis post link doesnt work when csdb is also set to display only a set nr of posts from a topic. I think that's a bug report and should go to another sub-forum, no? :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Krill, 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? |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
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. |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 - Next |
