| |
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. |
|
... 1 post hidden. Click here to view all posts....
|
| |
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. |
| Previous - 1 | 2 - Next |
