Low-level workings of Paula

[absence]

Interesting bit about the volume implementation: http://blog.kebby.org/?p=11

[h0ffman]

No idea, however make your samples as load of they can go and turn them down with the Paula instead of making them quieter, you wont loose detail then

[mc6809e]

Originally Posted by absence

Interesting bit about the volume implementation: http://blog.kebby.org/?p=11

Very interesting.

I wonder if there's any way to control the phases of the counters or if they simply run continuously.

If a pair of volume counters can be made to run 180 degrees out of phase with one another, then samples can be made to interleave and samples with frequencies above 14KHz could be produced.

Perhaps turning a channel on and off also starts and stops the channel's respective counter.

Maybe Toni knows.

[Toni Wilen]

Interesting..

I'd assume there is only one counter shared by all channels and it is always counting. (Why waste gates for 4 counters when only one is enough and why bother with enable/disable input?)

It probably is as simple as: "unmute" all channels when counter wraps around (becomes zero) and "mute" it when channel's volume matches counter value (I'd assume equal comparison is much simpler than equal or larger than)

(Perhaps I am totally wrong but assuming and then finding test cases to either prove it wrong or right has worked for me so far..)

[absence]

Originally Posted by Toni Wilen

(Perhaps I am totally wrong but assuming and then finding test cases to either prove it wrong or right has worked for me so far..)

I recall a picture of an A500 you had hooked up with a million cables to do tests on. Is it possible to figure out if the assumption is right with that setup?

[absence]

Originally Posted by Toni Wilen

Because I am too lazy, you can post our findings to that thread, you can use my images if needed.

I guess main things are:

- each channel has own volume counter
- volume really simply works by switching DA output on and off.
- switching rate is exactly color clock / 64.
- volcntrld and counter reset was already sort of documented.

I'm lazy too, so I'll just paste the highlights from our discussion. Regarding the images, Toni measured from U14 (A500) and U15 (A1200) pin 14 due to difficulties with SMD. The LED filter was disabled, so only the fixed 6 dB/oct filter was active (U15, C321/331, R321/331 for left/right on the A1200, same circuit with different component numbers and values on the A500).

Originally Posted by Toni Wilen

AUDxDAT was 0x7070 (written only once. I also tested other values, the smaller value, the less the waveform changed when changing volume, as expected)

Only AUDxVOL was then changed.

5: VOL=1
6: 10
7: 20
8: 30

Originally Posted by Toni Wilen

Ok, A1200 test done..

7_1: vol=32
7_2: vol=10
7_3: vol=20
7_4: vol=1

Originally Posted by Toni Wilen

One more interesting note: channels are not in phase, _1.gif shows two channels with exact same dat and vol being in about 45 degree out of phase.

Originally Posted by Toni Wilen

Writing to DAT will reset vol counter (or when DMA audio starts)

This is actually documented in HRM audio state diagram. It has signal "volcntrld". It also talks about "volume counter". I guess everyone originally thought it is a mistake or something and ignored the "counter" part..

Test was: I wrote same word (0x7070) continuously to DAT (+also cleared intreq) and trace started jumping around randomly.

This needed very small period value to see it clearly because volcntrld only happens when DAT is written and audio state=0.

This proves that each channel has own volume counter.

Originally Posted by absence

The time constant for the A1200 filter matches the rise times in your latest measurements, which means that there is no filtering inside the Paula, and that there would have been straight pulses if the Paula was disconnected from the filter circuits.

Also thanks to kb (the blog author) for providing further insights by e-mail, and pointing out that by mentioning a number of ones and zeros the HRM hints towards a "PWM" counter: http://amigadev.elowar.com/read/ADCD.../node0017.html

Later I found another hint - modulated carriers only work at max volume: http://amigadev.elowar.com/read/ADCD.../node00F2.html

Finally, Toni saw the volcntrld in the audio state diagram: http://amigadev.elowar.com/read/ADCD.../node02DC.html

I'm not sure what those impulses during switching are. Possibly the scope probe is picking up noise from the components. I don't think they can be part of the audio signal, because the lowpass filter would eat them.

If anything is unclear or I have forgotten to include important details (quotes), feel free to ask.

[mc6809e]

Toni's comment about the counters being out of phase is interesting.

I bet the 45 degree phase difference is a result of the timing between writes to the DAT registers.

By setting the volume to 31 on two voices and by using the copper to start those voices 180 degrees out of phase relative to each other, it should be possible to produce an output with a sample rate twice the expected maximum via DMA methods by using one buffer to hold the even samples and a second buffer to hold the odd samples.

It might be worth losing a voice to get a nice crystal clear cymbal or snare drum sound at a 56KHz sample rate.

It's too bad this wasn't understood when Octamed was written.

[absence]

Originally Posted by mc6809e

I bet the 45 degree phase difference is a result of the timing between writes to the DAT registers.

That's right!

Originally Posted by mc6809e

By setting the volume to 31 on two voices and by using the copper to start those voices 180 degrees out of phase relative to each other, it should be possible to produce an output with a sample rate twice the expected maximum via DMA methods by using one buffer to hold the even samples and a second buffer to hold the odd samples.

That's an interesting idea. My poor A500 struggled enough with Octamed as it was, but faster Amigas could probably handle the mixing.

[Toni Wilen]

Mostly useless information: AUDxVOL register appears to be 7-bit. 64-127 = max volume, 128 = volume 0, 129 = volume 1 and so on..

EDIT: Volume range is also 0-64, 63 = output off one cycle (tiny pulse visible on scope), 64 = full volume, output enabled all the time (straight line on scope)

[Don_Adan]

Originally Posted by Toni Wilen

Mostly useless information: AUDxVOL register appears to be 7-bit. 64-127 = max volume, 128 = volume 0, 129 = volume 1 and so on..

EDIT: Volume range is also 0-64, 63 = output off one cycle (tiny pulse visible on scope), 64 = full volume, output enabled all the time (straight line on scope)

Not exactly, this is dependent to CPU too. Move.b #64,$DFF0A8 will be works for 68000/10/20/30, but it will be don't works for 68040/60.

[Toni Wilen]

Originally Posted by Don_Adan

Not exactly, this is dependent to CPU too. Move.b #64,$DFF0A8 will be works for 68000/10/20/30, but it will be don't works for 68040/60.

Yeah but it is CPU board feature, nothing to do with chipset.

EDIT: I meant only 7 lowest bits are in use in AUDxVOL. Not that register itself is 7-bit.

[StingRay]

Originally Posted by Don_Adan

Not exactly, this is dependent to CPU too. Move.b #64,$DFF0A8 will be works for 68000/10/20/30, but it will be don't works for 68040/60.

That's because of the byte write, value for the volume has nothing to do with it.

Edit: too slow again.

[Don_Adan]

Originally Posted by StingRay

That's because of the byte write, value for the volume has nothing to do with it.

Edit: too slow again.

Sorry you are wrong, if you use move.b #64,$DFF0A8, you have $4040 in $dff0a8 register for 68000 to 68030, but for 68040/68060 you have $4000 only (if $dff0A8 was null before), and yes only 7 bits are used.

[StingRay]

Originally Posted by Don_Adan

Sorry you are wrong, if you use move.b #64,$DFF0A8, you have $4040 in $dff0a8 register for 68000 to 68030, but for 68040/68060 you have $4000 only (if $dff0A8 was null before), and yes only 7 bits are used.

Which is because of the byte write to the volume register as I said before!

[Don_Adan]

Originally Posted by StingRay

Which is because of the byte write to the volume register as I said before!

It can be true only if byte write will be works identical for all CPU's, but it works different, dependent to CPU.

[hooverphonique]

Originally Posted by Don_Adan

Sorry you are wrong, if you use move.b #64,$DFF0A8, you have $4040 in $dff0a8 register for 68000 to 68030, but for 68040/68060 you have $4000 only (if $dff0A8 was null before).

If you use a byte write, I guess you have to write to $dff0a9 to set bits 6-0, but you're saying that on a 68000, performing "move.b #$40, $dff0a8" will actually be the same as performing "move.w #$4040, $dff0a8" ???

[Thorham]

From the link in the original post:

At some point in 2007 somebody told me how the Amiga’s sound chip, Paula, was able to modify a sound’s volume digitally without using multiplication – dedicated circuits for that would have been prohibitively expensive for a home computer in 1984: It simply has a 6-bit counter per voice that’s incremented every cycle and if its value is above the set volume, the voice is silenced for that cycle. So effectively it’s PWM with a pulse frequency of about 50Khz.

Can anyone confirm that this is actually true? Isn't a Paula simply 14 bit?

[Toni Wilen]

Originally Posted by Thorham

Can anyone confirm that this is actually true? Isn't a Paula simply 14 bit?

Scope tests above 100% prove it can't use 14-bit DAC:
- Pulses (Frequency = CCK/64) even when sample value does not change, except when volume is 64.
- Pulse width = AUDxVOL value.

I think 4x14-bit DACs would have been too expensive in early 1980s.

[Thorham]

