basicly its not 0 jitter, just then you know how the raster and the cpu is synchronized :P

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.

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 :)

and put all the init code somewhere that'll be overwritten by decrunched graphics or mainloop code.

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.

Quoting Krill

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.

Funny, didn't know that. Does Vice emulate it? Hoxs doesn't.

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

Like the mathematician's hypothetical can opener, let us assume we have 50 cycles worth of init code that we are happy to run as many as seven times over.

Then we can sync with just ten bytes of code, in at most seven frames.

sync:
    lda $d012   ; will be zero on cycles 0,1,2,3,4,5 or 6
    bne sync

    .res 25,$ea ; replace this with 50 cycles of init code

    lsr $d012   ; if it's zero, either we're too early on line 0, or we're on line 256..  
    bcc sync    ; fall through if we read on cycle 62, 56 after cycle 6

We use lsr instead of lda for the second test, as lda would result in a 63 cycle loop.

[...]

sync:
    ldy #val
    lax $d012
    bne sync
    // here we are at cycle 3..9 of rasterline $00 (or 2..8 of rasterline $100)
    /*
    // 50 cycles of init code go here
    */
    // after that init code block we are @cycle 53..59 of rasterline $00(52..58 of line $100)
    lda $d012   // the R-cycle occurs @cycle 57..63 -> 63 = cycle 0 of line 1
                // in rasterline $100 this will end up @cycle 56..62, thus always without reaching the next line 
    beq sync    // branch not taken only when line 1 is reached

sync:
    inc $d012   ; result will be zero on cycles 0-7 or 8 of raster line $ff
    bne sync    ; (or very rarely, cycle 9..62)

    .res 27,$ea ; wait 62-8=54 cycles. Replace with 54 cycles of init code

    inc $d012   ; if result is nonzero then we are too late.
    bne sync    ; carry on if we read on cycle 62, 62 cycles after cycle 0

edit: this one probably also compresses better than the earlier versions - the two code snippets both start with EE 12 D0 D0

[...]
But back to your INC-based solution: why does it take 9 frames at most?[...]

I guess it can be easily fixed by blanking the screen in the init code. This is often required anyway when setting up the graphics, so this is not really a constraint.[...]

I can shave off one byte:

sync: lax $dc04
      sbx #51
      sta ZP      ;RMW instruction
      cpx $dc04
      bne sync:

The loop is 16 cycles and since 461 = 29*16 - 3, this also should always lock. It needs at most 20 consecutive badlines, so the very worst case is that the lower border is reached after 19 badlines and you have to start again at the first badline. So locking is guaranteed in less than 1.4 frames.

Quoting Rastah Bar

I guess it can be easily fixed by blanking the screen in the init code. This is often required anyway when setting up the graphics, so this is not really a constraint.[...]

Forgot to stress this detail, but I had this in mind: you even do not have to set it before the start of the stabilization loop (the first check of $d012 might be a "bad case" anyway), so it suffices to blank screen/kill irqs/etc in the init code blob.

This one looks quite clever, though I did not deep-check "all the math" behind it. One thing (besides the badline-timing) that might also cause a cycle-mismatch at the cpx $dc04-instruction is the behaviour of the timers: afair, it never reaches the $00-value, but gets initialized with the max-value (so $dc04 outputs the same value in two consequetive cycles, but never $00).
And as a sidenote: a STA ZP is just a write-instruction, no Read-Modify-Write (the RMW-comment in your code examples confused me a little;)). But the idea you posted with one write-cycle is correct and should work...

* = $0f00  ; Some address with (H+1)&1 = 0 and (H+1)&$10 = $10

       ldy #$00
loop:  ldx #$11
       shx cont, y
cont:  bpl loop

This is an idea I got after talking to Copyfault.
At least in the cycle-correct version of Vice (i.e., x64sc) this seems to work. Haven't tried on a real machine.

* = $0f00  ; Some address with (H+1)&1 = 0 and (H+1)&$10 = $10

       ldy #$00
loop:  ldx #$11
       shx cont, y
cont:  bpl loop

It uses the fact that we will AND the written value with H+1 unless a badline pauses the CPU between the third and fourth cycle of shx. The latter then changes the "bpl" into an "ora" and drops us out of the loop at horizontal position 61.

If you want to "overdo" (optimize, erm) this, let's save another 2 bytes:

* = $0faa  ; _a very nice_ address with (H+1)&1 = 0 and (H+1)&$10 = $10

0FAA   loop:  ldx #$11
0FAC          shx cont, y
0FAF   cont:  bpl loop

with start adress $0FAD (you guess the operand bytes of the SHX ; ))

