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

[orangespider]

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:

; PAL VERSION
; d0 - frequency*100 (unsigned longword)
	move.l	d0, d1
	lsr.l	#1, d1
	move.l	#354687500, d2
	add.l	d1, d2
	divu.l	d0, d2
; d2 - AUDxPER


; NTSC VERSION
; d0 - frequency*100 (unsigned longword)
	move.l	d0, d1
	lsr.l	#1, d1
	move.l	#357954600, d2
	add.l	d1, d2
	divu.l	d0, d2
; d2 - AUDxPER

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.

[ross]

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

[Thomas Richter]

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.

[ross]

Originally Posted by Thomas Richter

That tells you the vertical frequency of the currently active screen mode ..

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.

[orangespider]

Originally Posted by ross

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

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

; d0 - frequency*100
	move.l	#354687500, d2
	move.w	vposr, d1
	and.w	#$1000, d1
	beq	.skip
	move.l	#357954600, d2
.skip:
	move.l	d0, d1
	lsr.l	#1, d1
	add.l	d1, d2
	divu.l	d0, d2
; d2 - AUDxPER

[ross]

Originally Posted by orangespider

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

[ross]

Just noticed.. you sure used values are perfect?

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

[orangespider]

Originally Posted by ross

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.

[ross]

Originally Posted by orangespider

I calculated the PAL one, don't remember where I got the NTSC from. Got the PAL as 227*15625 = 3546875. They so 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

[orangespider]

Originally Posted by ross

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

[ross]

Originally Posted by orangespider

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?

[orangespider]

Originally Posted by ross

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.

[sparhawk]

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

[mark_k]

Originally Posted by orangespider

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.

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

[orangespider]

Originally Posted by mark_k

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.

[ross]

Originally Posted by sparhawk

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

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.

Originally Posted by mark_k

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

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

Originally Posted by orangespider

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

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

[8bitbubsy]

Originally Posted by orangespider

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.

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)

[mark_k]

Originally Posted by ross

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

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.

[ross]

Originally Posted by mark_k

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.

[Photon]

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.