| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Oh this is great.
May I suggest replacing the RTS with a BRK? Then you only need a single vector pointing at the routine start, instead of all of stack :) 13 cycle works I think; it divides cycles per frame but not cycles per character row.
(edit - assuming no issues with cycle stealing from all the stack writes for the BRK, of course. I've not tested this) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
read the whole thread again any by scientific measures you all turned out pretty insane. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Groepazread the whole thread again any by scientific measures you all turned out pretty insane.
Well, I can't really argue with that.
I can suggest replacing the BRK (or rather the contents of A) with the opcode of the next instruction in the init routine. Place the SHA in $ffxx, and it will zero out whatever is written until the time is right. Just saved another byte \o/ |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting ChristopherJamOh this is great.
May I suggest replacing the RTS with a BRK? Then you only need a single vector pointing at the routine start, instead of all of stack :) 13 cycle works I think; it divides cycles per frame but not cycles per character row.
(edit - assuming no issues with cycle stealing from all the stack writes for the BRK, of course. I've not tested this) I also had this idea to do it with a BRK instead of RTS (I mean: when there's some ANDing in play, a $00-byte for the "continue-loop"-case feels tempting;)), but afaiu post#61 by Quiss, 13 cycles does not work. So I guess the complete stack would've to be "configured adequately" :)
Quoting Groepazread the whole thread again any by scientific measures you all turned out pretty insane. Well, don't have a good argument against this - but insanity is the obvious state when stepping beyond science ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting ChristopherJam[...]
(edit - assuming no issues with cycle stealing from all the stack writes for the BRK, of course. I've not tested this) Oh wait... Quiss' calculation for the loop-length was based on R-cycle only... so the BRK *will* change it. Need to fiddle out the permitted loop-lengths under this new precondition - maybe it works... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I do hope it works. Because then we can use the entire SHA instruction and its opcode as the address operand of a preceding instruction (eg placing the zp pointer at an address that doubles as the high byte of an IO address), then the entire routine can vanish altogether. Zero bytes :D :D |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting ChristopherJamI do hope it works. Because then we can use the entire SHA instruction and its opcode as the address operand of a preceding instruction (eg placing the zp pointer at an address that doubles as the high byte of an IO address), then the entire routine can vanish altogether. Zero bytes :D :D Oh, where are we now??? Insanity^infty /o\\ But ok, splendig idea to make SHA (vec),y an operand of a preceeding opcode, like STA $d093,y :)) First thought it'd rather be a 1-byte-solution due to the opcode following that STA $d093,y, but the sync-loop exits always when the full value was written, thus also this byte is completely free to choose. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quote: read the whole thread again any by scientific measures you all turned out pretty insane.
BS |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quote: I do hope it works. Because then we can use the entire SHA instruction and its opcode as the address operand of a preceding instruction (eg placing the zp pointer at an address that doubles as the high byte of an IO address), then the entire routine can vanish altogether. Zero bytes :D :D
Fantastic! |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Zero bytes routine... Sounds like a world's first to me. :)
(And, yes, this thread obviously continued way past its end station.) |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 - Next |
