Paula ROCKS!

[KONEY]

Paula's sound texture is UNIQUE

[chip]

Paula music is my favorite since the last 6 years

Paula rulez

[Hewitson]

To someone with an electronic background, there's nothing fascinating about Paula from a design point of view. In fact the SID was a far more impressive design.

There's just something about the sound though. Amiga mods or emulators never sound quite right, it's almost like there's something missing.

[buggs]

Originally Posted by ross

I assumed that the counter counts up (like the video h cck counter) and AUDxVOL is a barrier.
This is because the PWM [sampling*] is at constant frequency (55420Hz) and need to mute the sample at defined position (i.e. for a AUDxVOL=$3E you have only two muted pulse and a very high volume).

Yes, exactly. Since the OpAmp behind Paula is tuned for impulse inputs, you can't use wider impulses for the desired lower Amplitude. That's the explanation why Paula subtracts the previous impulse (with an impulse of opposing sign) after the timer corresponding to the desired volume expires. While the approach and effect are comparable to a PWM, the waveform itself isn't.
I've observed that the regualar (55kHz) subtraction cycle still shows an impact on the RCA output (on A500, sorry that I didn't take a picture).
Back on topic: I've attached three pictures to illustrate how the volume control is carried out (2 sample square wave 0x7f80, period 8192). The lower trace is at full volume 64. The upper traces show volume 16, 32 and 48. Of note is how the negative impulse after a positive impulse moves further to the right with increasing volume setting.



So even for very low desired volume, the output impulses are still at full level and will be canceled out at the earliest possible moment (min. interval 282ns).

One interesting tidbit is that at full volume 64, all samples are output as "one shot", while for lower volumes the add/subtract cycle repeats with a rate of 55.4 kHz.

[roondar]

Originally Posted by Hewitson

To someone with an electronic background, there's nothing fascinating about Paula from a design point of view. In fact the SID was a far more impressive design.

Now, I have no electronics background at all but even so this does seem to me to be underselling what the chip actually does.

See, Paula is much more than just the audio parts (it has a number of additional functions). And even the audio parts are apparently deceptive in how simple they may or may not be (as far as this thread seems to imply anyway). I certainly haven't heard of other consumer oriented DAC based designs from the 1980's that run at 3.5MHz internally.

This alone is an interesting design choice to me, as it allows the Amiga to do something that most DAC's definitely do not do (even to this day): play back samples at a (more or less) arbitrary sample rate, rather than using a small set of pre-defined rates.

[ross]

Originally Posted by buggs

.. Since the OpAmp behind Paula is tuned for impulse inputs, you can't use wider impulses for the desired lower Amplitude -- cut --

Thanks, very interesting scope images.
This seems to clarify without a doubt how the volume works

I repropose:

Originally Posted by ross

But what happens when I've a sample play and I write to volume register a value lesser than the running counter?

If the AUDxVOL barrier is not hit there can be, for a 55.4Khz quantum, the described "one shot" (so a sample at full volume).
The designers will have thought of a 'protection' for this possible problem, or have they simply decided to ignore it because of minimal impact (a possible small click)?

EDIT:
Thinking about it, there is a very simple solution. Other Paula's registers are buffered and written deferred to the 'real registers'.
xLC and xLEN when internal_len 1 -> 0, xPER -> internal_per when sample -> out.
I always thought the volume was "immediate".
But if internal_vol is set to xVOL only when PWM_counter overflows? (so updated at 55.4KHz freq.)
This could solve the possible 'click'!

[frank_b]

Originally Posted by Thomas Richter

Note well, I'm not implying that a DAC is simple, just that it was state of the art at the time Paula was designed. SID was certainly a unique piece of work, and the first music synthesizer for consumer devices in a chip I am aware of. The same kind of unique work the Atari 8 bit chipset was, and which was the basis for the Amiga chipset.



The Atari ST "Yamaha" sound is not worth mentioning. Even the old Atari 8-bit Pokey could do better than it. It was just a convenience choice, but certainly not a breakthrough.

YM sounds quite good these days with the modern SID voice/buzzer effects. [ Show youtube player ] Lots of good chip music.
I like Paula and the SID too. Pokey always sounds out of tune to my ears though.

[buggs]

Originally Posted by coder76

Yes, this is true, but the needed ~31 kHz screenmodes do not work well on ECS, they have very limited colors and are slow too compared to AGA. That's why the 56 kHz DMA rate is not so useful under ECS chipset.

Well, I bought my Cybervision64 around 1995 and never had much motivation to go back to plain ECS/AGA screen modes for more than occasional testing. But you are right about the severe ECS limitations. Even on the A3000 with 32 Bit ChipRAM Doublescan modes are slow.

[8bitbubsy]

Originally Posted by ross

I repropose:

If the AUDxVOL barrier is not hit there can be, for a 55.4Khz quantum, the described "one shot" (so a sample at full volume).
The designers will have thought of a 'protection' for this possible problem, or have they simply decided to ignore it because of minimal impact (a possible small click)?

EDIT:
Thinking about it, there is a very simple solution. Other Paula's registers are buffered and written deferred to the 'real registers'.
xLC and xLEN when internal_len 1 -> 0, xPER -> internal_per when sample -> out.
I always thought the volume was "immediate".
But if internal_vol is set to xVOL only when PWM_counter overflows? (so updated at 55.4KHz freq.)
This could solve the possible 'click'!

Again, I think the barrier will always be hit. Changing AUDxVOL probably doesn't change the internal working registers directly. Just like AUDxDAT and AUDxLEN. They are read from the state machine when the LEN counter has reached 0 (or on DMA retrigger). So I would assume it's the same for AUDxVOL and AUDxPER. We need Toni to confirm how it works.

[buggs]

Originally Posted by ross

If the AUDxVOL barrier is not hit there can be, for a 55.4Khz quantum, the described "one shot" (so a sample at full volume).
The designers will have thought of a 'protection' for this possible problem, or have they simply decided to ignore it because of minimal impact (a possible small click)?

Frankly, I did not dive into this as of yet. Most parameters are latched and I would assume for now that this applies to the xVOL as well (until proven otherwise).
Actually, I sincerely hope that this assumption holds. Otherwise, it'd be harder to aim for the still pending additional bit in dynamic range.

[ross]

Originally Posted by 8bitbubsy

Again, I think the barrier will always be hit. Changing AUDxVOL probably doesn't change the internal working registers directly. Just like AUDxDAT and AUDxLEN. They are read from the state machine when the LEN counter has reached 0 (or on DMA retrigger). So I would assume it's the same for AUDxVOL and AUDxPER. We need Toni to confirm how it works.

Originally Posted by buggs

Frankly, I did not dive into this as of yet. Most parameters are latched and I would assume for now that this applies to the xVOL as well (until proven otherwise).
Actually, I sincerely hope that this assumption holds. Otherwise, it'd be harder to aim for the still pending additional bit in dynamic range.

Yep, the guess about xVOL set at the PWM_counter overflow seems the most logical

It is verifiable, readind the same wave in two different set-up:
- set a period of 128
- first read with a copper list with two consecutive writings to AUDxVOL of two different values, the second of which is the default one
- second read without volume modification (the default one)
- the two value need to be very different and <64
- the copper must be synchronized to write every 64 cck (if possible in the middle area of the PWM cycle)
- compare the waveforms

[ross]

Ok, code time:

	section	pwmvolumetest,code_c

pwmcenter	equ	14+28+1
volume1		equ	15
volume2		equ	63

Start
	lea	$dff000,a6
	move.w	#$7fff,$9a(a6)
	move.w	#$005f,$96(a6)
	move.w	#$00ff,$9e(a6)
	lea	c0(pc),a0
	move.l	a0,$80(a6)

	lea	wave(pc),a0
	move.l	a0,$a0(a6)
	move.w	#16,$a4(a6)
	move.w	#128,$a6(a6)
	move.w	#volume2,$a8(a6)

	lea	copperlist1(pc),a0
	lea	copperlist2(pc),a1
	lea	cl+8(pc),a5
	move.l	a1,-(a5)
	move.l	a0,-(a5)

	moveq	#pwmcenter,d7	; h
	bsr.b	genlist


	move.w	#311,d0			; penultimate line
waitl:
	move.w	6(a6),d1
	swap	d1
	move.w	4(a6),d1
	rol.l	#8,d1
	andi.w	#$1ff,d1
	cmp.w	d1,d0
	bne.b	waitl
	
.ll	cmpi.w	#$3840,6(a6)
	blo.b	.ll
	move.l	(a5),$80(a6)
	move.w	#$0120,$96(a6)
	move.w	#$8001,$96(a6)
	move.w	#$7fff,$9c(a6)

.go	moveq	#$20,d0
	and.w	$1e(a6),d0
	beq.b	.go
	move.w	d0,$9c(a6)

	movem.l	(a5),a0/a1
	exg	a0,a1
	movem.l	a0/a1,(a5)
	
	bsr.b	genlist
	
	move.l	(a5),$80(a6)
	bra.b	.go


genlist
	move.w	#227,d6			; 227
	moveq	#$40,d5
	lsl.w	#2,d5			; #$00000100
	moveq	#1,d4
	swap	d4			; #$00010000
	moveq	#-2,d3
	moveq	#64,d2
	moveq	#0,d0			; line