with start adress $0FAD (you guess the operand bytes of the SHX ; ))

Quoting Copyfault

If you want to "overdo" (optimize, erm) this, let's save another 2 bytes:

* = $0faa  ; _a very nice_ address with (H+1)&1 = 0 and (H+1)&$10 = $10

0FAA   loop:  ldx #$11
0FAC          shx cont, y
0FAF   cont:  bpl loop

with start adress $0FAD (you guess the operand bytes of the SHX ; ))

with start adress $0FAD (you guess the operand bytes of the SHX ; ))

Interesting idea, but I do not completely understand it. How does the Y register get the right value?
[...]

[...]Another amusing thing to contemplate is how this code could be placed at, say, $08xx. Preferably without messing up the basic upstart.

Also, careful with the loop length. The number of CPU cycles between two badlines is 461, except when the loop's one write cycle (last cycle of SHX) sneaks into the three cycle RDY grace period. Then it's 462 ticks.
(Imagine a graph with n nodes, in which node i is connected to node (i+461)%n for 0 < i < n-1 and to (i+462)%n for i = 0. Node n-1 isn't connected to anything. You want that graph to be acyclic.)
In the range 5-20, the lengths that do work are 5, 10, 12, 16, 18 and 19. But note that in particular, length 8 (a.k.a. branching directly to the SHX) does not.

0FAA   loop:  ldx #$11
0FAC          shx cont, y
0FAF   cont:  bpl loop

with start adress $0FAD (you guess the operand bytes of the SHX ; ))

The SHX will be SHX $0fa0,y. Then you start this with a JMP $0fad which is just an LDY #$0f. This is also the reason for that code blob to begin at $0faa.

Yes, yes, it's so true! After I wrote this post, two things haunted me some hours later: 1. that branching to SHX is not possible when doing the SHX $0fa0,Y-trick, so it was confusing to start with it and writing that branch-idea after it
2. those 63 cycles do only apply for non-badlines, but your approach needs badlines badly (pun intended). So my calculation was wrong. Thanks for putting this right, with the corresponding cycle calculations included :)

Quoting Copyfault

The SHX will be SHX $0fa0,y. Then you start this with a JMP $0fad which is just an LDY #$0f. This is also the reason for that code blob to begin at $0faa.

Excellent! Thanks for the explanation. I had the same problem as Perplex. The code you posted gives LDA $100F.
[...]

461 is a prime number, so I don't understand the (a)cyclic graph explanation. Could someone explain it in a bit more depth, please?

So next task is to get his <7 bytes *ducks+runs*

I think though that the borders could make some of the other loop lengths work.

The border is 112*63 cycles = 7056 cycles.

So perhaps a loop, when it is stuck in a wrong loop on the visible screen, will be "shifted out" of that loop in the border.

This will happen for a loop length of 17, since 7056 = 415*17 + 1.

(Btw, with longer loop lengths there may be more W-cycles in the loop.)

The six byte example as shown does not work since it could get interrupted. An SEI should be executed first before jumping into the loop.

Neat! 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.
[...]

$08A3

Stupid question from a layman - where this stabilizing piece of code is supposed to go exactly to do its job and not crash the whole thing? :)

The code location can't be $183c, can't it? Also the SHX instruction behaves unpredictable when a page is crossed, so I'm afraid this one won't work.

Btw, maybe you could summarize all the known allowed code locations where any SHX or SHY variant could work?

Thanks! I should have looked at the latest version of the "No More Secrets" document.

[...]The (currently) shortest code that can be placed anywhere was proposed in post #44.

Quiss came up with a very bright idea in post #50 that uses the instabilities of the SHX instruction. It uses less RAM, but it has some restrictions on code location. Shorter variants were found, but they have much stronger location restrictions.

The STA $ZP instruction (see post #44) can be made part of the init code, which reduces the timer-based stabilization approach to effectively 10 bytes:

      ldy #init_value  ;Init code
sync: lax $dc04
      sbx #51
      sty ZP      ;RRW instruction. Part of init code.
      cpx $dc04
      bne sync:

STY ABS is also allowed, in combination with SBX #52.

If I'm not mistaken, this should work on PAL, NTSC, and DREAN, but the loop exit cycle may depend on the system.

      ldx #initval
      ldy #<(zp_pos+1)
loop: shx $ffff,y
      lda <($100 + zp_pos - initval),x
      beq loop

CJam's approach also takes 10 bytes, but maybe it requires blanking the screen? I'm not sure, but if it does, it is an extra constraint, since you do not always want that. For example, in a demo you can have some effect working on the startup screen, and then you don't want to blank it.

VIC always steals the same amount of cycles from the CPU on a badline. This is system independent.

Woah, this thread has been busy, nice work all :)

