[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-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.

2004-04-18 20:13

Cybernator

Registered: Jun 2002
Posts: 154

@JackAsser: Never really tried to understand that method. Maybe I will when I decide to code a Viccy demo. ;)

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

I wasn't talking about your code. It was an idea, which crossed my mind that maybe the chip's designers have had their trouble here, which lead to incompatibility. But that's pretty much irrelevant.

Tested both routines on 6526A - PAL.

Cycles per Frame:
19655

Timing test:
63 cycles per line
19656 cycles per frame
312 lines
CIA #2 timer delays by 0 cycles

Haven't tested with an old CIA, but I'm pretty sure that the values would be the same as in Vice. And strange enough, they are the same as on 6526A. Is the timer on continuous or one-shot mode?

2004-04-18 21:23

White Flame

Registered: Sep 2002
Posts: 136

The timer is in continuous mode. The number reported in "cyclesperframe.prg" just gives the timer value that syncs to the screen. "timingtest.prg" adds 1 to the value, because then it actually reflects the number of clocks per countdown cycle.

It shouldn't be too difficult for me to measure the "phase offset" effect of the old timer, if that's what it does. However, if somebody could run that program on a machine with old 6526's and verify that it still reports a timer delay of 0 cycles, that'd be awesome.

2004-04-20 07:47

JackAsser

Registered: Jun 2002
Posts: 2014

I'm getting a little bit paranoid about all these timing differences on different CIAs. If I've undestood everything correct is that if you are using the timer approach (either signel or double) to gain stable rasters you have to be aware if you have an old or new CIA, right? So, usually I only care about if it's PAL or NTSC and in most cases I actually simply drop the NTSC support, so what about the CIA chip? Is one chip version more common than another? Are the any unwritten rules what chip the compo machine have, etc..? Or do I simply have to detect and support both inorder to not get flamed by various people? =)

2004-04-20 09:58

Krill

Registered: Apr 2002
Posts: 2980

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.

2004-04-20 10:54

Graham
Account closed

Registered: Dec 2002
Posts: 990

@krill:

i had a pure timer based 4x4 routine in oneder and there were visible bugs on some machines due to irqs being 1 cycle too late. since the discussion is about "stable raster via timer" it is a problem.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next

Refresh

Subscribe to this thread: