A.D.A. Amiga Demoscene Archive

Hey Guys

Wondered if any of you here are very familiar with CIA interrupts? We're working on PT-1210 at the moment, biggest change is we're dropping loads of the assembly in favour of C and making everything nice and system friendly. That in itself has already fixed a bunch of bugs and allows us a load of cool benefits.

So, we're now adding our CIA interrupt using system calls but it seems to be running slightly slower than the original assembly / hard hack we had. Doing a side by side example running a tune at 170 BPM on the old version, we have to set the new version to run to 170.6 BPM to get them at the same speed.

In addition to this, we're noticing differences in the CIA speed between different Amigas, although that was also the case with the original hard hack version.

I guess what I'm achieve is a solid CIA interrupt which runs at the same speed on all amigas.

Anybody had any experience with this?

Have a look how P61 (P61_openciares) is doing, it use OpenResource("ciab.resource") to get if $bfd500 or $bfd700 is free. After that it "hardbanging" this register instead of using the system friendly StartTimer.

Finally found the issue, with the help of kalms / tbl and a couple of beers in an airport bar!

So, it would appear that protracker has only ever used one shot timers. With one shot, each call to the interrupt requires you to reset the timer value, otherwise it never runs again. With continuous, the system re-loads the timer value automatically.

Now, the issue with using the one shot approach is that a handful of instructions will be executes before you can even begin to reset the timer. This handful of instructions are all effected by factors in the system, CPU speed, fast ram, DMA access etc. so you end up with a small amount of indeterminable time added on the your timer value, meaning they will always run just a little slower.

So why did ProTracker not use the continuous approach if it would be more curate? Well the real reason is that in continuous, if you change the timer value, it doesn't take affect until the next run of the interrupt. As ProTracker can perform BPM changes on any line, that change needs to be set a frame early. The only way to get around it would have been to read ahead 1 extra line of pattern data.

The test I ran today played a 125 bpm module at 124.996 bpm, so I reckon about as accurate as you could get it.