| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Stable Raster via Timer
Maybe some of you advanced coders can help me with the following oddity. I'll keep out the basic routine for stabilizing rasters with the timer method, as it is presumably known to everyone!
If we ignore Illegal Ops for the moment, the max. number of cycles occuring in the main prog is 7 (when executing an indexed RMW). When it comes to the different values the variance can take, there should also be 7 (0 to 6 cycles). I wrote some (working!) routines, but I always end up having 8 different variance values. Of course one can live with it, but I wonder where this 8th state comes from!
If necessary, I'll deliver more details. I'd be really happy to understand this behaviour!
Yours, Copyfault |
|
... 70 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
one of the better summaries on the topic indeed :) |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Quoting KrillGraham, please don't scare people so much =) In reality, the different CIA delays won't be any problem. Graham said there are different timings of CIA interrupts on different machines. Well, so what?
The most common implementation of a CIA-timed raster stabilizer (on the C64) would be to set up _one_ timer (to repeatedly count 63 cycles on PAL) in the main loop under sterile circumstances (in the border without sprites and no other possible delay factors), using the half-variance method.
Then you set up a _VIC_ raster interrupt which should have the same timing on every machine. In the irq handler, you can read out the CIA timer register and delay accordingly to get to always the same cycle and have a stable timing. The value the CIA gives is the same on every machine.
Et voilà, stable raster position on every machine.
I fully agree! Best topic on the subject. Especially Krill's post really opened my mind and made "Aurora 100%" last part possible, where I needed 100% stable raster for the fullscreen sprite split. I even mentioned Krill in the note for his post!
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Btw, does anyone know if 9 different jitter cases (0-8 cycles) is the absolute maximum one has to take into consideration, or have there been other even more extreme situations discovered? |
| |
terric
Account closed
Registered: Feb 2009
Posts: 47 |
Most intresting topic.
( How it works ,My shot( a guess ):
Those Jittercases is an ongoing instruction and interrupt have to wait 0-8 cycles to occur.
So if processor just has gotten an instruction irq have to wait max of 7 cycles ( an example asl $1234,x ) and a fetch cycle for pc? )
What about those illegal ops, are there any know cycleburners? :D |
| |
terric
Account closed
Registered: Feb 2009
Posts: 47 |
About those extreme situations.
Most situations is controllable. We have seen restore disablers and other stuff. (restore fires off a nmi right?!)
So my advice, disable irq that are not needed and you
have control over which sources that will take cycles.
By example:
You have a timer interrupt.
It fires off at once a frame.
What the timer does is like playing music, shifting to finished screen and acknowledges interrupt and ends interr.
Still rastertime left, yes we have
and goes back to where processor was last time.
And where were the processor,
Frst frame:
Processor have just finished the initilising code for the timer int and jmped to music_init. Heads back to code after.(an loop)
x frame: Processor heads back to stored location in loop.
Hope some need a little advice, or like remember this right! :)
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
