3 upvotes, 2 direct replies (showing 2)
View submission: PAULA 3.0 UPDATE
This is very cool
I'm still a bit confused about this:
dynamically alters the sample rate based on the note played.
Did the Paula chip do this? I thought the sample rate was fixed for anything that was already in-memory.
Comment by DigitalShrine at 03/03/2025 at 16:18 UTC
6 upvotes, 1 direct replies
I took the idea from protracker 2 clone. As it has its own resampling capabilities that allow you to resample to key corresponding to a specific sample rate.
Comment by GwanTheSwans at 03/03/2025 at 19:05 UTC*
2 upvotes, 0 direct replies
I think may be talking about slightly different things here but it's just up to you as the programmer what sample rate you play back the in-memory data with for a Paula DMA op, with Paula. Function of audio period chip registers of Paula. So the exact same 8-bit audio data in memory can just be played back at very different rates, and often was to play at different "notes".
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0016.html
This register contains the period (rate) of audio channel x DMA data transfer. The minimum period is 124 color clocks. This means that the smallest number that should be placed in this register is 124 decimal. This corresponds to a maximum sample frequency of 28.86 khz.
Table of periods in Amiga Hardware reference. Some confusing stuff, but ultimately result is the sample rate at playback is just up to you within the limits of the hardware, though there's a lot of subtleties I'm skipping (see Toni Wilen comments in linked abime thread hah)...
This is very different to modern hardware that may prefer to work at a constant 44100Hz, say. Well, it may still be some more flexible programmable dsp chip underneath but people almost never think of it that way now, it's just "THE sample rate IS 16-bit stereo 44100Hz ...and we'll change the data itself for any effects" not "we'll change the actual hardware sample playback rate on the fly in fine-grained fashion for effects". And thus you have to emulate the latter, munging the data to feed into the former, for authentic-sounding playback of Amiga Paula stuff on the constant-rate hardware.
1: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00F0.html
2: https://eab.abime.net/showthread.php?t=113542
There was a particular old quirky set of paula period values /frequencies used for each "note" in original ProTracker
https://16-bits.org/ptfreq.php[3] https://www.pouet.net/topic.php?which=8628[4]
3: https://16-bits.org/ptfreq.php
4: https://www.pouet.net/topic.php?which=8628
Now, some middle-C note sample data could well have been sampled at higher rate like 22050Hz anyway, so you had to either pretranspose it or do things like using F-3 for it in protracker despite it being a middle-C note, since the *sample* was of a middle-C note but at the ~22kHz that is near the denoted-as F-3 sample playback frequency in protracker. But also a lot of the time people would in fact have sample a middle C note at around ~8kHz (not to be confused with the standard middle-C sine wave pitch frequency of 261.6Hz, that's different), that would then basically work (pitch-wise) as per linked table at a bunch of the other notes too.
Actually I'm also totally glossing over how everything *really really* worked - Paula was *really really* a sort of 3.5MHz (far beyond normal audio frequency obviously) constant-rate hardware just being fed by the DMA, holding each value for the given period.
To understand what goes on with the Amiga sound chip, Paula, is to understand that Paula does no interpolation of any kind. Paula's output is strictly a pulse wave,
produced on 3546895 Hz frequency, which is the Paula clock rate for PAL systems.
The Amiga period values, typically valued somewhere between 120 and 800, count Paula ticks. For instance, a period value of 400 means that Paula waits 400 ticks holding
the output constant, and then changes to the next sample.
To simulate this perfectly, we would produce an output sample stream at that 3.55 MHz rate, one sample per tick, and then simply hold the output constant while counting down to zero from the period value, then switch to next sample, reset period clock back to original value, and so on. This stream would be very accurate representation of the Paula's output.