Does it raise an IRQ, leaving the IRQ handler to query SDST I/W bits (Sound DMA status) to determine if and which Sound buffer is exhaust?

Don't forget MEMC Logical and Physical memory are different ranges.

Like JL said, the Sound Buffers are within the first 512K of Physical Memory because that's what the VIDC registers allow (upper bits used for what index of register you're referring to)

1. Call OS_FindMemMapEntries to get the page number
2. Multiply page number by page size (from OS_ReadMemMapInfo)
3. Write that address to VIDC

Are you sure they aren't using OS_ReadMemMapEntries/OS_FindMemMapEntries to work out the physical address?

jon, you sure it's not just directly accessing the physical memory range which is perfectly allowed and theoretically quick since you're avoiding logical translation look up.

would be something like &2007E000

SoundDMA compiles code for this in the RMA when its initialised, is it exposed so it can be called or triggered to do the conversion?

Is there a reason why SoundDMA doesn't register this code as the system default Linear Handler so it can be called?

No idea. But that wouldn't solve your problem - you'd still need a separate interface to be available for calling the conversion code with the right parameters (buffer pointers, channel count, stereo positions, etc.)

What happens when a game configures the sound system? (Whether via SWIs or direct hardware access). Are you intercepting that all in order to provide a full emulation of the Arc sound system, or are you relying on the host machine to support all the different sample rates, etc.?

If you're just passing the configuration changes through to the OS then you should probably just copy the contents of the games sound buffer into the OS's sound buffer whenever the game finishes filling its buffer.

I suppose I could try ignoring the MEMC write if it's setting the buffer to the OS default and see if SoundDMA converts it correctly.

Jon, is it absolutely necessary to unplug things rather than RMkill etc?

I've had a couple of cases our customers have tried recent versions of ADFFS on RISC OS 5, then had crashes, and been left with unbootable machines (ie. won't get to desktop) because key modules have been unplugged.

This may be down to user error, of course, but equally unbootable machine is never good

Thinking about it, this wouldn't work anyway as the game is taking over the device. I'd have to pass the device IRQ onto SoundDMA.

This is all coded now and appears to work ok on VIDC20, the next issue is converting 8bit ulaw to 16bit linear.

SoundDMA compiles code for this in the RMA when its initialised, is it exposed so it can be called or triggered to do the conversion? That will save me creating my own routine and will ensure future compatibility, provided SoundDMA retains support for 8bit sound.

Is there a reason why SoundDMA doesn't register this code as the system default Linear Handler so it can be called?

On further investigation it turns out that SoundDMA is working at the correct time, the issue is that if SoundSystem is configured for 16bit sound, SoundDMA is not compiling an 8bit conversion routine. If I reconfigure SoundSystem to 8bit, RMReInit SoundDMA and then let Diggers run with ADFFS translating the MEMC writes, the music is correct.

Surely that's backwards?

1. How to generate the emulated IOC device 9 IRQ at the correct rate

4. What to do about SoundDMA, should I emulate the RO3.1 module in its entirety? Or, leave the current one.

You'd almost certainly need to use a timer interrupt (HAL timer/IOC timer 1).

4. What to do about SoundDMA, should I emulate the RO3.1 module in its entirety? Or, leave the current one.

In order to catch configuration changes being made by games I think you'd have to emulate the module in its entirety. But as you say I think that will introduce problems with trying to work out when to intercept or when to pass through.

Regarding when to process the sound - rather than process a full buffer's worth of data in one go, ArcEm goes down the route of processing it in batches

Then there's the second point you've probably noticed, which is that the channel mixing is deferred until the sample rate conversion is performed. This is because, just by reading the hardware registers, there's no way of determining how many audio channels are being used. You can kind of guess by looking at the settings of the stereo position registers, but that will fall apart when you come across a game which uses multiple channels but only mono sound (Lotus II, IIRC), or regularly changes the stereo position of sounds (Asylum, IIRC). So for ArcEm (and potentially ADFFS) the only real way of doing things was to provide an emulation of the time division multiplexing-like method

It's probably worth taking a look at the mixing code in the ArcEm sources to (hopefully) get a better idea of what I'm talking about here.

I did take a look last week to see how SharedSound worked - I've since made a start on adding SharedSound documentation to the Wiki based on the ROOL source code

* No Excuses uses one-shot Sstart/SendN values that are larger than the stock RO3.5 sound buffer. On IOC the DMA buffer length can be 512kb long

* Rockfall also uses one-shot Sstart/SendN values, but these are a max of &A30 in length