| |
Copyfault
Registered: Dec 2001
Posts: 475 |
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 |
|
... 65 posts hidden. Click here to view all posts....
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Yup! As I mentioned above, this has happened to me too! |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
that's why the method i described is the best one with timers, no cia detection needed, working same on every machine. |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
This topic seems to get outta control... at the very beginning I only had the version with _one_ timer in my mind (like Krill) !
Up to now I haven't used the double_timer method. The _only_ advantage is that you can save some cycles on IRQ_entry - or is there even more? If we are at it at the moment:
i) what is the shortest possible way to sync the "1st" timer...
ii) ...and how do we test the CIA-Versions reliably?
...there _are_ solutions to this prob, aren't there?
One last question in my head: why do people always use two timers? Ok, it says "double timer method", but it should be possible to sync one timer (usually called the "1st" in the double_timer method), and use exactly the same one as "2nd" timer to kill the variance cycles - or do I miss something?
Later
/Copyfault |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Well, I pulled apart my 128, and lo and behold there are a pair of non-A 6526's staring up at me. :-P So, can I get a few testers for yet another version of http://www.white-flame.com/timingtest.prg ? This one *should* detect between a 6526 and 6526A. I'll yank apart some non-working C64s from home and see if I can get some 6526A's.
(I also was curious as to whether or not sprite DMA still happened when you turned the screen off... it does)
Here's the relevant code:
;---------
; 6526 vs 6526A
;
; Set off a single-shot NMI to interrupt
; immediately before an INC statement. The
; older 6526 triggers one cycle later, so it
; will run the INC while the newer one won't.
testCIAVersion:
; Set NMI vector
lda #<continue
sta $fffa
lda #>continue
sta $fffb
; Set timer to 5 cycles
lda #4
sta $dd04
lda #0
sta $dd05
; Clear the detection flag
sta oldCIA
; Fire a 1-shot timer
lda #%10011001
sta $dd0e
; This should be interrupted before the INC
; only if it's a newer chip.
lda $dd0d
lda $dd0d
inc oldCIA
jmp * ; just in case
continue:
lda $dd0d
pla
pla
pla
rts
oldCIA:
.res 1
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
So glad I found this topic! :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
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 |
