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

2020-12-04 14:40

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

@CJam: Thanks for explaining. It is a nice puzzle to find short uncrunched versions, but I understand that it remains to be seen how useful they really are.

@all:
Another variant: after some init code often the values in X and Y will be known. If one of them is larger then 127, then SHX or SHY can be used with an address with {H+1}<128 for a 7-byte, 10-cycle loop. F.e. let's say X>$7F and Y=$10 (any value Y<$FF can be made to work):

HH0c   shx $HH00,Y
HH0f   lda #any_value
HH11   bpl *-5

HH is a number smaller than $7F. The low byte of the start address should be adjusted according to the value of Y.
X or Y >$7f is hardly a constraint, since something like LDX #$80, STX $d020 already does the trick.

2020-12-04 21:49

Copyfault

Registered: Dec 2001
Posts: 478

I was about to begin with "Let's cheat it down to 7 bytes...", but hats off for being faster with a 7-bytes-version, Rastah Bar! Great stuff, really! But let's face it: the lower the amount of bytes for the actual sync routine, the more (and weirder) the constraints ;)

Here's my idea. After decrunch, let's assume we have two zp-adresses set to specific values: $9e=$fa; and $a0=$00 (other combinations are possible, but this one's fairly nice to illustrate the method). This'd allow us to sync with the following three lines of code:

loop:  lda $a6,x
       shx $00a0,y
       beq loop

The routine must be called with a JMP loop+1, so it starts with

entry: ldx $9e
       ldy #$00
       beq loop

Ok, it needs special zp adresses set to special values, but this is usually the case (one's tempted to say: "choose your vectors wisely";)). At least this routine can be placed at any mem position and the zp-values stay unchanged.

Don't know which constraints are less disturbing, but I think it won't get any smaller than 7 bytes. It's still a challenge to try to make it completely free of any constraint while keeping this small size!

2020-12-04 22:35

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

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.

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

Martinland
TheRyk/MYD!
4gentE/ΤRIΛD
MWR/Visdom
Nordischsound/Hokuto..
Freeze/Blazon
B.A./QUANTUM
iAN CooG/HVSC
Mike
St0rmfr0nt/Quantum
Case/Padua
Airwolf/F4CG
Walt/Bonzai
Neotec/Padua
Guests online: 108

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 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (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 Swappers

1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

Page generated in: 0.046 sec.