Low-level workings of Paula

[yaqube]

Originally Posted by pandy71

I saw this and i even ask Her about details but no reply.

I have also asked Her about those schematics but have got no reply. Shame

[mc6809e]

Originally Posted by pandy71

I've read HRM and from my understanding interrupts must be correctly processed - CPU is to slow to deal with such things.

Depends on the frequency I think.

Amiga audio is interesting in that the output rate per channel is variable. If the output rate is low enough, the CPU is more than capable of keeping up.

And as Toni has pointed out before, the Amiga has a clever way of avoiding autovectoring for interrupts (autovector interrupts are a big hassle on Atari ST as they add a variable number of additional cycles to interrupt processing). This keeps interrupt response time low. I think the maximum is 40 cycles.

As mentioned early, though, the COPPER can update audio outputs, too, and that's very fast indeed, but less flexible of course.

I'd be interested in seeing if a hybrid approach might work: use DMA for some of the samples, but use the COPPER to sneak-in a few extra samples at those times when Paula requests a word from Agnus that can't be delivered in time.

The max DMA rate is two outputs per scanline per channel. If the period is set to 63, then two samples are output in the first half of a scanline. A COPPER list that causes the COPPER to wait mid-scanline can then load the next two samples for the second half of the scanline. This would give an output rate of 56K.

To make things fast, perhaps the blitter could be used to fill in the values for the COPPER list.

[absence]

Originally Posted by mc6809e

Depends I think. Anything above about 56K values per second will change the granularity of the volume control mechanism, but I think some control is still available.

Constantly resetting the volume counter will also give strange results below 56 kHz. But you will get results - by "won't work" I just meant they won't be normal (i.e. volume 32 won't necessarily give you half amplitude).

[pandy71]

Originally Posted by Toni Wilen

You need to clear INTREQ (It can be done with copper) or state machine returns to idle state after period has counted twice to zero instead of starting to play next sample "word". AUDxDAT write with DMA OFF and channel INTREQ bit set: nothing happens.

It is clearly shown in HRM audio state diagram

Thx Toni, OK, so seems that i've not misunderstood HRM - there is no chance to bang directly AUDxDAT without processing interrupts generated after each word.

[pandy71]

Originally Posted by mc6809e

Depends on the frequency I think.

Amiga audio is interesting in that the output rate per channel is variable. If the output rate is low enough, the CPU is more than capable of keeping up.

CPU have enough tasks to process - i dont expect form 0.75MIPS CPU to deal with audio data.

Originally Posted by mc6809e

As mentioned early, though, the COPPER can update audio outputs, too, and that's very fast indeed, but less flexible of course.

Most of today sample rates are constant - i need oversample 2x typical sample rates ie 32, 44.1 and 48 ksps.

Originally Posted by mc6809e

I'd be interested in seeing if a hybrid approach might work: use DMA for some of the samples, but use the COPPER to sneak-in a few extra samples at those times when Paula requests a word from Agnus that can't be delivered in time.

I have also similar idea, only currently no chance to check...

Originally Posted by mc6809e

The max DMA rate is two outputs per scanline per channel. If the period is set to 63, then two samples are output in the first half of a scanline. A COPPER list that causes the COPPER to wait mid-scanline can then load the next two samples for the second half of the scanline. This would give an output rate of 56K.

To make things fast, perhaps the blitter could be used to fill in the values for the COPPER list.

This will be only part of the more complex task - 16 bit sample, quantize to 8 bit, quantization error add to next sample etc.

[mc6809e]

Originally Posted by pandy71

Thx Toni, OK, so seems that i've not misunderstood HRM - there is no chance to bang directly AUDxDAT without processing interrupts generated after each word.

But you don't need to actually use interrupts. You just need to clear the INTREQ bit to get Paula to accept the next word.

It should be possible to drive Paula directly with the CPU by polling INTREQR to see which channel needs a new sample, then clear the right bit in INTREQ, and then load the next word and loop.

[pandy71]

Originally Posted by mc6809e

