How to find out if we are on PAL or NTSC?
 

I am trying to write a function that gets an audio frequency and then returns the nearest AUDxPER value to be used for that frequency. It works like this:
However, I couldn't find any way to find out if I am in PAL or NTSC. Alternatively something that gives the cycles/second could work as well, since then I would just send cycles/second to the function and it would still work. The only thing I was able to find is to read VBlankFrequency and check if it's 50 or 60. But this won't work for doublescan resolutions or custom resolutions, I am not interested in the screen framerate, I want to know the number of cycles per second.

Check VPOSR http://www.winnicki.net/amiga/memmap/VPOSR.html

That tells you the vertical frequency of the currently active screen mode (and only so if this is a native screen mode), but not the system clock frequency. To check for PALN/NTSC, please read the graphics/gfxbase.h include file, there is a flag for it. One is dynamic and changes with the active monitor, but for the system clock frequency, there is a flag named something like REALLYPAL that corresponds to the installed crystal.

What?!
It tells you which version of Agnus/Alice you have installed, and usually is supposed to have its associated crystal.
It has nothing to do with active video mode, as with both crystals and versions of Agnus-hr/Alice you can have NTSC or PAL lines.

If I understood it correctly, this should do the trick?

:agree

Just noticed.. you sure used values are perfect?

In literature are reported values for PAL CCK = 3546895 and for NTSC = 3579545

I calculated the PAL one, don't remember where I got the NTSC from. Got the PAL as 227*15625 = 3546875. Think I'll go with your values instead, they are probably the correct ones.

Yep, PAL h-freq on Amiga is not exactly 15625 but 15625,0881Hz
On NTSC is even more different due to alternating length lines (it only average to 64us EDIT:~63,56us).
So use my posted values :)

I just got to those alternating length lines. I'm tying the timing of the phase shift to those cycles and it just gets more and more complicated as I read the documentation.

Well, alternating lines are neutral in regard to your phase shift, only CCK is significant. Or I'm missing something?

Well, it's about the way I am synching the channels.

The current idea I am working on is:
1) find a vposr/hvposr nearby that we will use to start the whole thing
2) precalculate vposr/hvposr for all the next steps knowing the delays we want to have
3) vposr/hvposr wait to: start up the dma
4) vposr/hvposr wait to: stop the dma when we started playing the 2nd sample from the first pair
5) vposr/hvposr wait to: write to channel 0 when all of the channels are on idle
6) vposr/hvposr wait to: write to channel 1 at 90 degrees
7) vposr/hvposr wait to: write to channel 3 at 180 degrees
8) vposr/hvposr wait to: write to channel 2 at 270 degrees
9) fire up the audio DMA again

So the uneven scanlines are a problem, yes.

In my library, I do it this way: https://github.com/skeetor/amiga-uti...stemTakeover.s (line 21)

If running under Kickstart 2.0 or later you can check the EClockFrequency field in ExecBase.

That seems to work. Just need to multiply those values by 5 and get the clock for the audio.

This only indicates the power supply frequency which may or may not correspond to a PAL or NTSC system,
furthermore I seem to remember that in some condition there is a bug in the KS1.x in reporting this value.

Yep, this is good :), the only drawback is that is not working on KS1.x

Your audio value is not CCK*100?
As EClockFrequency (the base clock for CIA chips) is CCK/5 then you need EClockFrequency*500..

Just get the master crystal frequency for PAL/NTSC Amigas and divide it by 8 to get the Paula rate. Every clock (except keyboard) is derived from this crystal, even the video clocks.

The crystal frequencies are exactly 28.37516MHz for PAL and ~28.63636363MHz (repeating) for NTSC. These are nominal values, real case frequencies will be off by a small fraction because of crystal tolerances and possibly other external factors.

So nominal Paula rates are:
PAL: exactly 3546895Hz
NTSC: ~3579545.45Hz (repeating)

You could roll your own check, e.g. disable ints, wait for vblank, read e clock. Wait for a certain number of scanlines, read e clock again. The difference between readings should fall within two distinct ranges depending on Amiga crystal frequency.

No unfortunately, because all is tied to master clock.
You need two independent sources to do what you written.

Reading VFreq from Execbase is reliable - to reveal if the motherboard (and therefore the crystal, if Paula is used) is PAL or NTSC.

If you're turning off the system (say, for audio in games or demos), native modes are often used so that this is enough.

If you're running in Workbench, it's best to use system functions for audio if possible, and the user shouldn't have to change his or her Workbench screen mode to play audio correctly. There are both native and expanded high-horizontal-frequency modes.