| |
xIII
Registered: Nov 2008
Posts: 210 |
Horizontal d020 scroller
I'm still learning ... and again I could use some advice.
I coded a d020 scroller that actually works :p
I'm having trouble with the stability (the scroller is jittering ?). I used the double IRQ routine but I just cannot get the timing correct.
If there's a coder out there who wants to help me by taking a look at the code, send me a msg with your email and I'll send you the kickasm code.
thanks. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
*if* the double irq is working you must have only 1 cycle jitter left. do this with the 1 cycle jitter:
lda $d012
sta $d020
by adding/removing nops bit $xx, etc. find the place (right edge of screen) where d020 color flickers, then you found the place where the raster counter is 'flickering' between two lines.
there you have to add this line:
lda $d012
cmp $d012 ;<- place of lda $d012 of prev code in timing
beq next
next
this adds +1 cycle when needed.
sometimes it was bne next, but never tought about it why, just hacked the code mindlessly. :o) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Double-check if all indexed addressing modes do not cross a page border. Also check if all branch instructions do not cross a page border. Especially the latter can easily slip through, so most people have a macro checking this for branches in timing sensitive code. |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Oswald: good tip. Double IRQ routine seems to be OK, this is confirmed by Flavioweb who was so kind to take a look at the code.
Flavio explained the problem and I'm trying to work out a solution.
I'm not sure if I understood it all very well but it seems that it has something to to with delaying cycles every frame. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Code is stable and works as it should.
The "glitch" is caused by a not complete "scroll" routine that, for now, -move- chars simply updating the "sta" for bgcolor in an "hardcoded" way, without modify the starting cycle for each frame.
This mean that the minimum step is 4 cycles, so 32 pixels, and this cause a poor scroll movement.
XIII should implement an "intermediate cycles delay" code, to cover 4 steps, each with 1 cycle difference from previous, to achieve a more "smooth" scroll fx.
I suppose this can be done with some self-modify code, that update itself, accordingly with a step-counter.
Same as is done with normal scroll routine, but done with cycles and for only 4 steps instead of 8...
I think is more simple to code that explain it... |
| |
xIII
Registered: Nov 2008
Posts: 210 |
I came up with this routine:
ldx timer1 // 3-2-1-0 2
dex // 2-1-0-ff 2
bpl *+2 // taken-taken-taken-not 3-3-3-2
dex // 1-0-ff-fe 2
bpl *+2 // taken-taken-not-not 3-3-2-2
dex // 0-ff-fe-fd 2
bpl *+2 // taken-not-not-not 3-2-2-2
// ------------------------>17-16-15-14
Later in the code:
dec timer1
bmi resettimer1 and do scroll
jmp endirq
This helped for a smoother scoll but it still is not smooth enough. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
You used this code just before "line1"?
Keep in mind that minimum "resolution" possible is 8 pixels, but this should give a decent scroll movement...
Ps: you have a mail. Give a look. |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Found this routine in Krestage which also does the trick (code is a little modified to my needs):
self_mod:
cmp ($00),y
jmp line1_entry // 59
delay:
ldx timer1
lda cycle,x
sta self_mod
rts
cycle: .byte $d1,$c9,$c5,$d5
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Ok.
Nice way to do it.
With cycles in correct sequence, it should work as well... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
use this:
sta timeit+1
timeit bpl timeit+2
.byte $a9,$a9,$a9,$a9,$a9,$a9,$24,$ea
by changing how far bpl jumps (sta timeit+1), you can change in a cycle exact way how much cycle is wasted. trick is that the last few bytes alternatively translate into bit $ea, or lda #$24 nop, giving one by one increments of extra cycles as you go.
code snippet from a 4x4 irq by ninja. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
take care of having a cia detection if you do things by timer though. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Bitbreakertake care of having a cia detection if you do things by timer though. This is why i prefer VIC rasterline interrupt + jitter correction via reading a CIA timer (which does not require handling different CIA revisions), rather than having CIA timer interrupts. Unless the former is not feasible for some reason. |
