View Single Post
Old 16 January 2020, 16:50   #12
Registered User

Join Date: Nov 2017
Location: Los Angeles
Posts: 36
The HRM is confusing in places, and this is certainly one of them. As Toni says, the "joining tones" section is probably the best description of the behavior for "automatic" mode (DMA based sample fetching).

To achieve a single-shot-sample using the IRQ handler I have to ignore the first INT. Then when the sample restarts I process the INT and switch off the DMA to stop it.
I think this is not robust and could result in audio pops.

If you ignore the first interrupt, the second interrupt is the sample restarting playback. Your interrupt must stop the DMA before any data is read, which generally means it must happen very quickly (probably within less than one raster line). Failure to do it quickly enough will result in audio pops.

On the 68000, servicing an interrupt reliably within one raster line can be tricky, if you consider:
- the CPU invoking the interrupt alone is quite expensive (storing CPU state takes quite a lot of cycles even before the first instruction of your interrupt)
- you have to save registers in your interrupt handler
- other DMA going will compete with your interrupt routine (copper, bitplane fetch, sprites, blitter, audio, disk etc), assuming you're running from code in memory on the chip ram bus
- you may have other higher priority interrupts already running
- you might have multiple samples start on the same raster line

Some of these issues might be mitigated if you are targeting a faster CPU or running from fastram, but I think it's ultimately still unreliable

(EDIT: It might even be that the interrupt triggers after the fetch of the first pair of samples (i'm not sure about this) in which case you'd also have to make all your samples contain leading zeros to avoid pops)
FSizzle is offline  
Page generated in 0.04123 seconds with 11 queries