New in V0.9a:
Fixed an issue in the PAL / NTSC detection with Kickstart 2.0.
New in V0.9:
Nothing fundamental new: now you can change the frequency of test tone
(100 - 5000 Hz) and toggle the hardware audio filter off and on.
In the good old OCS times Paula and Audio was quite simple as there were
only NTSC and PAL Amigas. On both systems the maximum replay rate for
audio was something around 28.6 kHz.(*) With the upcoming of ECS and AGA
the maximum replay rate also increased and Amiga magazines and other
sources talked about a doubled maximum rate when using the new screen
modes i.e. something around 57.2 kHz.
But what is the real maximum replay rate using a specific screen mode?
I could not figure it out for over 20 years! :-( But now, everything
is different! :-D
(*) there seems to be a second difference i.e. audio playback using the
audio.device vs. "direct DMA". As I only use the audio.device and do not
really understand the direct DMA playback, I am only talking about Paula
in combination with the audio.device.
Setting up the replay rate
If you play sounds using the audio.device you have to create an AudioIO
Request. In this structure you enter information about the memory
location of the audio data to be played, the volume and some more, but
there is no entry for a replay rate, only mysterious "period" !? This
period is calculated using the colorclock and the replay rate i.e.
period = colorclock / replay rate
whereas colorclock is 3579545 Hz for NTSC systems (the hardware, not the
screen mode!) and 3546895 Hz for PAL systems. (*)
Altogether this means: the lower the period, the higher is the resulting
replay rate. In order to get to know the maximum replay rate you need to
know the minimum period. Regarding to the Autodocs the minimum period
is 124. Obviously this part of the Autodocs was never updated when ECS
and AGA were introduced.
(*) for sure you recognized the resulting limitations!? i.e. if you want
to replay with 22050 Hz (= 1/2 CD), on a PAL system the period is 160.8
which has to be rounded to 161 or 160. So the real resulting replay rate
is 22030 Hz or 22168 Hz but not 22050 Hz!! => the lower the period gets,
the bigger are the steps from a replay rate to the next one. For 44100 Hz
(= CD) this means you have to choose between 44336 Hz or 43788 Hz!
What is the minimum period?
By a few simple tests I could figure out, that the DBLNTSC, DBLPAL and
Productivity as well as Euro72 were capable to replay at least 44100 Hz.
On the other side Super72 does not manage the 44100 Hz.
=> there is a connection between the screen mode and the max. replay rate
=> to replay with ~44100 Hz a period of 80 is required, therefore the
124 mentioned in the Autodocs is for sure no more true
To learn more about Graphics and Chip-Ram and how they affect Paula
I opened the thread "Grafik, Chip-Ram und Paula" in the A1K.org forum.
There I got lots of feedback and explanations as well as the correct
key-words to search for.
=> the final answer I found in the EAB forum in a posting from Toni
Wilen (the WinUAE developer!) in the "15 bit 44 khz audio idea." thread.
min period = (color clocks in horizontal line + 13) / 2 + channel
And yes, you're reading correctly: every of the four Paula audio channels
has a different min period and therefore a different max. replay rate!
So to say, channel 0 is "the best" and channel 3 "the worst".
Now my goal was to write a program which is able to determine the
Paula's maximum replay rate and compare the "heard" results with above
formula in dependence of the used screen mode!
=> MaxReplayTest is the result! :-)
Don't talk so much! How do I use MaxReplayTest?!
!! Warning !!
!! Turn down the volume before starting MaxReplayTest !!
After starting up a sine sound is played and depending on the volume
setting of your amplifier / speakers this sound may be very loud !!
So don't blame me if your speakers or your ears blow up, you have been
1) Run MaxReplayTest from Shell or Workbench and select a screen mode
(and change the number of colors if you want i.e. to increase the
load on the Chip-Ram). The GUI opens and a sine sound is played on
channel 3 (the "worst" one) maximum replay rate (*).
(*) unfortunately Toni's formula does not match the findings on my
A1200. So I adapted his formula a little bit:
min period = (color clocks in horizontal line + 13 +1) / 2 + channel +1
a) Assumed that the adapted formula is "correct" channel 3 should play
at its maximum replay rate. Now decrease the period one by one and
therefore increase the replay rate to the next step.
If you start to hear glitches or other parasitic noise effects, then
the period is too low i.e. the replay rate is too high!
=> Congratulations, you found the maximum replay rate of the tested
Caution: it may take some to several seconds until you can hear a
glitch, in other cases the glitches can repeat very quickly.
Therefore don't decrease the period too quickly!
Note: if you further decrease the period, sooner or later the
glitches may disappear and the sine sound starts to sound too
low-pitched as the replay rate no more increases!
Go on with the next channel i.e. channel 2, press "set max" in order
to set the replay rate to the maximum calculated level and start to
decrease the period.
Afterwards repeat the procedure with channel 1 and 0.
b) In the case you hear glitches right from startup or you can't provoke
glitches by decreasing the period, try the other way round, increase
the period. For whatever reason, perhaps the replay is already too
2) MaxReplayTest scanmodes
shows some relevant technical data and the maximum replay rate of the
installed screen modes e.g.:
Monitor total color clocks min. period max. sampling rate
SUPERPLUS 232 -> 127 cc -> 27928 Hz
A2024 226 -> 124 cc -> 28603 Hz
EURO36 226 -> 124 cc -> 28603 Hz
Film24 226 -> 124 cc -> 28603 Hz
NTSC 226 -> 124 cc -> 28603 Hz
PAL 226 -> 124 cc -> 28603 Hz
HD720 196 -> 109 cc -> 32540 Hz
XTREME 192 -> 107 cc -> 33148 Hz
HighGFX 160 -> 91 cc -> 38976 Hz
SUPER72 153 -> 87 cc -> 40768 Hz
DBLNTSC 129 -> 75 cc -> 47291 Hz
DBLPAL 129 -> 75 cc -> 47291 Hz
EURO72 121 -> 71 cc -> 49956 Hz
Productivity 121 -> 71 cc -> 49956 Hz
MaxReplayTest is "Feedbackware"
Yes, not Shareware, not Freeware, not Crippleware, but Feedbackware! :-)
This means, if you use MaxReplayTest, then please give feedback on which
Amiga with which chips(et) you tested which screen mode (and the number
of colors) and what the resulting maximum replay rates for the four
channels were! :-)
But why this?
Well, there are more differences between the different Amigas than only
OCS, ECS and AGA!
The OCS A1000 & A2000A are quite 'similar' but the A500 and A2000B & C
are different to the first two. In addition, there are A500 and A2000
with a 1 MB Chip-Mem Agnus and some of them are even equipped with a
2 MB Chip-Mem Agnus and may even have an ECS Denise!
On the ECS side, the A3000 is a real 32 Bit Amiga i.e. everything
including the Chip-Mem is 32 Bit wide. The A500+ and A600 are also ECS
but they are still only 16 Bit Amigas i.e. the Chip-Ram is only 16 Bit
wide. In addition, in opposite to the A500+ the A600 is manufactured
in SMD technology.
=> it would be interesting to figure out if these differences have an
effect on the maximum replay rate. That's why I ask for feedback! :-)
V0.9a 22.11.2020 fixed an issue in the PAL / NTSC detection
V0.9 09.11.2019 change frequency of test tone, toggle hardware audio
filter off and on
V0.8 30.12.2018 added the "set max" button, first Aminet version
V0.7 13.11.2018 "final" version
V0.6 02.04.2018 cleaned up the GUI
V0.5 20.03.2018 added the "scanmodes" option
V0.4 19.03.2018 the number of colors for the screen can be selected
V0.3 28.02.2018 now also works on Kickstart 2.0 with Workbench 2.1
V0.2 27.02.2018 first functional version, OS 3.0 or higher required
V0.1 27.02.2018 first version with a different approach which did not
work as intended
I tested MaxReplayTest for hours and it caused no problems on and to my
system. Afterall you use MaxReplayTest on your own risk!
MaxReplayTest is pushing the (audio) hardware to its limits!
MaxReplayTest is for testing purposes only.
=> therefore MaxReplayTest is for people who know what they do and know
how much stress they can expect from their hardware without causing
damage to their hardware.