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: 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....
2004-03-03
12:36
Copyfault
Registered: Dec 2001
Posts: 475
I felt like putting some final words on this thread;)
Ok, I still wonder why Graham did never have 8 different timer values, but there are eight states. Like Cybernator stated in his last posts, this has something to do with the way a branch_instruction is carried out: normally an IRQ_Condition can be acknowledged while an instruction is being executed. But there are socalled "Opcode_fetch"-cycles which won't allow ack'ing! Let's simplify things and say these opcode_fetches are always done on the first cycle of each instruction - then ofcourse we will only get 7 different timer value, corresponding to 0-6 cycles variance, or 1-7 cycles delay resp. But if the IRQ_Condition occurs on the second cycle of a taken branch that does not cross a page, there will be no ACK in the third cycle of the branch instruction as it also is an "opcode_fetch"-cycle. In this rare case we will get a delay of 1 cycle (coming from this 3rd branch_cycle) _plus_ n cycles from the following opcode! If the following instruction is an indexed RMW, this gives us a delay of 1+7=8 cycles, explaining the 8th state I was always wondering about;))
Cybernator and me coded some fast routines to proof this. The progs allow to let the RASIRQ_condition occur on a selected cycle of our main_code. If you're interested in these programs, then just drop me a privat line here, ok?
A big thank to everyone here - you all helped to push things forward! Above all, I definatly have to thank Cybernator for all his activities and his motivation to find an answer to my question! Keep up the good work, guys!
2004-03-24
16:40
White Flame
Registered: Sep 2002
Posts: 136
Regarding the differences in CIAs, could you guys run this program if you get a sec?
http://www.white-flame.com/cyclesperframe.prg
I get 17094 for my NTSC C128, and VICE's PAL mode gives 19655. I'm curious to see what the numbers would be with an older 6526; I'm guessing they'd be one less? The number reported is the CIA timer value that synchronizes with the screen refresh.
2004-03-25
05:52
Fungus
Registered: Sep 2002
Posts: 680
This is all very interesting...
I get 9 cycles depending on if something is crossing a page boundary or not.
Also, I think ive experienced this irq on bxx bug, as I had a raster routine here somewhere which crashes for no reason, and the PC is way off...
Ill have a look.
2004-04-15
06:54
JackAsser
Registered: Jun 2002
Posts: 2014
FYI, I also get 8 different delays using copyfault's main loop.
After reading this thread I got inspired and also wanted to try to stabalize rasters using double timers since they have quite nice properties. I'm however a bit confused. How come the raster is stable at the exact the same spot on the screen every time I run the code. Shouldn't this be pretty random or has this something to do with VICE (since I autolaunch the code as fast as possible)?
As a follow up question, what method should I use to always be certain that the raster is stable on the exact same position on the screen each time run the code? My first idea was to use double rasters for the first time to lock the exact spot on the screen then use the timers but this seems a bit overkill.
What do you guys think / how do you usually do it?
For example in those 4x4 modes, what is the preferred method to use the timers here? (not that I like 4x4 modes, but hey...) =)
2004-04-17
07:57
Cybernator
Registered: Jun 2002
Posts: 154
You have to use another method (eg. double IRQ) to sync the timer. It's not overkill as you only sync the timer once.
> For example in those 4x4 modes, what is the preferred
> method to use the timers here?
Preference is a subjective matter.
Whenever you have multiple IRQs close to each other, you might want to use a timer (eg. distorters). As for double timer, I don't know where else I'd use it except for 4x4.
@White Flame: Vice and CCS emulate the old CIA! I'll see what my commies say, asap.
2004-04-17
08:24
White Flame
Registered: Sep 2002
Posts: 136
Grab this instead, it's much better:
http://www.white-flame.com/timingtest.prg
I've got a 128, so I'm pretty positive it has 6526A's in it, and I get the same values as NTSC VICE.
It runs the timer on continuous mode, and syncs to the screen refresh with a latch value of 17094, which takes 17095 cycles, which is sensible (65 cycles/line * 263 lines). If the latch value would sync at 17093, it would report that the CIA delays by 1 cycle. Note that the program should work on any 64, no matter the VIC-II or CIA version.
So, with 6526 vs 6526A, is the one cycle difference a difference in the actual cycles spent during timer countdown (ie, on one CIA you need to inc your timer values compared to the other, which is what the program looks for), or is it a "phase offset" where it triggers the IRQ on a different cycle than the other (trigger when it hits 0 vs trigger when it reloads the latch value)?
2004-04-17
13:37
JackAsser
Registered: Jun 2002
Posts: 2014
Quote:
You have to use another method (eg. double IRQ) to sync the timer. It's not overkill as you only sync the timer once.
> For example in those 4x4 modes, what is the preferred
> method to use the timers here?
Preference is a subjective matter.
Whenever you have multiple IRQs close to each other, you might want to use a timer (eg. distorters). As for double timer, I don't know where else I'd use it except for 4x4.
@White Flame: Vice and CCS emulate the old CIA! I'll see what my commies say, asap.
Ahh, ok. I usually use double IRQ, that's the only way I fully understands why it works. Can someone perhaps explain the half-variance method? I can understand that it should work but how do you reason when calculating the cycles.
2004-04-17
14:27
Cybernator
Registered: Jun 2002
Posts: 154
Half-variance method !?
> So, with 6526 vs 6526A, is the one cycle
> difference a difference in the actual cycles
> spent during timer countdown (ie, on one CIA
> you need to inc your timer values compared to
> the other, which is what the program looks for),
I doubt it's the case, because that would lead to significant incompatibility!
> or is it a "phase offset" where it triggers the
> IRQ on a different cycle than the other (trigger
> when it hits 0 vs trigger when it reloads the
> latch value)?
Most probably! The problem finally occurred in my 4x4 routine. At first it worked a-ok, then (after a lot of mods in the code) it began to flicker like hell while it worked perfectly in an emu. I tried an old C64 and it worked there too! (Might have been page-crossing thing). The IRQ was occurring one cycle earlier and after a quick patch the routine worked on both CIAs.
Btw, you could never read 0 from $dc04 (or whatever) when on continuous mode! Let's suppose the timer counts down from 5. What you'd read is: 5, 4, 3, 2, 1, 5, 5, 4, 3, 2, 1, 5, 5, 4, etc... Maybe the whole issue starts here? ;)
There's an article written by Wolfgang Lorenz at Funet, explaining this behaviour. Have a look!
2004-04-17
16:27
JackAsser
Registered: Jun 2002
Posts: 2014
Half-variance, the method used on VIC20 for instance, when you can't use raster interrupts.
2004-04-17
20:16
White Flame
Registered: Sep 2002
Posts: 136
> Btw, you could never read 0 from $dc04 (or whatever) when
> on continuous mode! Let's suppose the timer counts down
> from 5. What you'd read is: 5, 4, 3, 2, 1, 5, 5, 4, 3, 2,
> 1, 5, 5, 4, etc... Maybe the whole issue starts here? ;)
It's still a 6-cycle pattern when 5 is loaded, so there should be no difference. I don't read the timer value at all. I'll check that article out, though.
Graham, do you have any more info on the 6526/6526A difference? I don't have a 6526 in any of my machines. I don't think that a 1-cycle offset will matter incredibly much for my routine (since it does a cycle patchup via reading $d011), but it does need to be cycle-exact.
Previous
-
1
|
2
|
3
|
4
|
5
| 6 |
7
|
8
-
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
Dr. Doom/RAD
krissz
Guests online: 82
Top Demos
1
Next Level
(9.7)
2
13:37
(9.7)
3
Coma Light 13
(9.7)
4
Edge of Disgrace
(9.6)
5
Mojo
(9.6)
6
The Demo Coder
(9.6)
7
What Is The Matrix 2
(9.6)
8
Uncensored
(9.6)
9
Comaland 100%
(9.6)
10
Wonderland XIV
(9.6)
Top onefile Demos
1
Layers
(9.6)
2
Party Elk 2
(9.6)
3
Cubic Dream
(9.6)
4
Copper Booze
(9.6)
5
Libertongo
(9.5)
6
Rainbow Connection
(9.5)
7
Onscreen 5k
(9.5)
8
Morph
(9.5)
9
Dawnfall V1.1
(9.5)
10
It's More Fun to Com..
(9.5)
Top Groups
1
Performers
(9.3)
2
Booze Design
(9.3)
3
Oxyron
(9.3)
4
Nostalgia
(9.3)
5
Triad
(9.2)
Top Crackers
1
Mr. Z
(9.9)
2
Antitrack
(9.8)
3
OTD
(9.8)
4
Fungus
(9.8)
5
S!R
(9.8)
Home
-
Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.056 sec.