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: 2804
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-02 18:44
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Rastah Bar
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.
Ok, that's true. However screen blanking could be done inside the code bracket, but it is a constraint as it's not possible to display anything during this init.

Quoting Rastah Bar
VIC always steals the same amount of cycles from the CPU on a badline. This is system independent.
YES ofcourse!!! Thanks for the oh so pbvious yet clever point! So the drawback that remains is the demand of a running timer. With my last proposal (based on Quiss' SHX-idea), we'd have no constraints at all, but it needs 11 bytes in its current state. So definately not the shortest one, but at least something with SHX :)
2020-12-02 18:49
Rastah Bar

Registered: Oct 2012
Posts: 336
The more different approaches, the merrier :-)

It could very well be that screen blanking is not required for CJam's approach, but it needs to be analyzed. With likely multiple W instructions in the init code, that seems very difficult. And I'm too tired right now to think about it very hard. Not that I can figure it out, anyway :-)
2020-12-03 12:48
ChristopherJam

Registered: Aug 2004
Posts: 1359
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)
2020-12-03 13:05
Frantic

Registered: Mar 2003
Posts: 1626
cjam: See post 16 in this thread.
2020-12-03 14:21
ChristopherJam

Registered: Aug 2004
Posts: 1359
Arrgh, I'm going blind. Thank you Frantic.
2020-12-03 14:24
Rastah Bar

Registered: Oct 2012
Posts: 336
Quoting ChristopherJam
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)

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.
2020-12-03 14:49
ChristopherJam

Registered: Aug 2004
Posts: 1359
Quoting Rastah Bar

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.


Oh yes, I'm well aware that (compressibility aside??) the mantle of shortest routine has moved on :)

Quote:
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?


Oh, I see - the requisite phase drift might not occur.. Yes, I can see that's a potential issue, and one that would be quite a nightmare to debug if someone hadn't already pointed out the possibility. Well spotted!


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...
2020-12-03 17:22
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Rastah Bar
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.
Well, what can I say? Thanks!!! I happily take this "medal" :)) Makes all other approaches not a tiny bit less attractive (and I still have to do the transferring to codebase,so @Frantic: sorry for delay!)

Quoting ChristopherJam
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.
This was also some point I always wanted to get rid of. I'm over-happy that my last proposal does not need a jmp inside of the loop but can just start with the first opcode, the LDX #initval. But fair point with the context, the routine is usually called after the cruncher finished its job, so a jmp to whatever adress shouldn't be a real constraint.
2020-12-03 20:37
Rastah Bar

Registered: Oct 2012
Posts: 336
Quoting ChristopherJam

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?
2020-12-04 00:23
Copyfault

Registered: Dec 2001
Posts: 466
Here's another nice one I just found: if we first have an init-routine that initialises zp-adr $9f with a non-zero(!) value val, the following routine can be run afterwards to get in sync:
loop: lax $9f
      ldy #$ff
      cmp <($100 + $9f - val),x
      bne loop+1
Takes 8 bytes and though it operates on zp, it is non-destructive, i.e. the value of $9f is restored again when the loop terminates.
Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 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
Laurent
apprentix
jmin
kbs/Pht/Lxt
Dymo/G★P
celticdesign/G★P/M..
MAT64
Guests online: 356
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

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