SOUND statement query

[tucker]

Hi all,

I am working on a graphics/sound library for macOS, Windows and Linux that implements a retro style frame buffer, sound, keyboard, mouse and game controller interface. Each platform is implemented natively and an SDL implementation for those I have not covered yet. macOS AppKit, Windows Win32 and SDL working perfectly, Linux needs work on sound. Also planning to move it to Raspberry PI Pico. The sound is based on SN76489 and I quite liked BBC SOUND/ENVELOPE so both are working (envelope completely but issue with SOUND). The library can be used directly from C or as a local socket interface allowing use via Python and others. I also plan to look at serial and network socket. The socket interface is modelled on the TUBE communication style that I always liked. Also using BBC VDU and OSxxx calls as I really liked that element of BBC design.

I am working mainly from manuals, MOS documentation and other sources as this is an API level "simulation" rather than an emulation. I have run into an issue with SOUND. I largely understand SOUND but always had an issue with Sync even back in 80s. It seems to work fine when I use examples from manuals, various AU/MU articles, several books and several PCW articles. All was going fine and it all works - sound can sync with S=1,2 or 3 and all appears fine. Then I ran some tests in JSBeeb and they left me confused, remembering I had this query in 80s. I have done extensive research and can find little reference. I plan to have a look inside the MOS disassembly, the work by Toby is awesome. However I wanted to try and avoid this too much as I was trying to replicate the function at the API level and not emulate the inner workings.

Now I am sure the answer will be obvious to some with a lot more experience than I have with The BBC SOUND command. Hence I am posting in anticipation someone can point out the obvious. For now I cannot reconcile why the commands below perform as they do in JSBeeb yet do not seem to follow what The BBC manuals say.

SOUND &102,-5,40,40 then SOUND &203,-5,80,40 immediately plays. I have reloaded JSBeeb and pressed Escape and this happens on first load.

SOUND &202,-5,40,40, then SOUND &102,-5,80,60 and SOUND &101,-5,40,20 and all 3 play as expected yet the manual seems to suggest they should only play if they all have same S value.

I have other examples that seem to defy the manual. I am wondering if I am reading something incorrectly or there is something obvious I am missing. Before I start working on the disassembly which goes against my idea to implement the API I wondered could anyone shed any light on it.

Thanks in advance for any assistance anyone can offer

[tricky]

Sorry, I can't help as I never used anything remotely fancy to do with sound and drove the chip directly from asm. I wonder if beebwiki would help and I'm surprised that jgh hasn't been along to explain.

[jgharston]

I've been deep in map stuff, interspersed with sleeping off post-viral slumber.

Looking through the examples in the first post, there's a typo in the second example that I can't decide what the correction should be:
SOUND &202,-5,40,40, then SOUND &102,-5,80,60 and SOUND &1011-5,40,20 and all 3 play as expected yet the manual seems to suggest they should only play if they all have same S value.

From memory I'm not sure if the sync value is "sync with others calls with same sync number" or "sync until X number other calls have been queued". If you'd asked me straight off, I'd have said the second, so would expect:
SOUND &3xx,.... wait for three others
SOUND &2xx,.... wait for two others
SOUND &1xx,.... wait for one others
SOUND &0xx,.... wait for no more
The &3xx now plays as three more calls have been queued.
The &2xx also now plays as two more calls have been queued.
The &1xx also also now plays as one more call has been queued
And the &0xx call plays immediately, and triggers the playing of the previous three calls.

Also, beware determining functionality from using emulators. They may not faithfully replicate what happens on real hardware, and the low-level sound stuff is one of the hardest bits to do.

[tucker]

Indeed there was a typo - now corrected. Thanks for pointing out the error.

My understanding is as you have suggested. SOUND &NxC,... adds to channel C queue with S set to wait for N other channels.

The manual suggests the same in chapter 30 on sound. Page 161 states S determines how many other channels form the chord. Reading that seems quite clear - "two or more channels will not start until all have received a note marked for synchronous productions".

The later reference on instructions seems a little divergent from this. Page 320 states "a non-zero value of S indicates .. not played until a corresponding note on another channel". It then goes to expand stating "with S set to 1 then it would not be played until a note was ready on another channel which also had S set to 1". This now seems to suggest the queued channels must have the same S value.

The former suggests SOUND &1xx, SOUND &2xx, SOUND &2xx should all play as all conditions are met - 1 is waiting on 1 other channel, 2 and 3 are each waiting on 2 other channels. The later section seems to suggest this should not play as they have different values of S.

My implementation is based on the more logical interpretation that you neatly summarised. It is up and working now and seems to work well.

