Sound Instantiation
Jon Abbott (1421) 2640 posts |
I’m not sure if this is actually a bug or by design but I’ve noticed Page Zero accesses in a few Voice Generators due to this. When the Instantiate entry of a Voice Generator is called, R9 doesn’t point to the channels’ SCCB which means a voice handler can’t actually initiate the channels working registers (R4-R8). I would have thought that a voice being instantiated might want to initialise its variables…or am I missing something? The sourcecode for instantiation is here |
Jeffrey Lee (213) 6048 posts |
I’m assuming it’s by design – the RISC OS 3 PRMs make no mention of the SCCB being provided to the Instantiate or Free entries. It’s only the Fill/Update/GateOn/GateOff entries which are documented as receiving it. One bit which is in the PRM description of Instantiate but not on the wiki is “Each channel attached is likely to need some private workspace” – which implies that one potential reason for the Instantiate entry existing is for voice generators to be able to allocate workspace on demand, e.g. if the 192 bytes available in the SCCB is insufficient. Of course, that still doesn’t explain why the SCCB isn’t provided to Instantiate. One theory is that if the process of switching over ownership for a sound channel isn’t atomic, then if the new voice generator was allowed to overwrite the SCCB during Instantiate then it would interfere with any last few buffer fill requests which the old handler receives before the switch-over is complete. But (at least as far back as RISC OS 3.6) the entire AttachVoice SWI runs with interrupts disabled, so we’d need to disassemble some older versions of the module to see if that behaviour’s changed at all. Also, the code detaches the old voice before attaching the new one. |
Jon Abbott (1421) 2640 posts |
Yes, I noted that comment in the PRM about “likely to need some private workspace” and the fact the PRM doesn’t mention R9 for anything except the Fill entry. It just seems a little odd to me. As the previous voice is removed before the Instantiation entry is called and the SCCB is modified elsewhere in AttachVoice I believe it’s safe to point R9 at the SCCB. Up until now, I’ve been patching Voice Generators, which in hindsight was probably the wrong thing to do. I’ve now put a wrapper around the Instantiate calls and am working out R9 from R10, which I believe is R9=R10-SoundChannelVoiceIndexB or R9=R10-1 going by the hdr file. Given the large number of Voice Generators that generate Page Zero accesses, I’m beginning to wonder if the early Sound documentation that was provided to developers was different to how it’s now implemented. I seem to recall in the early days (1987/88) that the sound documentation was not public information as I had to request it via the developer programme – I’ll have to see if I still have that paperwork. |
Rick Murray (539) 13747 posts |
Looking at the ancient description, it looks like it’s used as a way of maintaing state whilst actually generating sound. Which is why it’s not used during the initialisation. There’s a very simple example (and description prior) in the Arthur PRM on page 562. That’s book two, p215 (as the PDF numbers it). Might be largely the same as in the later PRMs? Not checked, but it’s the earliest reference I know about. It’s possible that it was not documented in the very early days due to the rapidity of changes? Things weren’t really “stable” until Arthur 1.20, and there’s quite a lot of difference between that and 0.30 (I don’t have any of the ones in between). |