Go to bottom

Paula interrupts

category: code [glöplog]
I wanted to be able to quickly prototype some Amiga music code in JavaScript, so I decided to code mycelf a simple Paula emulation in .js

I'm almost done, but I'm a bit confused about how the audio interrupts are supposed to work.

The Hardware Reference Manual at one point says:

"Interrupts occur immediately after the audio DMA channel has read the
location and length registers and stored their values in the back-up
registers. Once the interrupt has occurred, you can rewrite the
registers with the location and length for the next waveform segment."

and in another place it says:

"This level 4 interrupt signals "audio block done." When the audio DMA is
operating in automatic mode , this interrupt occurs when the last word in
an audio data stream has been accessed."

So, which is it? Does the interrupt occur at the start of sample playback (right after Paula copies the registers), or at the end (as the last word of data is read) ?
added on the 2015-07-02 16:58:49 by juice juice
Maybe poke around in WinUAE's source code?
added on the 2015-07-02 20:44:15 by absence absence
Better get in touch with UAEs´Developers directly!
They will listen to you for sure...and hopefully enlighten you aswell! ;)
(And in the end you will work with em, if you want to, maybe, just doesn´t pay, same as demos or Paula-JavaScripts! :) )
What the HRM probably meant was that interrupts occur immediately on the initial setup of the audio.

during this time, writing the offset/length values will not make a change to the playback until the previous sample is played back. It will then start the new playback from the offset/length values that were previously written and generate the irq again just before the playback of the new offset/length
added on the 2015-07-02 21:15:08 by algorithm algorithm
How did you do a Paula emulator without a 68000 emulator?
added on the 2015-07-02 21:19:41 by friol friol
exactly how it read to me, but didn´t want to post any speculations here...abscence was right about asking people who have more knowledge about this! (even if just intending, by supposing to read sourceCode!)

-> Once Level4-Interrupt is done, you can happily go on poking new values...won´t change anything until next one, only will be read/rewritten once this one is done!
friol: by emulating the Paula-Chip itself himself! ;)
Rest is writing it to some Wavetable!
Both are true.

If audio DMA was previously off and you write the location and length and then turn on audio DMA for the channel, the audio hardware will immediately copy the location and length to internal registers and then signal the interrupt.

If audio DMA is active (sound is playing), the audio hardware will not read the location and length until the last word was read from memory. At that point, it will copy the location and length to internal registers and then signal the interrupt.

In both cases, the interrupt indicates that the location and length registers can now be written with the location and length of the next block of audio data to be played after the current one. In other words, in a chain of audio data blocks, the interrupt occurs when the location and length for block n have been read, meaning that block n-1 was done, and you can write the values for block n+1.

Note that if sound is playing and you switch off the DMA, the audio hardware will not notice until it has finished playing the current sample pair (DMA word). If you switch the DMA on again before that time, the sound will continue playing as if nothing happened. Thus, if you need to stop a sound and start a new one, you must switch off the DMA and then wait for at least two times the period of the currently playing sound, before you can set up the new sound and switch on DMA again.
added on the 2015-07-02 21:34:54 by Blueberry Blueberry
@algorithm, yeah - that sounds like a reasonable assumption. there wouldn't be much time to do anything useful in the interrupt if it fired on playing the last word.

I'd like to hear from somebody with first-hand experience with this stuff, though. Failing that, maybe I'll just poke around the UAE sources, though.

@friol: I don't actually run any 68k code. I just poke Paula's "registers" from JavaScript code and give it an ArrayBuffer pretending to be CHIP RAM.

The idea is to be able to experiment and prototype audio synth stuff quickly, and when I have something I like it'll (hopefully) be an easy rewrite in 68k assembly to be run on a real Amiga, because the code is just moving some data around.

I also rewrote the most basic part of the ProTracker playroutine to .js as a test and it seems to work OK. No support for tempo or any effect commands, though I just wanted to hear if I can get sound out of it.
added on the 2015-07-02 21:39:06 by juice juice
@Blueberry, thanks! That's a great explanation!

The last thing you mentioned is the cause for the DMA Wait bug found in some (older) PT replays, right?
added on the 2015-07-02 21:41:40 by juice juice
Yes, the DMA wait is there for exactly that reason. The bug in old players (and Protracker itself) is that they use a CPU countdown loop to perform the wait, which means that on faster processors it is not waiting long enough.
added on the 2015-07-02 21:43:52 by Blueberry Blueberry
When an Admin uses a FakeAcc all left to say is: "Worst FakeAcc ever! :p"
@juice, in regards to interrupt firing at the last word, the new setup parameters would have been loaded before this (which will transition to the new) and then the next new offset/length can be written which will prepare for transition when the sample has played back.

Are you also utilising the non-linearity and cutoff filters that are on the devices?