.nl	moveq	#1,d1
	or.w	d0,d1
	or.b	d7,d1
	move.w	d1,(a0)+
	move.w	d3,(a0)+
	move.l	#$00a8<<16|volume1,(a0)+
	move.l	#$00a8<<16|volume2,(a0)+
	add.w	d2,d7
	cmp.w	d6,d7
	blo.b	.nl
	sub.w	d6,d7
	add.l	d5,d0
	cmp.l	d4,d0
	bne.b	.nl

	cmpi.w	#$ffd3,d1		; copper y-roll fix
	bne.b	.n2
	moveq	#2,d4
.n2	bhi.b	.n3
	move.l	#$ffe1fffe,(a0)+
.n3	cmpi.w	#$ffe3,d1
	bne.b	.nf
	moveq	#-2,d4

.nf	add.w	d4,-12(a0)
	move.l	#313<<8,d4
	bchg	d3,d3
	bne.b	.nl
	rts

	cnop	0,4
c0	dc.l	-2

wave
	dcb.b	16,127
	dcb.b	16,-128

cl	dx.l	2

copperlist1
	dx.b	12*(227*313/64)+12+4*2

	cnop	0,4
copperlist2
	dx.b	12*(227*313/64)+12+4*2

Volume change in perfect synchronization with pwm frequency thanks to the copper (hopefully centered in the midpoint of the cycle, in any case it can be modified by simply changing a parameter).
The code can be used as a basis for further synchronized audio experiments.

The double buffered generated copper list(s) has no problems at copper roll of line 0 and 256 and continues to remain in phase with a defined cck.

I assembled two executable: first one that keeps the volume constant, the other one that set volume at 15 then quickly flip to the default 63.
In theory, the two output wave should be identical if the volume is copied into the pwm counter only at the end of the count.

I used a simple square wave with 50% duty cycle (32 samples, period 128), therefore can be annoying to the ears

Work on any Amiga.

Yes this is too much off-topic, all these technical messages should really be moved to the Coders.Asm/Hardware section

Cheers.

[Paulee_Bow]

Originally Posted by ross

Ok, code time:

	section	pwmvolumetest,code_c

pwmcenter	equ	14+28+1
volume1		equ	15
volume2		equ	63

Start
	lea	$dff000,a6
	move.w	#$7fff,$9a(a6)
	move.w	#$005f,$96(a6)
	move.w	#$00ff,$9e(a6)
	lea	c0(pc),a0
	move.l	a0,$80(a6)

	lea	wave(pc),a0
	move.l	a0,$a0(a6)
	move.w	#16,$a4(a6)
	move.w	#128,$a6(a6)
	move.w	#volume2,$a8(a6)

	lea	copperlist1(pc),a0
	lea	copperlist2(pc),a1
	lea	cl+8(pc),a5
	move.l	a1,-(a5)
	move.l	a0,-(a5)

	moveq	#pwmcenter,d7	; h
	bsr.b	genlist


	move.w	#311,d0			; penultimate line
waitl:
	move.w	6(a6),d1
	swap	d1
	move.w	4(a6),d1
	rol.l	#8,d1
	andi.w	#$1ff,d1
	cmp.w	d1,d0
	bne.b	waitl
	
.ll	cmpi.w	#$3840,6(a6)
	blo.b	.ll
	move.l	(a5),$80(a6)
	move.w	#$0120,$96(a6)
	move.w	#$8001,$96(a6)
	move.w	#$7fff,$9c(a6)

.go	moveq	#$20,d0
	and.w	$1e(a6),d0
	beq.b	.go
	move.w	d0,$9c(a6)

	movem.l	(a5),a0/a1
	exg	a0,a1
	movem.l	a0/a1,(a5)
	
	bsr.b	genlist
	
	move.l	(a5),$80(a6)
	bra.b	.go


genlist
	move.w	#227,d6			; 227
	moveq	#$40,d5
	lsl.w	#2,d5			; #$00000100
	moveq	#1,d4
	swap	d4			; #$00010000
	moveq	#-2,d3
	moveq	#64,d2
	moveq	#0,d0			; line

.nl	moveq	#1,d1
	or.w	d0,d1
	or.b	d7,d1
	move.w	d1,(a0)+
	move.w	d3,(a0)+
	move.l	#$00a8<<16|volume1,(a0)+
	move.l	#$00a8<<16|volume2,(a0)+
	add.w	d2,d7
	cmp.w	d6,d7
	blo.b	.nl
	sub.w	d6,d7
	add.l	d5,d0
	cmp.l	d4,d0
	bne.b	.nl

	cmpi.w	#$ffd3,d1		; copper y-roll fix
	bne.b	.n2
	moveq	#2,d4
.n2	bhi.b	.n3
	move.l	#$ffe1fffe,(a0)+
.n3	cmpi.w	#$ffe3,d1
	bne.b	.nf
	moveq	#-2,d4

.nf	add.w	d4,-12(a0)
	move.l	#313<<8,d4
	bchg	d3,d3
	bne.b	.nl
	rts

	cnop	0,4
