[CSDb] - User Forums - Stable Raster via Timer

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: 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

... 65 posts hidden. Click here to view all posts....

2004-03-03 12:36

Copyfault

Registered: Dec 2001
Posts: 478

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: 686

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 for in
All times are CET.

Search CSDb

Advanced

Users Online

Alakran_64
Andy/AEG
Paladin/G★P
LordCrass
MWR/Visdom
Knut Clausen/SHAPE/F..
Guests online: 89

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 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (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 Musicians

1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Page generated in: 0.067 sec.