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


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

Registered: Apr 2002
Posts: 1786
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?
 
... 176 posts hidden. Click here to view all posts....
 
2021-01-31 12:39
Groepaz

Registered: Dec 2001
Posts: 9747
thats what the opcode does - why exactly it happens is unknown, but its likely some analog effect
2021-01-31 13:21
Krill

Registered: Apr 2002
Posts: 1786
Yes, something to do with DMA interference* disturbing the inner workings of that opcode. And it's a non-intended (illegal) opcode anyways, so short-circuiting inner logic to begin with. :)

* It has been observed that other 6502-based platforms without DMA (1541, e.g.) do not exhibit the &H-dropoff behaviour.
2021-01-31 15:04
Copyfault

Registered: Dec 2001
Posts: 382
Quoting Oswald
why does the &hi disappear on a badline?
In my text "badline" was short for "the 1st DMA-overtake-cycle @cycle#12 in every badline".

If the 4th cycle of the SHX abs,Y coincides with a DMA-overtake cycle, the &(hi+1) drops off, see e.g. post#88 or the latest No More Secrets V0.95.

Ofcourse all sprites must be turned off while the routine is running (they'd throw in other DMA-overtake-cycles and break the whole thing). So the basic trick (courtesy of Quiss;)) is to uniquely mark badlines with the DMA-overtake-cycles and loop until the beforementioned 4th cycle of the SHX lands on the correct cycle (or short: "on a badline";)).
2021-02-01 00:44
Devia

Registered: Oct 2004
Posts: 401
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 ;-)
2021-02-01 10:19
Frantic

Registered: Mar 2003
Posts: 1486
Yes, this thread should have some kind of warning sign attached to it. :)
2021-02-01 15:52
Copyfault

Registered: Dec 2001
Posts: 382
Quoting Devia
What an awful thread.. fell down the rabbit hole, turned utterly insane, lost several days of sleep...
How can it be so awful when it guided you into Wonderland :) ??

Quoting Devia
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.
Wow, loop times depending on the adress-highbyte. But yeah, a JMP-instruction is needed to change the basic structure from opcode-change to operand-change... (unless one wants to exit from the loop by jumping back, but let's not go that route)

Quoting Devia
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 ;-)
Hm, ok, I agree that readability was not the main focus most of the times... but at least some variants that leave A untouched were given already (basically those with a CPX#val).

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

Thanks for your version; it just rang the "things that I wanted to do"-bell for me (writing it all up on codebase, that is;)).
2021-02-01 18:10
Devia

Registered: Oct 2004
Posts: 401
Quoting Copyfault
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;)

That's what I mean about the insanity..I do remember reading that post and the following ones, but apparently didn't recognize their brilliancy the first time around - that one is a keeper! ;-)
2021-02-01 19:06
Oswald

Registered: Apr 2002
Posts: 4682
is there any requierement for the nr of cycles for the whole loop to make sure it will 'always' land on a different cycle of the shx opcode on the badline's 12th cycle?
2021-02-01 19:44
Rastah Bar

Registered: Oct 2012
Posts: 290
Yes, see posts 61 and 72 (and 69 for an explanation):

"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."

"Indeed, loop length of 17 gets "fixed" by the border. Depending on which cycle you land on initially, loop exit gets delayed by up to three frames, but it'll eventually align.
A similar thing happens with 27, which takes up to four frames to align.
Those seem to be the only "special" (multi-frame) cases below 30."
2021-02-01 20:47
Oswald

Registered: Apr 2002
Posts: 4682
thanks for everyone for the explanations, this shx method is really cool :)
Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 - 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
r242
johncl
Guests online: 81
Top Demos
1 Coma Light 13  (9.6)
2 Edge of Disgrace  (9.6)
3 Uncensored  (9.6)
4 Unboxed  (9.6)
5 Comaland 100%  (9.6)
6 Memento Mori  (9.6)
7 Lunatico  (9.6)
8 Christmas Megademo  (9.5)
9 Thirty  (9.5)
10 The Shores of Reflec..  (9.5)
Top onefile Demos
1 Copper Booze  (9.8)
2 To Norah  (9.7)
3 Lovecats  (9.6)
4 Elite Code Mechanics  (9.6)
5 Daah, Those Acid Pil..  (9.5)
6 Square Booze  (9.5)
7 For Your Sprites Only  (9.5)
8 Quadrants  (9.5)
9 Hyperborea  (9.5)
10 Catwalk  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Fossil  (9.4)
3 Censor Design  (9.3)
4 Oxyron  (9.3)
5 PriorArt  (9.3)
Top Cover Designers
1 Duce  (9.8)
2 Electric  (9.8)
3 Junkie  (9.7)
4 The Elegance  (9.4)
5 Mermaid  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.045 sec.