The effect you reported was not a bug. Changing it would have added a bug.
Music 5000 in B-Em
Re: Music 5000 in B-Em
Last edited by CHRISJJ on Sat Sep 30, 2023 12:56 pm, edited 1 time in total.
Re: Music 5000 in B-Em
Sorry I'm referring now to the PHSET issue. Not LR
Re: Music 5000 in B-Em
Okay I'm confused . If PHSET is high then the the B inputs to the adder are zero so the phase ram gets set the the current frequency if I understand your design. The code currently sets the phase ram to zero which I think is wrong.
Last edited by dp11 on Sat Sep 30, 2023 1:09 pm, edited 1 time in total.
Re: Music 5000 in B-Em
Note: attribution error.
PHSET is an AMPLE control keyword (defined in M5), not a signal. That's what I meant above by PHSET.
I'll interpret your "If PHSET is high" as "if frequency bit 0 is high".
Shame this signal doesn't have a name on the schematic. It can't really, because it is multiplexed. In schematic namespace it is "DATA AND S1" ... or arguably that plus "AND NOT Ø1". See IC3 pins 11,12. Let's name it PZ.
Yes, where "current frequency" refers to the value stored (for channel 0) in &00-&02 - a name some might find misleading given that value may alternatively be the phase value being written. Let's name it FP.
I apologise. I misinterpreted this the first time around. Note "phase RAM" is a bit misleading since the RAM chip holding phase holds other stuff too.
Yes, setting the stored phase value to zero is incorrect.
Setting the adder input phase value to zero is correct. Hence my "Phase set to zero (upon ON GATE) is correct behaviour (of ON PHSET)".
And the effect of that is to set the stored phase value to FP.
BUT this cannot be the bug sought. The resulting discrepancy is tiny and inaudible especially in this instrument, and even it it was larger, it would not cause the issue I reported. Again, the issue is not phase being set wrong, but phase not being set at all - by PHSET. I.e. ON PHSET acts as OFF PHSET.
Having said that, good that you did fix the code fault you did find, since that discrepancy could be materially large in some very different instrument.
It might help to consider the fact that signal PZ is also used by control word SYNC as well as PHSET, and despite that ON PHSET fails, ON SYNC works. The two differ in implementation. SYNC is implemented in hardware (as a modulation) whereas PHSET is implemented in software, with the timing critical code I mentioned above.
Thanks again.
Last edited by CHRISJJ on Sat Sep 30, 2023 11:31 pm, edited 1 time in total.
Re: Music 5000 in B-Em
Lots of super useful info. My quest continues.
Re: Music 5000 in B-Em
That is unfortunate. It sounds simple enough but which one is wrong? The recording was made with a Scarlett 4i4 and I definitely have the black lead from the Music 500 in channel 1 and the red one in channel 2 but this is one of those fancy interfaces with multiple routing options. Then who is to say I have the DIN plug at the other end wired correctly.
Then, with B-Em, the record to file option could conceivable be reversed compared to sending the sound to the OS sound drivers. Or the Music 5000 emulation may have a channel swap within it somewhere. We'll have to start with a couple of lines of AMPLE to play test sounds.
I can do that in due course. Hopefully this doesn't up looking at PHSET.
Re: Music 5000 in B-Em
I just loaded the flac and the wav output into audacity. And LR swap was obvious. Lots of places it can happen, it's easily done.
Re: Music 5000 in B-Em
Testing B-Em first, in AMPLE BCE:
gives a tone on the left channel and:
gives a tone on the right channel. Is this right. I cannot find the Music 500 guide and the moment.
EDIT: The Music 5000 (AMPLE NUCLEUS) guide has POS working that way round, negative for left and positive for right. Testing with my hardware Music 500 it seems the left channel is on the red plug so either I have put the plugs on the wrong way round or wired the DIN plug at the other end with the pins swapped.
I need to go out now but I will use an editor to swap the channels around on those recordings and re-upload but until then, it looks like all the hardware recordings I have uploaded will have this same channel swap.
Code: Select all
SOUND -3 POS ON GATECode: Select all
SOUND 3 POS ON GATEEDIT: The Music 5000 (AMPLE NUCLEUS) guide has POS working that way round, negative for left and positive for right. Testing with my hardware Music 500 it seems the left channel is on the red plug so either I have put the plugs on the wrong way round or wired the DIN plug at the other end with the pins swapped.
I need to go out now but I will use an editor to swap the channels around on those recordings and re-upload but until then, it looks like all the hardware recordings I have uploaded will have this same channel swap.
Re: Music 5000 in B-Em
There’s one on 8BS “BBC Series Hardware” page at http://8bs.com/othrdnld/manuals/hardwarebbcseries.shtml and direct to the zipped PDF
It’s a bit contradictory on which way is right and left, though:
Re: Music 5000 in B-Em
Goldwave for Windows free evaluation version will do this in batch processing.
Re: Music 5000 in B-Em
Thanks. I think this may be the source of the issue, then. Looking at my cable, the 5-pin DIN plug is wired with the red wire to pin 3 and the white to pin 5 which is, according to https://pinoutguide.com/visual/gen/DinAudio.jpg, the wrong way round.
Back in the 1980s, though, I probably didn't have a pinout for a 5-pin DIN plug handy and probably would have done it by experiment, i.e. set up the Music 500 to output on one channel and see which pin has the signal on it. If I followed the text, rather than the code, in the manual that would have guided me into wiring it incorrectly and it has been like it ever since.
Re: Music 5000 in B-Em
Where's the errata sheet when you need it ...
Page 28 is correct:
Apologies!
Wouldn't you have spotted that the Studio 5000 Mixing Desk pan pots were reversed?
Re: Music 5000 in B-Em
Thanks, Chris.CHRISJJ wrote: ↑Sat Sep 30, 2023 7:13 pm Goldwave for Windows free evaluation version will do this in batch processing.
I have now uploaded version of all the recent hardware recordings with the channels now the right way round.
Re: Music 5000 in B-Em
Hoglet, dp11, Coeus,
On the Music 5000 "Assault on Precinct 13" PHSET fail, here's a clearer demo of the same problem:
There may be a second problem there too. In PAD, Drum is not performing as expected with OFF PSENS, OFF PHSET. But I cannot (yet) see how that can be due to any synth bug, so should not obstruct progress on PHSET.
On the Music 5000 "Assault on Precinct 13" PHSET fail, here's a clearer demo of the same problem:
There may be a second problem there too. In PAD, Drum is not performing as expected with OFF PSENS, OFF PHSET. But I cannot (yet) see how that can be due to any synth bug, so should not obstruct progress on PHSET.
Re: Music 5000 in B-Em
I 've worked out an issue. Just need to work out how fix it correctly.
Re: Music 5000 in B-Em
Again thanks very much for this extra info. I've got my self a little stuck in understanding the circuit diagram. I wonder If you can help?
Here is a little timing diagram I've created, please point out any errors.
Re: Music 5000 in B-Em
Great work!
None seen in what I understand there, but that is subject to interpretation of your own labels. This diag would be really usuful in future if all its labels were objective e.g. schematic signal names or boolean expressions thereof.
Yup. This latching postpones amplitude change until waveform zero crossing, ensuring no discontinuity in product.
C
Last edited by CHRISJJ on Tue Oct 03, 2023 8:59 pm, edited 1 time in total.
Re: Music 5000 in B-Em
Certainly I've not seen it mentioned.
Re: Music 5000 in B-Em
Re: Music 5000 in B-Em
As you're looking at timing, I had a thought, also related to Chris's observation that changing the speed of the emulated machine in the Speed menu does not change the pitch of the Music 5000.
I am not sure how the original hardware handles writes coming in from the 6502 aligned to the 1Mhz bus clock, and then much of the hardware running on its own 16Mhz clock, but there is going to be a high degree of parallelism here, i.e. the Music 5000 is processing whatever it is in its RAM while AMPLE is working out what to write to that RAM next.
In B-Em there isn't real parallelism because it is driven by events.
The 6502 emulation is advanced in response to a timer event. As currently configured, that runs one frame of 6502 instructions, i.e. 40,000 2Mhz cycles. During those 40,000 cycles the things that happen are those tied to the 6502 emulation so, in the case of the Music 5000, this includes writes from the CPU to the RAM, i.e. calls to the music5000_write function but the rest of the Music 5000 is not advancing at all.
Between these timer events, there may be events from the sound system to call for another buffer-full of samples to play. It is in response to these that the function music5000_fillbuf is called and that in turn advances the state of the Music 5000 far enough to get a buffer-full of samples. Currently the default size of that buffer is 1,500 samples.
So the CPU is advancing in bursts of 40,000 cycles every 20ms and the Music 5000 is advancing in bursts of 1500 samples every 32ms. As 32 is not a multiple of 20 that means, even without the sound card clock drifting with respect to whatever is used for the interval timer, there won't be strict alternation between the two. Could this be the cause of the apparent randomness in how things don't work as they should?
The other question is whether these bursts are too long, i.e. whether there needs to be a swap between advancing the CPU and advancing the Music 5000 more often.
I am not sure how the original hardware handles writes coming in from the 6502 aligned to the 1Mhz bus clock, and then much of the hardware running on its own 16Mhz clock, but there is going to be a high degree of parallelism here, i.e. the Music 5000 is processing whatever it is in its RAM while AMPLE is working out what to write to that RAM next.
In B-Em there isn't real parallelism because it is driven by events.
The 6502 emulation is advanced in response to a timer event. As currently configured, that runs one frame of 6502 instructions, i.e. 40,000 2Mhz cycles. During those 40,000 cycles the things that happen are those tied to the 6502 emulation so, in the case of the Music 5000, this includes writes from the CPU to the RAM, i.e. calls to the music5000_write function but the rest of the Music 5000 is not advancing at all.
Between these timer events, there may be events from the sound system to call for another buffer-full of samples to play. It is in response to these that the function music5000_fillbuf is called and that in turn advances the state of the Music 5000 far enough to get a buffer-full of samples. Currently the default size of that buffer is 1,500 samples.
So the CPU is advancing in bursts of 40,000 cycles every 20ms and the Music 5000 is advancing in bursts of 1500 samples every 32ms. As 32 is not a multiple of 20 that means, even without the sound card clock drifting with respect to whatever is used for the interval timer, there won't be strict alternation between the two. Could this be the cause of the apparent randomness in how things don't work as they should?
The other question is whether these bursts are too long, i.e. whether there needs to be a swap between advancing the CPU and advancing the Music 5000 more often.
Re: Music 5000 in B-Em
Simple. 1MHz writes to a D-type latch and 16MHz reads from it.
Oops. That won't work for Music 5000 just as it wouldn't work for other fast peripherals e.g. TMS sound chip, VIA..Coeus wrote: ↑Wed Oct 04, 2023 9:14 amAs currently configured, that runs one frame of 6502 instructions, i.e. 40,000 2Mhz cycles. During those 40,000 cycles the things that happen are those tied to the 6502 emulation so, in the case of the Music 5000, this includes writes from the CPU to the RAM, i.e. calls to the music5000_write function but the rest of the Music 5000 is not advancing at all.
Yes. Every cycle. Just as presumably is already done for VIA.
The further issue ISTM this frame size is insufficient to resolve the 100Hz Music 5000 envelope tick, which could explain some other oddities I hear, and would hear better with PHSET fixed.
Re: Music 5000 in B-Em
Ok, there is more to do here then but, as I was experimenting with this anyway, I have pushed a commit to: https://github.com/stardot/b-em/tree/sf/m5000-filt which reduces the length of the "slice" or time devoted to each thing to 8ms, i.e. 125 slices/second. That should now be faster than the envelope tick. It doesn't pass the 16 fast and very short drum beats a couple of posts up, but to my ear at least, seems to have made a noticeable improvement to typical music.
To convert the MUsic 5000 to a tightly integrated peripheral like the 6522 will need some more thinking about.
To convert the MUsic 5000 to a tightly integrated peripheral like the 6522 will need some more thinking about.
Re: Music 5000 in B-Em
Nice. But note that slice/frame can still pseudo-randomly fall inside the synth's 100Hz update tick, so audibly break apart normally near-simultaneous events across channels.Coeus wrote: ↑Wed Oct 04, 2023 3:18 pmI have pushed a commit to: https://github.com/stardot/b-em/tree/sf/m5000-filt which reduces the length of the "slice" or time devoted to each thing to 8ms, i.e. 125 slices/second.
Great. That should ensure no missed ticks, but will leave sufficient jitter to audibly malform fast envelopes e.g. Studio 5000 INS1 Click.
As expected. Probably best I hold off listening until PHSET is working.
Coroutines?
Re: Music 5000 in B-Em
Is there a simple test case for PHSET, like the drum one above?
At the moment, the smallest amount we can advance the Music 5000 by is the time taken to generate one pair of PCM samples, i.e. one for the left stereo output and one for the right stereo output. That appears to process all 16 of the Music 5000 channels exactly once. The relevant function in the source is called music5000_get_sample.
At the moment, an event from the Allegro sound layer saying it wants a new buffer full of samples causes music5000_get_sample to be called in a loop to fill the buffer, i.e. after the latest change, 8ms worth of samples.
Writes to the RAM arrive via a function music5000_write. Without needing to hook into the CPU emulation in any other way, as long as we can measure the number of clock cycles since the last call to music5000_write, we can advance the Music 5000 by the right amount. The generated samples would then need to be added to a buffer.
The issue with this approach is handing the buffer off to Allegro's, and thus ultimately, the OS's sound system. In theory, this should be generating samples at exactly the right rate for the sample rate we declared when creating the sound stream but in practice it is likely to drift leading to either overruns or underruns. It also complicates changing the general speed of the machine.
Re: Music 5000 in B-Em
The Drum one above is for PHSET.
No problem there.Coeus wrote: ↑Wed Oct 04, 2023 3:18 pmAt the moment, the smallest amount we can advance the Music 5000 by is the time taken to generate one pair of PCM samples, i.e. one for the left stereo output and one for the right stereo output. That appears to process all 16 of the Music 5000 channels exactly once.
Oops. One orchestra, two conductors.
Presumably this makes also the BBC internal sound chip is inaccurate. Just it is less sensitive.
... the correct right amount being no more than one CPU 1MHz bus access.
More, and CPU->synth data is lost e.g. PHSET, and in extreme keyboard->sound suffers latency.
Indeed. The classic middleware problem. Middleware makes the stuff it thinks you want easier at the price of making stuff it didn't think of much harder. B-Em is unusual in that almost nothing it wants is what Allegro is designed to provide.Coeus wrote: ↑Wed Oct 04, 2023 3:18 pmThe issue with this approach is handing the buffer off to Allegro's, and thus ultimately, the OS's sound system. In theory, this should be generating samples at exactly the right rate for the sample rate we declared when creating the sound stream but in practice it is likely to drift leading to either overruns or underruns.
I suspect the simplest fix will hinge on how far Allegro can be thinned here e.g. smallest buffer size.
Indeed that feature looked brave to me
Re: Music 5000 in B-Em
Steve, I've just been looking back at how things worked with Allegro 4.
As far as I remember (and from looking at the code) every 64us of CPU emulation, three stereo Music 5000 samples were generated. You can see the code here (commented out as it was no longer used in Allegro 5):
https://github.com/stardot/b-em/blob/6d ... ound.c#L69
The Allegro 4 version does a much better job with the Drum test case.
Do you think you could record the Drum test case on the real Music 5000 please? I'd like to confirm that my FPGA implementation is handling this correctly.
Dave