Originally Posted by Toni Wilen

Scope tests above 100% prove it can't use 14-bit DAC:
- Pulses (Frequency = CCK/64) even when sample value does not change, except when volume is 64.
- Pulse width = AUDxVOL value.

Really? Well, that sucks then, because I've been telling people the thing is 14 bit Perhaps I'll write a program to test this just for fun

Originally Posted by Toni Wilen

I think 4x14-bit DACs would have been too expensive in early 1980s.

Seems odd considering Paula can handle sample rates of over a megabyte per second (or is that also untrue?).

[mc6809e]

Originally Posted by Thorham

Really? Well, that sucks then, because I've been telling people the thing is 14 bit Perhaps I'll write a program to test this just for fun

Seems odd considering Paula can handle sample rates of over a megabyte per second (or is that also untrue?).

The PWM frequency is 56KHz. This would seem to imply an upper limit of 56K samples per second. The volume counters are reset whenever a new sample is loaded for output, however, so as the output rate increases above 56K, the number of available volume levels effectively goes down but the output rate can continue to increase.

[Toni Wilen]

Originally Posted by Thorham

Really? Well, that sucks then, because I've been telling people the thing is 14 bit Perhaps I'll write a program to test this just for fun

I don't think it is possible to test this using only software.

Seems odd considering Paula can handle sample rates of over a megabyte per second (or is that also untrue?).

Digital part of Paula can handle it but I am quite sure DAC isn't fast enough.

[hooverphonique]

under normal circumstances, the highest number of samples per second possible is 28867. This means (according to Nyquist criteria) that the highest frequency sound you can play correctly is 28867/2 = 14434.

If the volume pwm counters run at a frequency of 56KHz and you want to use volume levels other than 64, this also limits the samplerate to ~28KHz (56/2) or you would get aliasing.

Considering this volume implementation, the hardware designers would be stupid to use anything but 8-bit DACs..

[Thorham]

Originally Posted by Toni Wilen

I don't think it is possible to test this using only software.

It can and is in fact simple enough. You'll need to program the audio using the CPU only, so you'll need an interupt-less environment. You then play a sample that's made up of only 127s. Next, you feed your test sample through the volume part. All you have to do is make sure you have a high sample rate sample. If Paula is 14 bit, then your sample should sound quite reasonable, if not, it should sound like absolute crap... or that's the idea.

Originally Posted by Toni Wilen

Digital part of Paula can handle it but I am quite sure DAC isn't fast enough.

It can still handle at least 84 Khz (Megalo Sound sampler and it's software allow this). Should be good enough for testing the above.

Originally Posted by hooverphonique

If the volume pwm counters run at a frequency of 56KHz and you want to use volume levels other than 64, this also limits the samplerate to ~28KHz (56/2) or you would get aliasing.

If that's true, then why does 44 Khz 14 bit sound so good on double scanrate? I use a VGA dongle on my A1200 so I can use 31 Khz displays, and playing anything that's CD quality, sounds very good. According to what you're saying, it shouldn't, or am I misinterpreting what you're saying (could be )?

[hooverphonique]

Originally Posted by Thorham

If that's true, then why does 44 Khz 14 bit sound so good on double scanrate? I use a VGA dongle on my A1200 so I can use 31 Khz displays, and playing anything that's CD quality, sounds very good. According to what you're saying, it shouldn't, or am I misinterpreting what you're saying (could be )?

Well, my previous statement might be wrong - it depends on if the 56KHz refers to counting from 0-64 or to count +1. If it's the latter, the chopping is so slow, that no aliasing effect would occur for high frequency content (it might for low frequency stuff, though).

When running in double scan, paula is able to play back higher samplerates using dma. If this also affects frequency of the volume counters, I don't know.

[mc6809e]

Originally Posted by hooverphonique

under normal circumstances, the highest number of samples per second possible is 28867. This means (according to Nyquist criteria) that the highest frequency sound you can play correctly is 28867/2 = 14434.

That is a misapplication of the Nyquist criteria.

The Amiga outputs samples. That is subtly different from sampling. One isn't necessarily trying to reconstruct a waveform. One instead tries to synthesize a waveform from a table of values (the Amiga hardware even supports wavetable synthesis by allowing one channel to modulate another's pitch or volume).

A two sample square wave output at 1000 samples per second, for example, will generate an infinite number of odd integer harmonics above 1000Hz -- 3000Hz, 5000Hz, or 17000Hz, or 19000Hz, etc.

Whether or not those frequencies are output depends on the details of the Amiga's output filter and not the sample rate.

[hooverphonique]

