You are not logged in -
nap
CSDb User Forums
Forums
>
C64 Coding
>
Sprite synchronisation
2008-10-06
17:36
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
... 30 posts hidden. Click
here
to view all posts....
2008-10-07
20:20
Krill
Registered: Apr 2002
Posts: 2980
Ninja: Yes of course, totally forgot that in the morning haze :)
2008-12-11
08:04
Devia
Registered: Oct 2004
Posts: 401
Perfect sync with only one sprite is impossible. There're only 3 write cycles to do it with and only 1 instruction using 3 consecutive writes: BRK.
So it would seem that you can only account for a maximum of 2 cycles of jitter using 1 sprite, unless you do some NMI trickery, then maybe 3 cycles.
The fact that it works in various IRQ cases is due to the nature of the code being interrupted.
Perfect sync seems possible using 3 sprites like 3, 6 and 0 as that would give you 9 BA+RDY low cycles in one line.
But even with more sprites it seems pointless, unless you're already utilizing those sprites for something else. Why? because, either you have to keep the sprite on for at least 21 lines or you have to set it up 20 lines before.. So if we're talking interrupts, you'd end up with a double interrupt 20-21 lines apart instead of a "normal" double-irq eating 2 lines. Maybe usefull in cases where you need to do stuff every other line, but then again, use the bloody timers!
In the case of JSR * - this works because JSR is a R/W instruction and because of the badlines. JSR * is executing so fast that it is bound to have one of its 2 writecycles hit the 3 BA+RDY low cycles just before every badline, thus gaining 1-2 cycles. Stack corruption is just an added bonus which is irrelevant in this case.
It's the same as doing INC $xxxx;JMP *-3 or even sta/jmp or the like.. as long as some write cycles hit the BA+RDY low cycles, it's bound to get in sync within 1 or maybe a couple of frames.
- Disable bit 4 of $d011 (DEN) and your magic JSR * stable will become unstable, depending on the length of your interrupt of course, hehe :)
Previous
-
1
|
2
|
3
| 4 - Next
Refresh
Subscribe to this thread:
You need to be logged in to post in the forum.
Search the forum:
Search
All forums
C64 Coding
C64 Composing
C64 Pixeling
C64 Productions
CSDb Bug Reports
CSDb Development
CSDb Discussions
CSDb Entries
CSDb Feedback
CSDb Info
CSDb moderators
CSDb Questions
Messages to moderators
Requests
for
in
Writer & text
Text
Writer
All times are CET.
Search CSDb
All
Releases
Groups
Sceners
Events
BBS
SIDs
-------
Forum
Comments
Advanced
Users Online
CreaMD/React
Guests online: 101
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
No Listen
(9.6)
2
Layers
(9.6)
3
Cubic Dream
(9.6)
4
Party Elk 2
(9.6)
5
Copper Booze
(9.6)
6
X-Mas Demo 2024
(9.5)
7
Dawnfall V1.1
(9.5)
8
Rainbow Connection
(9.5)
9
Onscreen 5k
(9.5)
10
Morph
(9.5)
Top Groups
1
Performers
(9.3)
2
Booze Design
(9.3)
3
Oxyron
(9.3)
4
Censor Design
(9.3)
5
Triad
(9.3)
Top Fullscreen Graphicians
1
Joe
(9.7)
2
Sulevi
(9.6)
3
The Sarge
(9.6)
4
Veto
(9.6)
5
Facet
(9.6)
Home
-
Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.035 sec.