Um, no need to blank the screen for my bracketing method. There's never character DMA on line $0ff, which is the only one for which there are 63 cycles for which an INC $d012 will read $ff and write $00.

(assuming of course that I'm remembering correctly rumours that line $00 is only 62 cycles long - can anyone point me at documentation to confirm that? There's nothing in the venerable VIC Article [english], and I'm not spotting it anywhere on CodeBase either)

Btw, since the LDX #initval in Copyfault's method of post #90 is part of the init code, that one is only 9 bytes and hence the shortest unconstrained method.

I was just wondering of some W cycles within the init code might cause some kind of alignment on badlines, such that the first INC $d012 always appears on line $ff on a non-syncing cycle?

Btw, since the LDX #initval in Copyfault's method of post #90 is part of the init code, that one is only 9 bytes and hence the shortest unconstrained method.

btw - with the various routines that have an entry point inside the loop, I was originally thinking "wait, aren't you then spending more bytes to branch into the start point?" but then I remembered that this code is probably running post decrunch, and most crunchers will happily let you set whatever start point you want, and kill CIA for you to boot.

btw - with the various routines that have an entry point inside the loop, I was originally thinking "wait, aren't you then spending more bytes to branch into the start point?" but then I remembered that this code is probably running post decrunch, and most crunchers will happily let you set whatever start point you want, and kill CIA for you to boot.

Of course, if you're being this stingy with bytes there's a also fair chance you're *not* using an off the shelf decruncher...

I do not know exactly how crunchers tailored to 6502 code work, but what will turn out to be the shortest crunched routine, could depend on the code or data around it, is that correct?

Nice, but it would be quite a coincidence that you would need exactly these presettings in the rest of the intro or demo. Perhaps there are ZP adresses that normally (I mean, after a cold start), have the required values.

I know almost nothing about decrunchers, so I don't have a clue what they can do in terms of "initial conditions" of ZP-adresses or registers, etc.

If they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this:

shx $HH00,y
BYTE any_value
bne *-4

The code location and $HH should be such that X & {H+1} is the opcode for instructions like TXA, TYA, while X should contain the opcode for a 3-byte instruction.

So without DMA, the byte after the SHX instruction is replaced by e.g. TYA ensuring the branch is taken, and with DMA the loop exits with the 3-byte instruction whose opcode was in X. But this is stretching it really far!

Quoting Copyfault

Quoting Rastah Bar

If they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this:

shx $HH00,y
BYTE any_value
bne *-4

[...]

Yes this should work. But you're right, it's really shifting *a lot* of preparations to the reign of decruncher & init code. Still quite doable I think. Time to dig out the shortest-code-medal and polish it for the new owner;)

The code cannot be freely placed in memory, so you may keep that medal :-)[...]

Well, in large parts it's the same as what I proposed in post#86.

But now that we entered the territory of over-stretching, here a version that does it in only 5 bytes (again putting all required reg settings on the decruncher's bill) :

$fdfc  9E D0 FD   shx $fdd0,y
$fdff  D0 FC      bne $fdfd

Comes with all constraints one could think of: mem loc fixed, y=$2f fixed val mandatory, x=$d1 fixed val mandatory, setting of vector $fc/$fd has influence on the no. of cycle that are taken when the loop is left, to be started with z-flag=0, ... maybe more! Ok. it's possible to do it with any branch-opcode, but this doesn't really make it any better;)

Quoting Copyfault

Well, in large parts it's the same as what I proposed in post#86.

Yes, you are right. I lost track a bit of all the variants.
Quote:

But now that we entered the territory of over-stretching, here a version that does it in only 5 bytes (again putting all required reg settings on the decruncher's bill) :

$fdfc  9E D0 FD   shx $fdd0,y
$fdff  D0 FC      bne $fdfd

Comes with all constraints one could think of: mem loc fixed, y=$2f fixed val mandatory, x=$d1 fixed val mandatory, setting of vector $fc/$fd has influence on the no. of cycle that are taken when the loop is left, to be started with z-flag=0, ... maybe more! Ok. it's possible to do it with any branch-opcode, but this doesn't really make it any better;)

Very ingenious, but an 8-cycle loop doesn't work, doesn't it? See post #61.

Quoting Rastah Bar

Very ingenious, but an 8-cycle loop doesn't work, doesn't it? See post #61.

Quote:

It's actually a 12-cycle loop, cause the first branch is 4-cycles long (page-break!), the branch in the operand of the SHX takes 3 cycles and the SHX itself 5 -> 12 cycles in total;)

It could even be done with just 4 bytes (continuing the abuse of the byte-counting):

