Multiple audio devices

Colin, what Module is it that’s crashing in you debug dump?

If Colin had started the debug dump a few intructions earlier we’d be able to see the full name of the faulty function. ‘……SC_OSLib’

If Colin had started the debug dump a few intructions earlier we’d be able to see the full name of the faulty function.

That was just a file path.

what Module is it that’s crashing in you debug dump?

I posted the output of ‘where’ which didn’t find a module. Looking at the modules list I would agree with it.

This isn’t a problem for me personally as I can work around it I just pointed it out as other users may use old commercial software. I should also point out that I would have expected that this part of techwriter has been rewritten in the newer versions.

Colin hasn’t given any reports for how TechWriter fails

It doesn’t produce a zero pain report it just aborts on data transfer.

Yeah, ZeroPain doesn’t trap writes to zero page. Looks like it’s trying to write to the ‘RISCOSLibWord’ and ‘CLibWord’ zero page variables, which (together with the truncated ‘SC_OSLib’ text, and the fact that it’s running from the RMA in SVC mode) suggests it’s using a module which was built against an old version of RISC_OSLib. *Where is probably having trouble finding it because the module crashed during initialisation.

It’s potentially the kind of thing that ZeroPain could deal with, although I’d probably have to look at the RISCOS_Lib sources to try and work out why it’s overwriting the values with zero rather than reading from them (reads from RISCOSLibWord and CLibWord are translated). And I should probably work out why we even need those variables in the first place.

Sadly the same isn’t true of the IOMD version of SoundDMA, where we have to retain compatibility with systems which lack 16bit sound hardware.

I’ve yet to test, but the wording here scares the living daylights out of me from a compatibility perspective!! Does 8bit sound still exist in the revised SoundDMA? I’ve not misinterpreted as now being 16bit only post IOMD? Or have you simply moved SoundDMA over to the HAL model where possible, leaving IOMD as-is.

Sorry; perhaps I wasn’t clear enough. All versions of SoundDMA support playing 8bit audio, but it’s only the IOMD version of SoundDMA that knows how to drive 8bit audio hardware. This is a problem because (as I’m sure you know) early RiscPC’s only had 8bit audio hardware.

Extending the HAL device interface (which the ‘Sound0HAL’ version of SoundDMA uses) to support 8bit audio shouldn’t be too hard (I think that all it really needs is a flag to say ‘I am 8bit’ and an extra entry point to set the stereo position registers), but there’s also the slight niggle that the choice of whether to use 8bit or 16bit sound is controlled by a CMOS setting (with associated *Configure option) – something which the HAL wouldn’t be privy to. So maybe the solution there would be to have an ‘IOMDSound’ module which contains the 8bit and 16bit HAL devices and the necessary logic to handle the CMOS settings.

Sorry; perhaps I wasn’t clear enough. All versions of SoundDMA support playing 8bit audio

It’s probably down to me being drugged up to the eye-balls at the minute! Very little is making sense!! Thanks for the clarification.