| |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Ah, ok, looking from that meta-level I agree of course. The only case that causes trouble is A&X=2, everthing else will work. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CopyfaultQuoting QuissNeat! Right, no reason to make those two address bytes go to waste. :)
Another amusing thing to contemplate is how this code could be placed at, say, $08xx. Preferably without messing up the basic upstart.
[...] Not necessarily the shortest piece of code, but it satisfies your requirement to have the sync routine at $08xx:
0843 A2 9E LDX #$9E
0845 A0 08 LDY #$08
0847 E0 00 CPX #$00
0849 D0 F9 BNE $0844
Branching to $0844 leads to SHX $08A0,Y, so the operand byte of the CPX is altered continuously. As long as the "&(hi+1)" plays in, the compare operand will be =$08. When "&(hi+1)" disappears, the full $9E is written to the operand byte and the loop will end. This happens iff the critical SHX-cycle happens on a badline. Nice trolljob there! =)
Took me a while and Rastah Bar's successive comment to figure out that code must sit at $08A3 instead, and not at $0843.
Seems to work nicely now in real-world code on realthing and x64sc, while on x64 the code just twiddles thumbs in an endless loop. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: Quoting CopyfaultQuoting QuissNeat! Right, no reason to make those two address bytes go to waste. :)
Another amusing thing to contemplate is how this code could be placed at, say, $08xx. Preferably without messing up the basic upstart.
[...] Not necessarily the shortest piece of code, but it satisfies your requirement to have the sync routine at $08xx:
0843 A2 9E LDX #$9E
0845 A0 08 LDY #$08
0847 E0 00 CPX #$00
0849 D0 F9 BNE $0844
Branching to $0844 leads to SHX $08A0,Y, so the operand byte of the CPX is altered continuously. As long as the "&(hi+1)" plays in, the compare operand will be =$08. When "&(hi+1)" disappears, the full $9E is written to the operand byte and the loop will end. This happens iff the critical SHX-cycle happens on a badline. Nice trolljob there! =)
Took me a while and Rastah Bar's successive comment to figure out that code must sit at $08A3 instead, and not at $0843.
Seems to work nicely now in real-world code on realthing and x64sc, while on x64 the code just twiddles thumbs in an endless loop. =)
Oops, thought I corrected this in a later post, but it seems I forgot to.
However, other approaches have been discovered during the discussion that are comparable in size but more flexible regarding mem location.
So take my deep apologies... "trolljob" sounds really evil :(:(:(... and I really really did not intend to fool anyone.
Hopefully it won't happen again. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
No worries, i actually took it for a mistake.
Though i wonder how that could happen, did you drunkenly type in some notes scribbled on a napkin, mistaking an A for a 4? =) |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
So you're suggesting there was a fault in Copyfault's copy? |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting RaistlinSo you're suggesting there was a fault in Copyfault's copy? Yeah, must be the handle, obviously ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
0843 A2 9E LDX #$9E
0845 A0 08 LDY #$08
0847 E0 00 CPX #$00
0849 D0 F9 BNE $0844
could someone explain how this works ? :D |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Oswald0843 A2 9E LDX #$9E
0845 A0 08 LDY #$08
0847 E0 00 CPX #$00
0849 D0 F9 BNE $0844
could someone explain how this works ? :D Corrected version of the code and Copyfault's explanation annotated:
08A3 A2 9E LDX #$9E
08A5 A0 08 LDY #$08
08A7 E0 00 CPX #$00
08A9 D0 F9 BNE $08A4
Branching to $08A4 leads to SHX $08A0,Y with Y = 8, so the operand byte of the CPX #imm at $08A8 is altered continuously.
As long as the "&(hi+1)" plays in, the CPX #imm operand will be $9E & $09 = $08, which is not equal X = $9E, so branching back.
When "&(hi+1)" disappears, the full $9E is written to the CPX's operand byte and the loop will end (X = $9E with CPX #$9E will yield Z=1). This happens if and only if the critical SHX-cycle appears on a badline. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
why does the &hi disappear on a badline? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats what the opcode does - why exactly it happens is unknown, but its likely some analog effect |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 - Next |