loop:  sha (vec),y
       bne loop

If this is located at the end of a page s.t. the BNE comes with a pb, it's a 10-cycle-loop in total.

Still, too far-fetched, too many things must be configured correctly. Personally, I think the 7-bytes-solution (as in post#110) that "only" comes with requirements on zp-values set in a special way is the best compromise between flexibility and byte-count!

Awesome! With SHA(vec),y even 3 bytes is possible for a 12-cycle loop. One example:

$5f00  SHA (VEC),y
$5f02  RTS

If we assume that the decruncher provides the following initial conditions: {A&X} = $EA (opcode of NOP), Y = 2, the ZP addresses VEC and VEC+1 point to $5F00 and the stack is completely filled with the return address $5F00. Without DMA the SHA writes $EA & {$5F+1} = $60 (opcode for RTS) and repeats that until a DMA makes it write an NOP.

read the whole thread again any by scientific measures you all turned out pretty insane.

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)

read the whole thread again any by scientific measures you all turned out pretty insane.

[...]
(edit - assuming no issues with cycle stealing from all the stack writes for the BRK, of course. I've not tested this)

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

[...]
Now, if the magic code could reside somewhere at $08xx... =)

Quoting Krill

[...]
Now, if the magic code could reside somewhere at $08xx... =)

Well, it can, see f.e. post#76 ;)

The 13-cycle-loop won't work :(((

this post link doesnt work when csdb is also set to display only a set nr of posts from a topic.

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?

What I meant was: suppose you want to use the timer-based syncing routine not directly after the start from basic, but later, for some other part of a demo. Is there some risk in relying on $dc04? I suspect not, since the coder should know the state of the timers, but I don't know if there are some cases where you can't be sure of the state of the timers, because f.e. a loader has used it.

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!

relying on anything being already initialized isnt really a good idea though. perhaps acceptable for something like a 4k - but for anything bigger i'd rather not do this. you can never know what some cartridge or kernal replacement does.

It may still work, because the border can get it out of such an endless loop, but this should be checked.

Cartridge and KERNAL stuff do not play much of a role in demos, so it's not unusual to have timers for IRQ jitter compensation run during the entire multi-side demo without re-initialisation.

I did assume that $dc04 goes through all 256 values.

The approach with the timer has some pitfalls but the idea behind it is really beautiful: to check if the timer has changed largely though the read-accesses to the timer-register are just a few cycles apart!

In some of my former posts I already wondered wether the timer underflow never misaligns the read values s.t. a badline might be detected while not being in one. And somehow it feels strange to use timers in a routine which aims to fix a raster cycle position s.t. a timer can be initialised in a stable way. Nontheless a valuable addition to the pool of (mostly insane) approaches :)

The default Kernal settings are such that a false positive cannot occur. But, as Groepaz pointed out, you can never know what some cartridge or kernal replacement does to the settings.

I checked all starting situations and if I did not make a mistake, the loop always ends!

The next exercise is to check this for C64 models other than PAL.

Quoting Copyfault

[...]Thanks for doing the analysis!

Had to be done;) And I kinda like rastercycle-joggling... really sad it did not "pay off".

Yes, you're both right, the BRK can be used as some data and the step from the beginning of the page to the adress where to continue can be chosen almost arbitrarily... but it imposes more (and weirder!!) restrictions on the choices for a and x;)

Quoting Copyfault

Yes, you're both right, the BRK can be used as some data and the step from the beginning of the page to the adress where to continue can be chosen almost arbitrarily... but it imposes more (and weirder!!) restrictions on the choices for a and x;)

Not more restrictions, you just have more choice.

Quoting Quiss

Neat! 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.

So you're suggesting there was a fault in Copyfault's copy?

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

why does the &hi disappear on a badline?

What an awful thread.. fell down the rabbit hole, turned utterly insane, lost several days of sleep...

Quiss' original approach is short and elegant, but opcode rewriting confuses my old brain.
Adding a single byte to it's size, the flexibility can be increased somewhat (from 64 to 112 possible pages) and no opcode rewrites, just operand rewrite.

	* = $xy00, where x=$0-$f and y=$0-$6
loop:	ldy	#$08
	ldx	#$0a
	shx	loop,y
	jmp	loop
$xx0A:

Loop times kept at either 10 or 12 cycles, depending on address choice.

As an added bonus, A is not touched - which may or may not matter in your overall timer setup.

So, it's obvious my priority is not size, but readability - and I find this approach a tad more readable ;-)

Still, I think the sniplet presented in post#90 (and all variants thereof) is best regarding trade-off between readability and size. And it imposes almost no restriction on the highbyte that can be used;)