Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Stable Raster via Timer
2003-12-28 19:40
Copyfault

Registered: Dec 2001
Posts: 453
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....
 
2004-04-20 12:34
Cybernator

Registered: Jun 2002
Posts: 154
Yup! As I mentioned above, this has happened to me too!
2004-04-20 13:43
Krill

Registered: Apr 2002
Posts: 2514
that's why the method i described is the best one with timers, no cia detection needed, working same on every machine.
2004-04-20 14:43
Copyfault

Registered: Dec 2001
Posts: 453
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
2004-04-21 05:04
White Flame
Account closed

Registered: Sep 2002
Posts: 135
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
2011-09-30 11:37
Cruzer

Registered: Dec 2001
Posts: 1007
So glad I found this topic! :)
2011-09-30 12:21
Groepaz

Registered: Dec 2001
Posts: 10522
one of the better summaries on the topic indeed :)
2011-09-30 13:02
ready.

Registered: Feb 2003
Posts: 441
Quoting Krill
Graham, 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!
2011-10-02 13:44
Cruzer

Registered: Dec 2001
Posts: 1007
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?
2011-10-02 17:38
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
2011-10-02 18:10
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mibri/ATL^MSL^PRX
acrouzet/G★P
Mason/Unicess
Karmic/HVSC
Airwolf/F4CG
MCM/ONSLAUGHT
Higgie/Kraze/Onslaught
Paladin/G★P
commodore_freak
kenchis
Bieno/Commodore Plus
FunFun/Triangle
Da Snake
macx
WVL/Xenon
Guests online: 49
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Uncensored  (9.6)
4 Comaland 100%  (9.6)
5 E2IRA  (9.6)
6 Bromance  (9.6)
7 Unboxed  (9.5)
8 Lunatico  (9.5)
9 Wonderland XII  (9.5)
10 Memento Mori  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Barry Boomer - Trapp..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 POKE 56576,1 for Unl..  (9.5)
6 Breadbinked  (9.4)
7 Onscreen 5k  (9.4)
8 Offering  (9.4)
9 No Mercy for the Tro..  (9.4)
10 2 shades of Gray  (9.4)
Top Groups
1 Lethargy  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Oxyron  (9.2)
Top Fullscreen Graphicians
1 Talent  (9.9)
2 The Sarge  (9.8)
3 Facet  (9.8)
4 Joe  (9.8)
5 Veto  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2023
Page generated in: 0.047 sec.