Minimum safe Paula periods for PAL Amigas

[8bitbubsy]

So, we can agree that Paula can play rates up to 28867Hz in the normal screen modes, right?

Well consider this... Imagine ProTracker, and the notes and periods in it.

A#3 is 29557Hz (3546895 / 120 = ~29557.45Hz)

Yet A#3 plays fine. How's this possible? A#3 is above 28867Hz which is said to be the max frequency in normal screen modes.

2020 edit: A#3 didn't really play fine, I guess it was just one of those cases where the sample timbre made it hard to hear the crack/pops.

[Toni Wilen]

Each channel has different max rate: http://eab.abime.net/677060-post9.html

[8bitbubsy]

That's interesting indeed. I guess that solves the mystery. Thanks!

- 30.05.2020 edit after doing tests on real Amigas -

Minimum safe PAL period values in normal video modes:
Channel #1: period 121 (29313.18Hz)
Channel #2: period 122 (29072.90Hz)
Channel #3: period 123 (28836.54Hz)
Channel #4: period 124 (28603.99Hz)

Max safe notes (w/ finetune) for ProTracker:
Channel #1: A#3 (finetune -1)
Channel #2: A-3 (finetune +6)
Channel #3: A-3 (finetune +5)
Channel #4: A-3 (finetune +4)

So period 124 (28603.99Hz - A-3 finetune +4) is the minimum safe period for PAL Amigas.

[Photon]

Minimum recommended period is 123, this gives 3546895/123 = 28836.544715447154471544715447154 Hz.

The DMA fetch, however, is faster: 15734 Hz * 2 samples per scanline = 31468 Hz. This is the limit you seem to pass when testing.

HRM slips in a suspicious note, that "28867 is also the maximum sample rate for PAL systems."

It sounds more like someone decided that, than a factual limit. (And of course the 123 period limit makes the statement even stranger.) Perhaps it has to do with inaudible specs of other parts of the hardware than the fetch itself. Or they may write this to ward off any attempts to go faster to use the audio output for something other than playing music to human ears.

An oscilloscope+a long waveform, at least 314*2 samples, should verify whether the 28867 cap is just for convenience or for guaranteed fidelity of output.

Note that you should select a minimum period from which you can round to periods without too much frequency abberation. It makes good sense in a music program to base a scale on a period a bit above minimum period for the sake of vibrato sounding proper.

The baseA constant in the example I gave you in your other thread is such a scale base that I tested out.

[Toni Wilen]

Everything has been confirmed long time ago. (Check linked thread and others that mention DMAL)

Different channel limits are simply due to way Paula and Agnus communicate. Paula generates sort of bit mask that contains which channels need new data from Agnus at the beginning of each scanline, this data is then serially transmitted to Agnus, one bit/cck. (This also includes disk read and write DMA slots)

All channels' request bits are generated (or more like loaded to separate shift register) at the same time but because each audio DMA channel has different DMA slot position, lowest numbered channel has smallest "dma latency", next has 2 cycles more (=1 period count) and so on.

In other words, minimum time that is needed for Paula to request DMA and Agnus writing to requested AUDxDAT: length of one scanline + position of channel's DMA slot.

PAL/NTSC is not tested (at least not by me) but NTSC alternating long/short line may affects audio period limits by 1 cycle.

[mc6809e]

Originally Posted by Photon

An oscilloscope+a long waveform, at least 314*2 samples, should verify whether the 28867 cap is just for convenience or for guaranteed fidelity of output.

If each sample pair could be made to expire at the same point during each scanline then the 31468 rate could be achieved.

The problem is that there is no value that can be loaded into the period counter to keep the sample outputs in constant phase relative to Agnus' DMA fetches. At some point a sample pair will expire immediately after the first refresh cycle but before DMA fetch. At lower sample output rates this is fine, but at higher rates a sample fetch is missed.

The only way to get DMA driven audio to output close to the 31468 rate might be to use the COPPER to set the period register to 113 on even scanlines and 114 on odd scanlines so that the sample pair always expires at roughly the same place between the end of audio DMA and the first refresh cycle. The copper would also have to initiate audio output.

[Photon]

Exactly. I was addressing the gist of the original question, what frequencies Protracker (normal DMA driven) playback can reach vs. what's said in HRM. 8bitbubsy is checking PT's period tables and wants to know how the high notes behave (right?).

Just wanted to make clear that since the cap is 123, 28836 Hz is max and that ends it for DMA purposes regardless of the fine points of behavior of the hardware beyond that.

