OS_Word 7

What’s the status of OS_Word 7 its not documented in the RO3 PRM, so is it considered deprecated or has it simply been missed?

5a-686 states that “many” OS_Bytes and OS_Words have been deprecated, although unfortunately it doesn’t list OS_Word 7 specifically.

Edit: https://www.riscosopen.org/forum/forums/3/topics/1532 (13th post) states that OS_Word 7 was specifically tied to the BBC’s sound chip.

Edit 2: http://lists.cloud9.co.uk/pipermail/bbc-micro/2009-December/007656.html says that “For the record, RISC OS does support OS_Word 7 (by passing it to Sound_ControlPacked), and it’s what BASIC passes SOUND to.”

Nice and confusing :)

The source code is still in RISCOS (see link in OP).

I can’t see any reason to deprecate it any time soon, as it simply does LDMIA R1,{R0,R1} followed by SWI Sound_ControlPacked

The fact it’s not documented does however mean it can change at any time, or be deprecated so I’m wondering if I should trap the SWI in ADFFS and implement it, or if it’s safe to leave for the OS to handle.

Yeah, my post above was a bit of me trying to save face after initially accidentally looking up OS_Byte 7 :)

Ah, I see we’re all looking at this.

The logical explanation? Undocumented compatibility.

The OS_Word, which is not officially supported, passes its values on to the Sound_ControlPacked SWI which receives its input in a BBC Micro like fashion.
Looking in the Beeb AUG (p250), the OS_Word does indeed make sounds, 4×16 bit for channel, amplitude, pitch, duration.

It wouldn’t surprise me if this was intended to be used by the OSxxxx trap in BASIC so that older programs could make sounds, it was just never properly documented because ENVELOPE was never implemented…

As for trapping – do you plan to implement ENVELOPE? I can’t imagine it is going to go away, the OS_Word call I mean, but then given that it was never officially documented, I can’t imagine much RISC OS era software would be making use of it. With that in mind, perhaps best to kick it to the OS and not worry too much until somebody complains. ;-)

Just browsing my paper copy of the AUG. There were lots of interesting OS_Word calls. Say – if we implement multicore support, can we reinvent OS_Word 5 and 6? 8-)

As for trapping – do you plan to implement ENVELOPE?

No, I’m only implementing OS calls that games use as I come across them – if they’ve either been deprecated past RO2, or the behaviour has changed. Thundermonk uses OS_Word 7 and although its now running under ADFFS on the Pi, the question of OS_Word 7’s deprecated status past RO2 remains.

If I document OS_Word 7 on the Wiki is that sufficient enough to make it officially supported? Obviously with a clear statement that Sound_ControlPacked should be used in preference.

Just browsing my paper copy of the AUG. There were lots of interesting OS_Word calls. Say – if we implement multicore support, can we reinvent OS_Word 5 and 6? 8-)

Ah yes, Read/Write IO Memory – surely somewhat redundant on RISCOS as IO is mapped in.

Just looking at OS_Word 8, I’m not sure why Acorn didn’t implement it, its only manipulating the Voice Handler parameters on a cs basis. We’ve lived this long without it though so probably no reason to consider implement now.

REM >osword7
DIM block% 7
?block%=1      :REM Channel LSB
block%?1=0     :REM         MSB
block%?2=&F1   :REM Amplitude
block%?3=&FF
block%?4=&80   :REM Pitch
block%?5=0
block%?6=&14   :REM Duration
block%?7=0
SYS "OS_Word",7,block%
END

REM Alternatives
REM SYS "Sound_Control",1,-15,&80,&14
REM SYS "Sound_ControlPacked",&FFF10001,&00140080
END

Ah yes, Read/Write IO Memory – surely somewhat redundant on RISCOS as IO is mapped in.

Well, it may need some tweaks to specify a processor, a virtual address (on that processor), a buffer (local), and a number of bytes. ;-)

[I’m assuming here that each core has an independent MMU and thus can map memory differently to the other cores]