Sound system recovery issue

SoundChannels and SoundScheduler don’t reinstate themselves when SoundDMA is reinitialised if they were the previous providers.

Repro from BASIC

*RMReInit SoundDMA
SYS "Sound_Configure",0,0,0,0,0 TO ,,,C%,S%
PRINT ~C%, ~S%

After reinitialising SoundDMA, the Channel Handler and Scheduler returned by Sound_Configure appear to be part of the PSR. On RO 3.71 they return &FC000003 and on RO5 they return &3.

Is this expected behaviour?

SoundChannels and SoundScheduler don’t reinstate themselves when SoundDMA is reinitialised if they were the previous providers.

Expected? Yes. AFAIK this has always been the behaviour.

Sensible? No.

After reinitialising SoundDMA, the Channel Handler and Scheduler returned by Sound_Configure appear to be part of the PSR. On RO 3.71 they return &FC000003 and on RO5 they return &3.

Actually this value is SoundSystemNIL, which was presumably chosen because it’s an invalid address.

There’s possibly a bug in RO3.x then, by returning &FC000003 instead of 3.

I can work around the fact they’re not reinstated, by storing the configuration at Service_Sound 1 and restoring it at Service_Sound 0.

The underlying problem I’m trying to resolve is how to recover the sound system from a fatal error in a voice.

SoundSystemNIL used to be &FC000003, and was only changed to &3 for RISC OS 5 (checking the source, I can see that it uses TST against SoundSystemNIL to check if pointers are valid, so I guess the definition of SoundSystemNIL is really “all the address bits which aren’t valid”)

Just out of interest, why not a fixed bogus value like -1 (which will have invalid address bits set)?

TST some_pointer, #SoundSystemNIL
BNE bad_address

If SoundSystemNIL was -1, it would consider any non-zero pointer to be invalid.

(And if you want to know why TST is used, invent a time machine and go back in time 30 years to ask Acorn)

Ah, it’s a TST, not a CMP… Oh well.