Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user maak ! (Registered 2024-04-18) 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: 2825
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 01:24
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Rastah Bar
Thanks! I should have looked at the latest version of the "No More Secrets" document.
True that! Should've used the opportunity to do some advertisment for this fine document - my group fellow Groepaz does an outstanding job creating and continuously extending it!

Quoting Rastah Bar
[...]The (currently) shortest code that can be placed anywhere was proposed in post #44.
Well, I feel like a little correction is appropriate:
1. while the approach with the timers is fine and I really like it, it still depends on the timers being correctly set. Ok for most init situations, but in general dangerous to rely on.
2. The "code bracket approach" introduced by CJam (post#23) and the pure LDA-variant thereof I posted in #31 are also 12 (or even 10) bytes long (still arguable if that LDY #val must really be counted, but ok) and have no mem location constraints other than the fact that some lines of code must be put inside of this "bracket".

Quoting Rastah Bar
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.
So let's get rid of these location restrictions;) Since all the routines are meant to be run during init, why not let the sync loop do some init'ing also? So if we want a zp-adress zp_pos=$00..$fe to be init'ed with an initval(!=0), this routine will do it:
      ldx #initval
      ldy #<(zp_pos+1)
loop: shx $ffff,y
      lda <($100 + zp_pos - initval),x
      beq loop
The routine ends with accu=initval, which is also stored in at zp_pos in the zeropage. It works from any mem location. Only restriction is that zp_pos=$ff is not permitted. It can be shortened even further iff special init values and/or zp-adresses are used (got it down to 8 bytes so far), but I leave it as is now.


Will check codebase within the next days and add some of the routines of this thread, unless someone tells me it's already up there.
2020-12-02 13:33
Rastah Bar

Registered: Oct 2012
Posts: 336
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.
2020-12-02 18:13
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Rastah Bar
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.
But we both agree that this is not the shortest, but rather one of the shortest approaches that work without mem loc constraints, don't we?;) The code bracket with INCs is 10 bytes long, the other one with LDAs sums up to 10 + 2(for an LDY #val that effectively is also part of the init code) in total...

Now concerning the different VIC systems in your timer based approach, I wonder wether the operand of the sbx must be adjusted according to the no. of cycles per line or if this works with subtrahend 51 on all systems for some magic reason...
2020-12-02 18:18
Rastah Bar

Registered: Oct 2012
Posts: 336
Quoting Copyfault

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


Nice! LDA <($100 + zp_pos - initval),X can simply be replaced with LDA zp_pos, I think.
2020-12-02 18:26
Copyfault

Registered: Dec 2001
Posts: 466
Quote: Quoting Copyfault

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


Nice! LDA <($100 + zp_pos - initval),X can simply be replaced with LDA zp_pos, I think.


No, the loop'd take only 11 cycles which does not suffice, see also post #61 by Quiss. This was the reason to use the x-indexed version.
2020-12-02 18:26
Rastah Bar

Registered: Oct 2012
Posts: 336
Quote: Quoting Rastah Bar
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.
But we both agree that this is not the shortest, but rather one of the shortest approaches that work without mem loc constraints, don't we?;) The code bracket with INCs is 10 bytes long, the other one with LDAs sums up to 10 + 2(for an LDY #val that effectively is also part of the init code) in total...

Now concerning the different VIC systems in your timer based approach, I wonder wether the operand of the sbx must be adjusted according to the no. of cycles per line or if this works with subtrahend 51 on all systems for some magic reason...


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.
2020-12-02 18:30
Rastah Bar

Registered: Oct 2012
Posts: 336
Quote: No, the loop'd take only 11 cycles which does not suffice, see also post #61 by Quiss. This was the reason to use the x-indexed version.

Oh yes, I forgot about that. Hard to keep track of all the subtleties :-)
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: 1370
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)
Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 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
Fungus/Nostalgia
Guests online: 67
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 Wafer Demo  (9.5)
7 TRSAC, Gabber & Pebe..  (9.5)
8 Onscreen 5k  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Jeroen Tel  (9.7)
3 Stinsen  (9.6)
4 Mutetus  (9.6)
5 Linus  (9.6)

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