But you don't need to actually use interrupts. You just need to clear the INTREQ bit to get Paula to accept the next word.

It should be possible to drive Paula directly with the CPU by polling INTREQR to see which channel needs a new sample, then clear the right bit in INTREQ, and then load the next word and loop.

CPU is "asynchronous" when Copper is fully synchronous to audio - CPU should focus on how to prepare data but Copper should be responsible for perfect timing.

[mc6809e]

Originally Posted by pandy71

CPU is "asynchronous" when Copper is fully synchronous to audio - CPU should focus on how to prepare data but Copper should be responsible for perfect timing.

Well you brought up interrupts which are handled by the CPU...

But I think in non-DMA mode Paula will simply continue to output the last value written to AUDxDAT until INTREQ is cleared and a new value is written to AUDxDAT.

If the period value is very short, then Paula simply waits for the next INTREQ clear and AUDxDAT load which can be controlled by a COPPER list.

And no need to process interrupts.

[pandy71]

Originally Posted by mc6809e

Well you brought up interrupts which are handled by the CPU...

But I think in non-DMA mode Paula will simply continue to output the last value written to AUDxDAT until INTREQ is cleared and a new value is written to AUDxDAT.

If the period value is very short, then Paula simply waits for the next INTREQ clear and AUDxDAT load which can be controlled by a COPPER list.

And no need to process interrupts.

Toni and HRM says something else (hey Toni did You realize that You are source comparable to HRM - Deus Ex Machina )

[Toni Wilen]

Originally Posted by pandy71

Toni and HRM says something else (hey Toni did You realize that You are source comparable to HRM - Deus Ex Machina )

HRM may say something else but diagram won't lie

I am more surprised that the diagram actually matches what real hardware does..

But there is one mistake (I finally remembered it): state 011 to 010 transition has condition "perfin * (AUDxON + /AUDxIP)", it should be "perfin * (/AUDxON + /AUDxIP)" = return back to state 010 when period counted to zero and audio dma is off and interrupt request is cleared.

--
EDIT: I remembered wrong, it is correct. Go back to state 010 if period ended and (dma is on or interrupt status is cleared).. Without the AUDxON condition DMA mode wouldn't work at all. (and above "corrected" wrong condition was supposed to be "perfin * /AUDxON * /AUDxIP")
--

It is confirmed correct because pseudo code like this works:

Clear interrupt request, write only _once_ to AUDxDAT,
Wait for audio interrupt
Clear interrupt
Wait for audio interrupt
Clear interrupt
and so on..

010->011->010 state changes keep happening as long as interrupt is cleared. AUDxDAT write is only required to start the state machine.

[TheDarkCoder]

Originally Posted by pandy71

Thx Toni, OK, so seems that i've not misunderstood HRM - there is no chance to bang directly AUDxDAT without processing interrupts generated after each word.

I think you misunderstood what Toni said. (or maybe it is me who misunderstood ).
Toni, the HRM and my memory says that you have to clear INTREQ.

You don't need to enable interrupts to do that. You can keep interrupts disabled and just do a busy loop that waits for the bit in INTREQ to be set (to 1) by Paula.
When this happens, you reset (to 0) it.

This is what I recall and how I understand Toni's words

[Toni Wilen]

Yeah, only channel's INTREQ bit needs to be cleared before both samples (one word) has finished playing. Paula won't care how you do it

[pandy71]

I understand correctly - however anything over wrote to AUDxDAT is unacceptable overhead on such bandwidth machine.
I understand that Copper need to make additional write and this is problem - i prefer bang AUDxDAT then dont care except those moment when i need "bang" - but i'm not a programmer... so perhaps this is doable without problems.

[8bitbubsy]

Bump.
This thread is very interesting, and we need more research on this topic.
Too bad Jeri won't share the inner chip diagram of Paula.. I guess it makes sense though, those diagrams weren't probably meant to be spread.

[spoUP]

any news on this?

[pandy71]

Originally Posted by spoUP

any news on this?

news on what?