Yes and no.. It might be misapplication of Nyquist, I don't remember anymore, but it still holds true. How would you play back a wave of frequency 20KHz, for instance, if your max sample rate is 28KHz? By playing a lower frequency wave and then rely on harmonics? The smallest wave you can do contains 2 samples, so you cannot really create a direct wave of higher frequency than half the max sample rate..

[mc6809e]

Originally Posted by hooverphonique

Yes and no.. It might be misapplication of Nyquist, I don't remember anymore, but it still holds true. How would you play back a wave of frequency 20KHz, for instance, if your max sample rate is 28KHz? By playing a lower frequency wave and then rely on harmonics? The smallest wave you can do contains 2 samples, so you cannot really create a direct wave of higher frequency than half the max sample rate..

I think what you mean to write is that it isn't possible to produce a single sinusoid of 20KHz without also producing waves of other frequencies.

Okay. But I have to disagree with your suggestion that somehow harmonics aren't real frequencies that are output along with the fundamental.

The question was whether or not the Amiga can produce frequencies above 14KHz using DMA and no tricks. The answer is "yes".

The confusion comes from seeing the Amiga's audio strictly as a kind of sampler. It isn't just a sampler. It outputs arbitrary waveforms at variable rates up to 14K values per second per voice. It's a synthesizer. And synthesizers have a long history of relying on the higher-order harmonics of basic waveforms to develop sounds with a complex timbre. A single pure sinusoid of 20KHz is mostly useless. A lower frequency square wave and all it's harmonics, on the other hand, is very useful.

Where the Amiga's audio suffers is in the control of high frequency random noise above 14KHz.

[absence]

Wow, this thread went out of hand rather quickly and prooves audio is a little understood topic in the community...

[Don_Adan]

Originally Posted by hooverphonique

If you use a byte write, I guess you have to write to $dff0a9 to set bits 6-0, but you're saying that on a 68000, performing "move.b #$40, $dff0a8" will actually be the same as performing "move.w #$4040, $dff0a8" ???

Yes, it works as move.w #$4040, $dff0a8.
If you have A500 and Action Replay 3, you can trace Amiga registers, easy enough.

[Don_Adan]

Originally Posted by hooverphonique

under normal circumstances, the highest number of samples per second possible is 28867. This means (according to Nyquist criteria) that the highest frequency sound you can play correctly is 28867/2 = 14434.

If the volume pwm counters run at a frequency of 56KHz and you want to use volume levels other than 64, this also limits the samplerate to ~28KHz (56/2) or you would get aliasing.

Considering this volume implementation, the hardware designers would be stupid to use anything but 8-bit DACs..

Again this is no true (or not full true), 28867 limit is only for 4th Amiga channel, every Amiga channel has own limit. Maximum value is 29313 for first channel.

[mc6809e]

Originally Posted by Don_Adan

Again this is no true (or not full true), 28867 limit is only for 4th Amiga channel, every Amiga channel has own limit. Maximum value is 29313 for first channel.

Interesting.

Does that mean the allocation of the audio DMA channels per voice is not fixed?

[Toni Wilen]

Originally Posted by mc6809e

Interesting.

Does that mean the allocation of the audio DMA channels per voice is not fixed?

http://eab.abime.net/showthread.php?p=677012#post677012

[Thcm]

What happens if a Protracker module uses a lower period than 124? I'm currently working on a Protracker replayer for the c64 and I found a lot Amiga modules using lower periods.

[Toni Wilen]

Originally Posted by Thcm

What happens if a Protracker module uses a lower period than 124? I'm currently working on a Protracker replayer for the c64 and I found a lot Amiga modules using lower periods.

Sample word (=2x8-bit samples) keep repeating until new sample arrives.

[Photon]

Originally Posted by Don_Adan

Again this is no true (or not full true), 28867 limit is only for 4th Amiga channel, every Amiga channel has own limit. Maximum value is 29313 for first channel.

Originally Posted by mc6809e

Interesting.

Does that mean the allocation of the audio DMA channels per voice is not fixed?

Not practically, though. You would want to set a common software limit and let a sample be played in any channel and not be channel locked.

Originally Posted by Thcm

What happens if a Protracker module uses a lower period than 124?

It will sound shrill and rasping, for high-frequency instruments rather like the whistle of a referee. In other words, like crap. You can test this by starting Protracker, load a melody instrument, and then press U (or 0, depending on how high that version goes).

[pandy71]

Originally Posted by mc6809e