I still cannot explain odd anomalies. I also have no Beeb to test. Every time I run up JSBeeb and enter SOUND &102,-5,40,40 then SOUND &203,-5,80,60 both sounds play yet I cannot explain why. My reading of the manual states that SOUND &203 cannot proceed until 2 other channels are ready and SOUND &102 should not proceed as it needs one other channel that is ready which Channel 2 is not as it's sync condition is not met. The later section in manual seems to confirm this should not proceed as they have different S values.

I accept your point that use of an emulator is not a good idea for a definitive determination of function. However, looking at source of JSBeeb I confirmed what I expected and it emulates an SN76489 but relies on the MOS running on 6520 emulator to implement SOUND and ENVELOPE. While this is not assurance that it will react as expected I would have been more inclined to suggest it would faithfully reproduce the function as not.

As I am not working on a pure emulation but an interpretation I am running with the more logical explanation. It also ensures I have some hope of being able to document and explain it to potential users of the system.

Thanks for feedback and comment.

BTW I hope you recover from the post-viral lethargy. I know from experience how debilitating yet seemingly illogical it can be. I suppose a little like the SOUND statement - unexpected interpretations Get well ...

[tucker]

Checking my formulae for amplitude and pitch conversions (used to generate lookup tables) the pitch is a little unusual. P=252 is highest pitch that corresponds to a standard note (D8). +/-48 increases/decreases by an octave. First note with picth is B2. MIDI covers A0 (21) to C8 (108). BBC coverage seems to be a little skewed towards higher frequencies at expense of lower. I suppose knowing how SN76489 uses square wave and the frequency of the counters the lower frequencies are less easy to replicate - a little easier for modern systems even on square wave especially as I am using 48kHz sampling and 16:14 fixed point to reduce error. .

As usually happens when I research things I end up in a little more detail than I expected ... or is probably needed! Inevitably I will end up looking at Music 500 to see how it covers notes. Sigh

[jgharston]

I've got a little program that generates this table and this diagram.

[TobyLobster]

The actual relationship between the SOUND pitch number (0-255) and the musical note produced is not as straightforward as expected due to the fact that there is only a limited set of 1024 different frequencies that the chip can produce, and none of them are the exact frequency of a regular musical note. The way the OS maps SOUND pitch values to chip frequencies is not optimal and means that you don't always get the best values for the next semi-tone up just by adding four to the SOUND pitch value.

It is further complicated by the OS slightly changing the pitch depending on which channel is being used. For example this plays two notes (one after the other) with the same pitch number 237 just on different channels, yet we hear different frequencies:

Code: Select all

   10 SOUND 1,-15,237,10
   20 T%=TIME:REPEAT:UNTIL TIME-T% > 51
   30 SOUND 3,-15,237,10

See the tables in this section: https://tobylobster.github.io/mos/mos/S-s15.html#SP31 for the best pitch values to use for musical notes.

[tucker]

I've got a little program that generates this table and this diagram.

Thanks for the programs and links. Much appreciated. I have something similar for my C library to generate the lookup table I include with modest extension to generate a comment. Yours is much more detailed and I think I will adopt the format.

[tucker]

The actual relationship between the SOUND pitch number (0-255) and the musical note produced is not as straightforward as expected due to the fact that there is only a limited set of 1024 different frequencies that the chip can produce, and none of them are the exact frequency of a regular musical note. The way the OS maps SOUND pitch values to chip frequencies is not optimal and means that you don't always get the best values for the next semi-tone up just by adding four to the SOUND pitch value.

It is further complicated by the OS slightly changing the pitch depending on which channel is being used. For example this plays two notes (one after the other) with the same pitch number 237 just on different channels, yet we hear different frequencies:

Code: Select all

   10 SOUND 1,-15,237,10
   20 T%=TIME:REPEAT:UNTIL TIME-T% > 51
   30 SOUND 3,-15,237,10

See the tables in this section: https://tobylobster.github.io/mos/mos/S-s15.html#SP31 for the best pitch values to use for musical notes.

As often happens when I started looking into the SN76489 what I had thought would be a simple abstraction soon changed and continued to the further I looked. When I tabulated the values I was using for sounds I quickly noticed the error you mention. Also the accumulation of error as I generated the samples. I increased the value I was dividing to get the half period in a quasi 16:16 fixed point format that avoided used of floats and allowed better approximation of the half periods along with less accumulated error as the sample generation progresses.

I appreciate the pointers to your links. I will review this. I have come this far so I think I should try and make the library as accurate as possible.

What continued to amaze me is just how much functionality was crammed into the BBC MOS and only 16KB maximum code space. Quite a work of art really.