| |
Barbarossa
Registered: May 2007
Posts: 31 |
Sprite synchronisation
I am trying to get a stable raster with the help of sprite timing. I've read the articles in C=hacking about it, but it is not explained in full detail there. That is, when I look at the examples Missing Cycles and TechTech, I don't quite get it.
I've tried the timing of those examples in an emulator. I have found out that when the INC ends within the cycles that BA goes low, the intruction ends exactly after the sprite fetch. This would mean that the interrupt cannot be more off than 3 cycles and we all know that we have to deal with 2-9 cycles (7 cycles variance). So how can this trick be stable?
If someone could explain this to me (an article about this in Codebase would be really neat) I would be very grateful.
John
|
|
... 22 posts hidden. Click here to view all posts....
|
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
If you know what kind of instructions will be used when the interrupt triggers, it becomes easier. E.g. if your non-interrupt code does this:
forever:
jmp forever
the variance should be 0-3 cycles, right?
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
with a mainloop like this you dont need a irq in the first place =D |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
When I use more sprites or more INC/DEC's I can probably get it to work, but how can the following code from C=hacking work then? It only uses one sprite and one INC.
irq:
lda #$13 // open the bottom border (top border will open too)
sta $d011
nop
bit $11
ldy #111 // reduce for ntsc ?
inc dummy // do the timing with a sprite
bit $ea // wait a bit (add a nop for ntsc)
loop3:
lda tech,y // do the x-shift
sta $d016
...
The raster is stable from loop3. |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: If you know what kind of instructions will be used when the interrupt triggers, it becomes easier. E.g. if your non-interrupt code does this:
forever:
jmp forever
the variance should be 0-3 cycles, right?
LOL, yeah unfortunately it isn't that simple.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
try this instead:
http://codebase64.org/doku.php?id=base:double_irq
shortly: the first irq it initiates a 2nd one, while the 1st irq executes nops the 2nd one will hit => only 1 cycle jitter left which is ironed by watching $d012 wether its in the current or the next line. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
somehow i get the impression that he knew that already when he explicitly asked about how to do it with sprites (which indeed can be better in some cases) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: If you know what kind of instructions will be used when the interrupt triggers, it becomes easier. E.g. if your non-interrupt code does this:
forever:
jmp forever
the variance should be 0-3 cycles, right?
not to forget the magic "jsr *" resulting in stable raster. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: not to forget the magic "jsr *" resulting in stable raster.
I see a corrupt stack... Please enlighten me. :D |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: try this instead:
http://codebase64.org/doku.php?id=base:double_irq
shortly: the first irq it initiates a 2nd one, while the 1st irq executes nops the 2nd one will hit => only 1 cycle jitter left which is ironed by watching $d012 wether its in the current or the next line.
Oswald,
I already know and understand the double IRQ methode. It is the sprite synchronisation I don't understand. |
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
Try this one: http://codebase64.org/doku.php?id=magazines:chacking3#the_demo_..
And no, just one sprite instead of all eight is enough to make the raster stable. |
| Previous - 1 | 2 | 3 | 4 - Next |
