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.