[CSDb] - User Forums - Shortest code for stable raster timer setup

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: 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 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-03 12:48

ChristopherJam

Registered: Aug 2004
Posts: 1409

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

cjam: See post 16 in this thread.

2020-12-03 14:21

ChristopherJam

Registered: Aug 2004
Posts: 1409

Arrgh, I'm going blind. Thank you Frantic.

2020-12-03 14:24

Rastah Bar
Account closed

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

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

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
Account closed

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

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.

2020-12-04 00:47

Copyfault

Registered: Dec 2001
Posts: 478

Ah well, f**k it, it obviously falls through on the first loop run. Damn!

2020-12-04 01:29

ChristopherJam

Registered: Aug 2004
Posts: 1409

Quoting Rastah Bar

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?

Could do - but every single cruncher in use is some kind of variation on "replacing things it has seen before with a reference to the earlier version" (though LZMA does also try and compress the bits in literal values if it can).

The code crunching specializations just separate out the operand stream from the opcode stream, either directly or by favouring offsets for copying bytes from 5 or 6 bytes earlier in the output-thus-far.

Any kind of guarantee that "hey I've seen nearly half these bytes already' is going to be hard to beat.

Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 19 - Next

Refresh

Subscribe 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

Derision/Longshot
Mike
Case/Padua
rexbeng
Honcho
katon/Lepsi De
Fred/Channel 4
Guests online: 79

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 No Listen  (9.6)
3 Party Elk 2  (9.6)
4 Cubic Dream  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)

Top Coders

1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Page generated in: 0.063 sec.