From what I have also read somewhere, the amiga only has 1 D/A converter that is multiplexed?
added on the 2015-07-02 21:53:13 by algorithm algorithm
added on the 2015-07-02 21:53:33 by juice juice

-> almost seems as i am not known to you as what i really am! :p -> Pouet-Troll! ;)
almost asleep, overheated and a bit drunk ↓
i'm emulating the non-linearity of the volume register (according to the values found in the HRM)

i know the DAC is also not perfectly linear, but I don't have a way to measure that, and I'm not really sure the effect is that pronounced.

i don't care about the lowpass filter ATM, but it shouldn't be very hard to implement, i'd just add a biquad after the output stage.
added on the 2015-07-02 21:59:26 by juice juice
hardy, yeah I'm new-ish here, thanks for the heads up :)
added on the 2015-07-02 22:00:09 by juice juice
If you are new, just listen to what Blueberry said/will_say ;) He´s right, Always!

My times on Amiga are long gone, SADLY! :( ( Last time i coded in 68k was around 1997! )

A small List of more ppl to abuse every Word they say (about Amiga-Code-Knowledge) would still make a very big Array, simply know you asked at the perfect "Forum" ;)

[CantResistFastList](Britelite!, Kalms, Emoon, MrPet, Chaos[/CantResistFastList]
(sorry to all forgotten, this would really end in said BigArray!)
From what I have also read somewhere, the amiga only has 1 D/A converter that is multiplexed?

AFAIK there are four separate ones, but volume control is simulated by quickly turning the signal on and off (pulse width modulation). Maybe that's what you were thinking of? Some modulation noise is introduced in the process, I guess that's the non-linearity mentioned. The rest, including the filters (non-AGA machines have one that's always active in addition to the power LED one), should be pretty linear.
added on the 2015-07-03 01:04:23 by absence absence
Haven't heard about PWM being used to simulate volume before, but it sounds plausible. It would be really cheap and easy way to implement volume control on a 3.5MHz DAC that only needs to output samples up to about 28KHz.

Here's the table from the HRM I mentioned, perhaps it can shed some light.

Code: Volume Decibel Value Volume Decibel Value ------ ------------- ------ ------------- 64 0.0 32 -6.0 63 -0.1 31 -6.3 62 -0.3 30 -6.6 61 -0.4 29 -6.9 60 -0.6 28 -7.2 59 -0.7 27 -7.5 58 -0.9 26 -7.8 57 -1.0 25 -8.2 56 -1.2 24 -8.5 55 -1.3 23 -8.9 54 -1.5 22 -9.3 53 -1.6 21 -9.7 52 -1.8 20 -10.1 51 -2.0 19 -10.5 50 -2.1 18 -11.0 49 -2.3 17 -11.5 48 -2.5 16 -12.0 47 -2.7 15 -12.6 46 -2.9 14 -13.2 45 -3.1 13 -13.8 44 -3.3 12 -14.5 43 -3.5 11 -15.3 42 -3.7 10 -16.1 41 -3.9 9 -17.0 40 -4.1 8 -18.1 39 -4.3 7 -19.2 38 -4.5 6 -20.6 37 -4.8 5 -22.1 36 -5.0 4 -24.1 35 -5.2 3 -26.6 34 -5.5 2 -30.1 33 -5.8 1 -36.1 0 Minus infinity
added on the 2015-07-03 09:19:57 by juice juice
OK, a few moments with a calculator later and I feel stupid. These are just the dB values for ratios x/64 rounded to the first decimal place.
It's the rounding that makes it seem non-linear.
added on the 2015-07-03 09:35:13 by juice juice
The PWM thing is only hinted at in the HRM, but suspicions and rumors were confirmed by Toni Wilen (WinUAE author) using a scope.
added on the 2015-07-03 11:28:28 by absence absence
non-AGA machines have one that's always active in addition to the power LED one

Correcting myself: All Amigas have a filter in addition to the power LED one, but on AGA ones the cutoff is above human hearing.
added on the 2015-07-03 12:06:41 by absence absence
Here's the table from the HRM I mentioned, perhaps it can shed some light.

Nice. Cheers juice! Regardless of decimal rounding, this is actually an interesting table to look at. I've been choosing values by ear for 20 years, but it's funny to see it resolved as a set of approx dB values! :-)

Us musicians all still wish there was the equivalent of a 0.5, 0.3, 0.2 and 0.1 come end-of-track last-note fade-out time ;-) (Yes, I'm aware the Paula only has a 6 bit vol reg per chan!)
added on the 2015-07-03 12:50:37 by cTrix cTrix
AFAIK there are four separate ones

I do remember someone mentioning that at least the two channels forming one mono channel are interleaved on the same DAC, but I could be wrong.


Go to top