The PWM frequency is 56KHz. This would seem to imply an upper limit of 56K samples per second. The volume counters are reset whenever a new sample is loaded for output, however, so as the output rate increases above 56K, the number of available volume levels effectively goes down but the output rate can continue to increase.

Oh - I think that PWM clock is 3.58MHz - and probably similar architecture as C-64 SID was used in Paula - 8 bit DAC provide Vref for PWM.

This should be quite easy to check - set two samples identical value (AUDxDAT) then modulate PWM (AUDxVOL) even square wave (but fast - maybe with Copper help), scope connected to audio output before integrator (directly to Paula pin) should show real frequency for PWM - 56kHz seems to be very low clock and IMHO will create lot intermodulation distortions.

Limit 56kHz is related only to DMA not software driven audio (even HRM mention about 1.79MHz PWM audio)

[Toni Wilen]

Originally Posted by pandy71

Oh - I think that PWM clock is 3.58MHz - and probably similar architecture as C-64 SID was used in Paula - 8 bit DAC provide Vref for PWM.

It is 3.58MHz. ~56KHz * 64 (volume counter size) = 3.58MHz.

[pandy71]

Originally Posted by Thorham

Really? Well, that sucks then, because I've been telling people the thing is 14 bit Perhaps I'll write a program to test this just for fun
Seems odd considering Paula can handle sample rates of over a megabyte per second (or is that also untrue?).

Paula probably have 4x 8 bit DAC's and 4x 6 bit PWM attenuators - similar solution is used in SID from C-64 - this also can explain why there is 7 bit used to control PWM level (bypas PWM) - period time in PWM is divided from 0 to 63/64 ie to have full level for PWM=64 they need to bypass PWM which create in real life 65 values

Originally Posted by Toni Wilen

It is 3.58MHz. ~56KHz * 64 (volume counter size) = 3.58MHz.

So sampling frequency for PWM is 3.58MHz/64 samples per second - ie if someone decide instead using 8 bit DAC to produce audio, 6 bit PWM as DAC can't expect sampling frequency higher than this (Nyquist criteria). To avoid problems with higher DMA audio sampling frequencies - value 65 (ie bypas PWM ) for AUDxVOL must be used - perhaps someone can verify this on ECS or AGA (create video mode when H frequency will be much faster than VGA ie something like 60kHz - this probably imply video mode with 80 pixels for lowres)

[absence]

Originally Posted by pandy71

Paula probably have 4x 8 bit DAC's and 4x 6 bit PWM attenuators - similar solution is used in SID from C-64 - this also can explain why there is 7 bit used to control PWM level (bypas PWM) - period time in PWM is divided from 0 to 63/64 ie to have full level for PWM=64 they need to bypass PWM which create in real life 65 values

Correct, that's what Toni's measurements confirmed.

Originally Posted by pandy71

So sampling frequency for PWM is 3.58MHz/64 samples per second - ie if someone decide instead using 8 bit DAC to produce audio, 6 bit PWM as DAC can't expect sampling frequency higher than this (Nyquist criteria).

With all respect it sounds like you're confusing the Nyquist theorem with amplitude modulation.

Originally Posted by pandy71

To avoid problems with higher DMA audio sampling frequencies - value 65 (ie bypas PWM ) for AUDxVOL must be used - perhaps someone can verify this on ECS or AGA (create video mode when H frequency will be much faster than VGA ie something like 60kHz - this probably imply video mode with 80 pixels for lowres)

I don't think there's anything special about the Paulas used in ECS or AGA, so there's nothing to verify. Faster DMA doesn't affect the modulation.

[pandy71]

Originally Posted by absence

Correct, that's what Toni's measurements confirmed.

Yep - never claimed anything else.

Originally Posted by absence

With all respect it sounds like you're confusing the Nyquist theorem with amplitude modulation.

Why?
This is circuit with two DAC's in series and one of them can be bypassed.

To add more details - max frequency that can be reproduced by PWM DAC in Amiga is half 3.58MHz/64.

Originally Posted by absence

I don't think there's anything special about the Paulas used in ECS or AGA, so there's nothing to verify. Faster DMA doesn't affect the modulation.

Yes, and i never claimed that there is ECS or AGA Paula - verification in ECS or AGA system can be easier due fact that video sequencer is programmable and H line can be shorter thus H frequency higher and DMA data can be feed to Paula faster than 56ksps - then verification for internal architecture should be easier (however i think that at least in theory H line can be shortened also on OCS by access cycle to correct STR* strobe registers). And faster DMA can affect modulation when modulation one channel to another is active - (however only one byte from word is used) - limitations for internal Paula architecture can be easily exposed when H line will be really short.