Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Shortest code for stable raster timer setup
2020-01-20 16:20
Krill

Registered: Apr 2002
Posts: 2839
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 setup
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.

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....
 
2020-12-16 15:54
Copyfault

Registered: Dec 2001
Posts: 466
Quoting ChristopherJam
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
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.
2020-12-16 17:46
Rastah Bar

Registered: Oct 2012
Posts: 336
Quote: read the whole thread again any by scientific measures you all turned out pretty insane.

BS
2020-12-16 18:25
Rastah Bar

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!
2020-12-16 19:16
Frantic

Registered: Mar 2003
Posts: 1627
Zero bytes routine... Sounds like a world's first to me. :)

(And, yes, this thread obviously continued way past its end station.)
2020-12-16 22:13
Copyfault

Registered: Dec 2001
Posts: 466
The 13-cycle-loop won't work :((( The additional W-Cycles do not cancel out every possible cyclicity in the corresponding graph.

Talking in terms of cycles, we have the following:
sha ($d0),y ; RRRRSW
brk         ; RRWWWRR
The cycles are denoted as usual, with "S" being the special cycle that must land on cycle #12 of a badline (starting the rastercycle-count of a line with 1).

Now a 13-cycle-loop that is spread amoing 461 cycles (from badline to badline) gives a mod(-,13)-operator. Since mod(461,13)=6, we're actually adding 6 to the relative cycle position in our loop when getting from one badline to the next and look at a fixed cycle in the line.

The mod-operator also uniquely numbers the cycles of the loop, i.e. the first R-cycle of the SHA is cycle=0, the second R-cycle is cycle=1, etc. and the last R-cycle of the BRK is cycle=12. Now if we e.g. fix cycle #11 (the one before the first DMA-overtake-cycle) and have loop-cycle#11 at this spot, the +6-operation will lead to loop-cycle=11+6=17=4(mod13), i.e. the "S"-cycle will be at cycle#11 of the next badline. But here the drama happens: the cycle following this "S"-cycle is a W-cycle, thus executed since W-cycles can be executed on DMA-overtake-cycles. So the cycle-loop-count increases by one, and in the next badline at cycle#11 we will meet loop-cycle=5+6=11. This is the cycle we started with, so we're in an endless loop :(

Can this be broken by the no. of cycles on the upper/lower border? Or can we circumvent the trouble by using ROM-vectors ($0314ff)? This would give us a 41/42-cycle-loop, since (at least afair) there's an LDA $0104,X in the ROM-IRQ-routine, with X=SP, so this may lead to a varying no. of cycles if a pb is happening...
2020-12-17 00:16
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.
2020-12-17 00:27
Krill

Registered: Apr 2002
Posts: 2839
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... =)
2020-12-17 00:34
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 ;)
2020-12-17 00:37
Krill

Registered: Apr 2002
Posts: 2839
Quoting Copyfault
Quoting 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! =)
2020-12-17 02:48
ChristopherJam

Registered: Aug 2004
Posts: 1378
Quoting Copyfault
The 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!
Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
rexbeng
Apollyon/ALD
mutetus/Ald ^ Ons
Paul Bearer
Mike
Matt
Oswald/Resource
Guests online: 85
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Bromance  (9.6)
10 Memento Mori  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.