| |
Krill
Registered: Apr 2002
Posts: 2855 |
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: 2855 |
Thanks! =) But i'm not quite satisfied with this approach yet.
I've just realised that the overall number of cycles in a frame is still 312 * 63 (otherwise the timer would drift, which it doesn't). There might be something with testing $d012 on two or more lines. Possibly with more than 14 bytes of code, though. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
13 bytes, still long wait. =)initstabilise ldx #11
lda $d012
- dex ; (11 * 5) + 4
bpl - ; 59
eor $d012 ; 4 = 63
bne initstabilise; 9 = 72 |
| |
Frantic
Registered: Mar 2003
Posts: 1633 |
In an actual 4K context, I guess this should be pretty minimal, since I guess you would remove the x register delay counting stuff and replace it with some other unrelated init code that you would have to execute anyway (and that wouldn't break things even if it was executed a number of times). |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"The 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."
basicly its not 0 jitter, just then you know how the raster and the cpu is synchronized :P cool idea! dont think anyone ever coded this for size, guess you could make it run faster if you would do this on the border on consecutive lines. bne would jump out from a loop. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Frantic: True that. =)
But i wasn't so happy with the possible long wait of about one second.
Here's a fast version with 15 bytes:initstabilise ldx #10
lda $d012
lsr ; 2
rol ; 2
- dex ; (10 * 5) + 4
bpl - ; 54
cmp $d012 ; 4 = 62
bne initstabilise; 9 = 71This only considers even-numbered raster lines, so the problematic last line 311 won't terminate the loop.
Note that when replacing the X register delay stuff with some code of the same cycle count, the loop must still have 71 cycles, that is, a number of cycles that is co-prime with 63. Otherwise, not all cycles in a raster line may be reached and the loop spin endlessly. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting Oswaldbasicly its not 0 jitter, just then you know how the raster and the cpu is synchronized :P I meant that the loop always comes out at the same cycle on a raster line, with no jitter. =)
Quoting Oswaldguess you could make it run faster if you would do this on the border on consecutive lines. bne would jump out from a loop. One must avoid the 64-cycles line, because this would in fact produce a 1-cycle jitter with a 63-cycles check. But i think i've got this, now. :D |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Ah, bummer. This is the correct one with even-numbered lines only. =)initstabilise ldx #10
lda $d012
lsr ; 2
asl ; 2
- dex ; (10 * 5) + 4
bpl - ; 54
cmp $d012 ; 4 = 62
bne initstabilise; 9 = 71 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
13 bytes, at most a frame.
But, only works 99.9% of the time (fails to trigger DMA if it starts during line $ee), and puts about 3 and a half lines of black at the bottom of the screen for a frame.
ldx#$ee
: cpx $d012
bne :-
: dex
bmi :-
stx $d011
|
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Hah, that's pretty dirty. :)
I briefly considered DMA-based methods, but yeah, they usually come with visual artefacts or VSP hazards and the like.
One could argue that- nop
lda $d012
lsr
asl
[54 cycles worth of user code not touching the accu]
cmp $d012
bne - with 11 bytes net size as proposed by Frantic is shorter, though. =D |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
Haha well if we can pad with other code, just put something else that doesn't touch X in place of dex:bmi *-1, and we're down to 10 bytes :)
But yes, I'm not that keen on visible artefacts even for a frame. Easier to do a DMA on line $30 at the start of a blanked frame, and put all the init code somewhere that'll be overwritten by decrunched graphics or mainloop code. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