Software driven audio can already reach lower periods, so... (btw, Your 113/114 trick will need to use CPU wait in the early part of the frame, since the copper can't match vpos below $1c or whatever it was.)

I meant to show only the reasons why lower periods may sound okay to the ear.

[mc6809e]

Originally Posted by Photon

Software driven audio can already reach lower periods, so... (btw, Your 113/114 trick will need to use CPU wait in the early part of the frame, since the copper can't match vpos below $1c or whatever it was.)

Are you sure about this? I've seen demos that have copper waits for vpos =>3 that seem to work fine.

Since the copper doesn't have access to the highest bit of vpos, how can it work for lines > $ff if it can't match lower than $1c?

And what about simple copper loops that wait for every other line with most of vpos masked out? The copper only sees 0, 1, 0, 1, 0, etc.

Maybe you mean something else.

[whitebird]

The problem is that there is no value that can be loaded into the period counter to keep the sample outputs in constant phase relative to Agnus' DMA fetches.

How the playback frequency actually accomodates to the DMA fetches frequency?

Does Paula anticipate telling agnus to load 2 new samples so that the slot within the scanline is not missed or some samples are played for a longer period of time (which would probably give strange sound output)?

[8bitbubsy]

I edited my third post with what seems to be the actual minimum safe period values for PAL Amigas. Period 123 (28836.54Hz) is definitely unstable on channel #4 on both my A1200 and A600, so I think that the Amiga Hardware Reference Manual is simply wrong with its Paula PAL notes. They claim that 28867Hz is the max safe frequency for both NTSC and PAL, and this makes little sense to me as all the clocks differ on PAL systems.

[daxb]

There is also a test tool for this: http://aminet.net/package/driver/audio/MaxReplayTest

[8bitbubsy]

Nice. It also shows period 124 as being max for the normal PAL video mode.

[daxb]

Yes, I got the same result (period 124) on A1200 PAL.

[ross]

For reference this is a formula that works for any HTOTAL:

minimum AUDxPER = (HTOTAL+16)>>1+channel

Explanation:
+1: HTOTAL to totalCCK per line
+8: Paula to Agnus DMAL delay
+6: floppy DMA setup bits
+1: align for successive shift
>>1: samples per word
channel: (AUDxDR and AUDxDSR bit * c)>>1

Example: PAL (HTOTAL 226), channel 3
(226+16)>>1+3=124

It is not the empirical formula you find in MaxReplayTest, this is the motivated one

[Photon]

It says both 123 and 124 in HRM, it would seem we can't go below 124 (from a decision, as HRM says, to save hardware buffers (but still has the figure 28867 everywhere). 28603(.99)Hz is the max PAL sampling rate then, whatever HRM says. And odd and even scanlines are both long, whatever HRM says.

So: 124.

Edit: I speak of PAL only.

[ross]

Well, actually 28867 is the proper frequency for a period of 124 in NTSC.
7159090/2/124=28867

So probably HRM report old value when only NTSC Amiga existed.

And also about the scanline length.
If you use an NTSC Agnus or you force NTSC mode in ECS/AGA or you don't use LOLDIS in programmed mode, for sure you have alternating short and long lines

EDIT:
But probably a clarification regarding the long and short lines must be made, because it could be misinterpreted.
Even if Agnus in NTSC mode counts (from 0) up to HTOTAL and HTOTAL + 1 alternatively, the horizontal frequency is constant because a delay circuit is applied to the sync signals, therefore all the lines have a horizontal frequency of (CCK_clock / (HTOTAL + 1.5)).

[Photon]

I spoke of PAL only. (Edited to clarify )

[b]3546895[b/] is the number in my HRM for PAL. 3546895/124 < 28867 Hz, but HRM still says 28867 Hz is valid for PAL, and it seems there's evidence in this thread that this is incorrect. (Errors in HRM are rare! It's normally the Bible.)

NTSC clock is slightly faster, so the Hz is higher.

[ross]

Originally Posted by Photon

..but HRM still says 28867 Hz is valid for PAL

HRM is wrong here, no doubt
At least for channels 2 and 3.
Channel 0 can go up to 29313Hz instead.

Maybe it made an average

EDIT:
I really tried to average (which obviously doesn't make any sense) and the value is 28957Hz

[8bitbubsy]

Yeah, 28603.99Hz (period 124) is confirmed to be the lowest safe period on PAL Amigas in normal video modes. At least during common DMA acitivity.

[ross]

I can think of two ways to have a higher frequency in PAL using the copper with a synchronized writing per line (therefore usable also for a normal display without having to rebuild the copper list at each frame using some improbable wait positions for video effects..).
The first with a period of 114 (31113Hz) and 4 8-bit channels, but complicated regarding the synchronization
The second with a period of 113.5 (31250Hz) with 2 '9-bit' channels (or 4 'interlaced' 8-bit at 15625Hz), but quite easy about the sync.

But I don't want to think about it too much otherwise I want to try it.