c0	dc.l	-2

wave
	dcb.b	16,127
	dcb.b	16,-128

cl	dx.l	2

copperlist1
	dx.b	12*(227*313/64)+12+4*2

	cnop	0,4
copperlist2
	dx.b	12*(227*313/64)+12+4*2

Volume change in perfect synchronization with pwm frequency thanks to the copper (hopefully centered in the midpoint of the cycle, in any case it can be modified by simply changing a parameter).
The code can be used as a basis for further synchronized audio experiments.

The double buffered generated copper list(s) has no problems at copper roll of line 0 and 256 and continues to remain in phase with a defined cck.

I assembled two executable: first one that keeps the volume constant, the other one that set volume at 15 then quickly flip to the default 63.
In theory, the two output wave should be identical if the volume is copied into the pwm counter only at the end of the count.

I used a simple square wave with 50% duty cycle (32 samples, period 128), therefore can be annoying to the ears

Work on any Amiga.

Yes this is too much off-topic, all these technical messages should really be moved to the Coders.Asm/Hardware section

Cheers.

No this is fantastic! As an expert synthesiser user/sound designer, but someone who knows very little about coding, this information is very useful in filling in some gaps in my knowledge.

Paula is truly capable of a lot of synthesis power, without doing any sampling whatsoever.

[Foebane]

What I've grown fond of with Paula is the bass capabilities of the chip, and how it was better than most people's stereos at the time of launch (JUMP TO 6:11, 5:13 if you want to hear Paula presented in full):

[ Show youtube player ]

Indeed, here are three Demoscene examples of pounding beats that I think stand out and which are favourites of mine (no doubt there are countless others):

[ Show youtube player ]

[ Show youtube player ]

[ Show youtube player ]

[8bitbubsy]

Originally Posted by Foebane

What I've grown fond of with Paula is the bass capabilities of the chip, and how it was better than most people's stereos at the time of launch (JUMP TO 6:11, 5:13 if you want to hear Paula presented in full):

If you like 8-bit quantization noise/hiss, that is. Especially audible when there is little treble/mid content in the sample, like bass samples. Now imagine Paula with 8+ channels, extended period range (higher clock + 32-bit periods) and 16-bit sound for all channels.

[daxb]

If you ever made music on Amiga using Paulas 8 bit you would know all the problems. Especially with bass samples as 8bitbubsy mentioned. Get a clean bass is (nearly) impossible. Samples with volume fade out just put out noise at the end (8 bit sucks). You can bypass that be using a good loop sample and do the volume fade out manually, but that isn't always possible.

Yes, Paula with more channels, 16 bit an at least 5 octaves (periods) would be nice. I think a lot of musicians left Amiga system in the 90' because of the limited sound properties.

[Foebane]

I don't agree with you two. Paula bass is cool.

And I actually think the present Paula limitations are not limitations, as complex soundtracks WITHOUT mods are possible, with enough memory and HDD space. Heck, even on A500, you can have such soundtracks.

And masses of Commodore 64 demos are still released to this day, so limits don't "force people away".

[8bitbubsy]

Suit yourself, just know that there is absolutely nothing special about bass on Paula. What you hear is what is in the sample data, and at 8-bit the noise floor is really high and well audible.

Here's an example for you. First part is 29kHz 16-bits, second part is how it would sound at 29kHz on A1200, and third part is how it would sound at 29kHz on A500 (~4.421kHz low-pass):
http://16-bits.org/etc/8bit_test.wav

Here's the original sample in case you don't believe me. Try to convert it to 8-bits and play it on Amiga:
http://16-bits.org/etc/bass.wav

Paula bass is not cool.

EDIT: Paula can do 14-bit, which helps a lot, but you lose two channels and are left with only two. This means that to do anything sensible, you'd have to do software mixing at high frequency. I'd say that 8-bit is what most people used when making music with Paula.

[Foebane]

Originally Posted by 8bitbubsy

Paula bass is not cool.

EDIT: Paula can do 14-bit, which helps a lot, but you lose two channels and are left with only two. This means that to do anything sensible, you'd have to do software mixing at high frequency. I'd say that 8-bit is what most people used when making music with Paula.

1st para: Tell that to a ZX Spectrum or a Commodore 64 owner who hears Amiga bass for the first time and immediately forks out the cash for one. SID and the Yamaha chip (or even beeper) couldn't do bass to save their lives.

2nd para: I'm not talking about mixing, but WAV-like PCM files, or whatever the Amiga equivalent is. As CDs (for example) are stereo and work on the principle of PCM, the lack of more than two channels is irrelevant.

[no9]

Originally Posted by Foebane

1st para: Tell that to a ZX Spectrum or a Commodore 64...

Tell what?

[ Show youtube player ]