Music 5000 in B-Em

[hoglet]

To convert the MUsic 5000 to a tightly integrated peripheral like the 6522 will need some more thinking about.

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

[Coeus]

The Allegro 4 version does a much better job with the Drum test case.

As you still have a copy built, could you record the output, please? If that is not easy I can try re-building it.

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.

Recording at: https://drive.google.com/drive/folders/ ... share_link

[hoglet]

As you still have a copy built, could you record the output, please? If that is not easy I can try re-building it.

Here's the recording.

drum_allegro4.zip

(377.47 KiB) Downloaded 24 times

(The filtered version was post-processed in Audicity)

To generate this, all I did was boot the MUSIC5000.ssd disc included with B-Em, then hit escape and entered:

Code: Select all

READY 1 VOICES Drum 1 CHAN 0 AMP
12, XXXX XXXX XXXX XXXX
12, XXXX XXXX XXXX XXXX

Is this correct, or am I using the wrong disc image?

(there was no track called assault, and I couldn't find that attached to this thread)

There are 16 bursts, but this sounds nothing like the original.

So something is very wrong, and the FPGA version is pretty simular.

Dave

[Coeus]

To generate this, all I did was boot the MUSIC5000.ssd disc included with B-Em, then hit escape and entered:

Code: Select all

READY 1 VOICES Drum 1 CHAN 0 AMP
12, XXXX XXXX XXXX XXXX
12, XXXX XXXX XXXX XXXX

Is this correct, or am I using the wrong disc image?

I don't have MUSIC5000.ssd in the latest B-Em distribution, though it may have been current at the time of the Allegro 4 version. There is a file of that name on by MMFS2 SD card, which is the one I used for the recording. I'll add it to the Google drive for reference.

Meanwhile B-Em now comes with Music5plus3000.ssd

(there was no track called assault, and I couldn't find that attached to this thread)

No that is on a different disc called MusicCity which I have uploaded along with the recordings of the same to: https://drive.google.com/drive/folders/ ... share_link

There are 16 bursts, but this sounds nothing like the original.

Yes, the recording you attached sounds more like clicks and the one from the hardware more like thumps. I'll try with the SDD from B-Em to see if it makes any difference.

[hoglet]

Steve,

Can you detail the steps you followed to play the Drum test case that you recorded?

i.e. Install these ROMs, power on machine, boot this disk, switch to that disk, type xxx then yyy.

My understanding of using Music 5000 and AMPLE is pretty minimal. I have no idea, for example, if the test case depends on the waveforms that are loaded as part of booting the system disk, or do I first need to load/run "Assault on Precinct 13"?

Also, the ROMs, which need to match the system disk?

I'm getting the same behaviour (i.e. short clicks rather than solid base drum beats) on the FPGA, which makes me think I'm not running the test case properly. Something is definitely not right!

Dave

[Coeus]

I have uploaded a second recording to the same Google Drive folder that was made using the disc Music5plus3000.ssd which is in the current B-Em distribution. That one is a series of clicks rather than thumps.

I have a Music 500 rather than a Music 5000. The only change I am aware of is the timing fix for the 1Mhz bus to make it work on the Master so I am having to do the hardware recording on a Model B with sideways RAM. AMPLE seems to be happy with that, though the !BOOT file on the disc assumes a Master so the sequence for this latest recording was:

Code: Select all

*DIN M5PLUS3.SSD
*SRLOAD R.AMPLE 8000 1
<hit break>
*E.RUNNER
<tab>
READY 1 VOICES Drum 1 CHAN 0 AMP
12, XXXX XXXX XXXX XXXX

M5PLUS3.SSD is what I called this disc when I copied it over to the SD card. Skipping !BOOT and doing the ROM load manually is the concession to this being a BBC B. I didn't bother to load ANHF. <break> is so the OS recognises the ROM so *AMPLE works and <tab> is to get out of the Studio menu back to the command prompt.

[hoglet]

Steve,

To avoid confusion, can you attach the disk image that resulted in the correct (thumpy) drum sound to this thread.

Dave

[CHRISJJ]

I have no idea, for example, if the test case depends on the waveforms that are loaded as part of booting the system disk

It does. And "Studio 5000" in the screenshot IDs these waveforms, which are unchanged across versions for this titke.

or do I first need to load/run "Assault on Precinct 13"?

No.

Also, the ROMs, which need to match the system disk?

One ROM, AMPLE Nucleus, and any deDRMed (patched) copy will accept the system disc.

[CHRISJJ]

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.

Recording at: https://drive.google.com/drive/folders/ ... share_link

I suggest that identify which of its two recordings is above test's.

[CHRISJJ]

I'm getting the same behaviour (i.e. short clicks rather than solid base drum beats) on the FPGA

The expected output is short bursts, not solid bassdrum beats.

[hoglet]

The expected output is short bursts, not solid bassdrum beats.

Looking in audacity at Steve's two recordings (from real hardware), I'm seeing:
01_phset_test.flac:

02_phset_test.flac:

So Chris, are you saying it's the second one (02_phset_test) that is correct?

Dave

[CHRISJJ]

So Chris, are you saying it's the second one (02_phset_test) that is correct?

Yes - except I'd expect L==R. I'd guess the first is from faulty input text.

Also worth checking is the quantity and uniformity of spacing.

[Coeus]

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

I have pushed a branch that returns to that approach and it does do much better at the drum test. The only slightly weird thing is that the first two hits seem too close together.

See: https://github.com/stardot/b-em/tree/sf/m5000-push2

[hoglet]

Hi Steve,

I have pushed a branch that returns to that approach and it does do much better at the drum test. The only slightly weird thing is that the first two hits seem too close together.

Great, I'll play with this later.

I actually see the same thing with the FPGA implementation, which is quite strange.

I also found if you do:

Code: Select all

*KEY 0 12, XXXX XXXX XXXX XXXX|M

and press F0 several times quickly, it's only the spacing between the first two hits in the first burst that is incorrect. Everything else is fine.

Maybe Chris has some ideas?

I was planning to investigate this with the ICE debugger over the weekend.

Going back to an earlier post where you uploaded two recordings:
- 01_phset_test.flac
- 02_phset_test.flac

Could you comment on excactly what each recording was? i.e. real hardware? which system disk?

I'm trying to understand what's responsible for the difference between them, and whether it's reprodicble. I have only been able to reproduce the second case: 02_phset_test.flac

Dave

[Coeus]

Yes - except I'd expect L==R. I'd guess the first is from faulty input text.

The channel imbalance is due to one of the gain knobs on the recording interface having been moved and I having not noticed. I did set them by making sure the channel meters were the same on a simple tone panned to centre before the previous set of recordings but this time I didn't re-check.

[Coeus]

Going back to an earlier post where you uploaded two recordings:
- 01_phset_test.flac
- 02_phset_test.flac

Could you comment on excactly what each recording was? i.e. real hardware? which system disk?

Both recordings are from the same hardware Music 500 attached to the same BBC Model B. I did describe exactly what I did to generate the second file, 02_phset_test.flac, in a post above: viewtopic.php?p=404707#p404707

The only definite difference is the SSD loaded at the time. For the first file, 01_phset_test.flac, this was M5000.SSD in the Google Drive folder above and for 02_phset_test.flac, it is Music5plus3000.ssd included with the current B-Em distribution, m5sum b31d85a182b04422978953acc6b779f6.

It seems the different disk is not the explanation for the difference, though, as I cannot reproduce the 1st recording, on the real hardware, even with the M5000.SSD file.

[hoglet]

Dominic pointed out a possible bug in the FPGA implementation, where amplitude changes are not correctly synchronized to waveform zero crossings.

I wrote a test case for this:

Code: Select all

   10 P%=&2000
   20[
   30.test
   40 LDA #&3E
   50 STA &FCFF
   60 LDA #&BE
   70 STA &FD01
   80 LDA #&6D
   90 STA &FD11
  100 LDA #&01
  110 STA &FD21
  120 LDA #&C0
  130 STA &FD51
  140 LDA #&0D
  150 STA &FD71
  160 LDA #&7F
  170.loop
  180 STA &FD61
  190 EOR #&10
  200 LDX #&10
  210 LDY #&00
  220.delay
  230 DEY
  240 BNE delay
  250 DEX
  260 BNE delay
  270 JMP loop
  280]
  290 CALL test

It turns out this is indeed a real bug, as you can see obvious discontinuities in the waveform:

After much head scratching, I've have a fix:
https://github.com/hoglet67/Music5000/commit/2eaa41c9

I no longer see disconuities on the scope:

Dominic, if you could cast your eye over this I would be greatful.

Dave

[dp11]

Dominic, if you could cast your eye over this I would be greatful.

Dave

Will do. Just thinking here not checked but "zero crossing here " should it really be "negative going zero crossing" ?

[CHRISJJ]

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

I have pushed a branch that returns to that approach and it does do much better at the drum test.

As expected.

The only slightly weird thing is that the first two hits seem too close together.

That's expected - due to command-line processing time delaying the first hit.

But - apologies - my "Expected: 16 uniformly spaced bursts" was inaccurate. Corrected here:



I've also included the system disc description. I suggest that system release issue be used for all testing of this issue.

[CHRISJJ]

I actually see the same thing with the FPGA implementation, which is quite strange.

If that's FPGA Music 5000 driven by BBC Micro, I agree that's strange. I suspect a fault in the FPGA.

If that's FPGA Music 5000 driven by B-em, that's expected.

I also found if you do:

Code: Select all

*KEY 0 12, XXXX XXXX XXXX XXXX|M

and press F0 several times quickly, it's only the spacing between the first two hits in the first burst that is incorrect. Everything else is fine.

Maybe Chris has some ideas?

The first X is delayed by command-line processing time. The subsequent ones play on time.

[CHRISJJ]

The only definite difference is the SSD loaded at the time. For the first file, 01_phset_test.flac, this was M5000.SSD in the Google Drive folder above and for 02_phset_test.flac, it is Music5plus3000.ssd included with the current B-Em distribution, m5sum b31d85a182b04422978953acc6b779f6.

It seems the different disk is not the explanation for the difference

Nevertheless, I would not be surprised for addition of 3000 to affect 5000 sound whilst B-Em is inaccurate, so I suggest omit 3000 for this testing.

[CHRISJJ]

Dominic pointed out a possible bug in the FPGA implementation, where amplitude changes are not correctly synchronized to waveform zero crossings.

It turns out this is indeed a real bug, as you can see obvious discontinuities in the waveform:

That's what I'd expect to see and hear from such a bug. A more extreme and hence I'd say better test is to switch amplitude between zero and max.

After much head scratching, I've have a fix:
https://github.com/hoglet67/Music5000/commit/2eaa41c9

I no longer see disconuities on the scope:

That's what I'd expect to see and hear from a true fix. But seeing how different from the original logic is the FPGA's logic there, I would not be surprised if other inaccuracies around this remain. I guess there's a good reason the FPGA logic is so different, but the price of that will I think turn out higher than one might expect.

[CHRISJJ]

Will do. Just thinking here not checked but "zero crossing here " should it really be "negative going zero crossing" ?

Good question.

Answer: No.

This is where we need a remastered schematic with signals hyperlinked within and to dp11's operations chart... and ideally also to charts for key cases such as this amplitude postponement. Those charts would ideally be made by a simulator. Does a tool for this yet exist?

[dp11]

There is the Kicad version of the schematic where we can label nets more accurately and add notes.https://github.com/jlprojects/music5xxx

[BigEd]

Do we know - perhaps CHRISJJ knows - if the schematic we're working from exactly matches the hardware as built?

[hoglet]

I actually see the same thing with the FPGA implementation, which is quite strange.

If that's FPGA Music 5000 driven by BBC Micro, I agree that's strange. I suspect a fault in the FPGA.

Yes, this is the FPGA Music 5000 driven by a BBC Master.

The only issue with the Drum text case is a shortened time interval between the first and second hits.

But based on your other comments, I think this is to be expected:

That's expected - due to command-line processing time delaying the first hit.

Although it wasn't present on the recording Steve posted from real hardware, but maybe he just got lucky?

Dave

[CHRISJJ]

There is the Kicad version of the schematic where we can label nets more accurately and add notes.https://github.com/jlprojects/music5xxx

That's for a reimplementation, and despite the description "clone", is a variant on the original.

Perhaps the author has a schematic of the original from which the reimplementation was derived?

[dp11]

Do you mean this one. ? http://www.retro-kit.co.uk/user/custom/ ... ematic.pdf The Kicad is very close.

[CHRISJJ]

Do we know - perhaps CHRISJJ knows - if the schematic we're working from

I've not seen anything identified as the schematic you are working from.

exactly matches the hardware as built?

I can say I am 99% sure that my 1984 hand-written schematic matches the Music 500 hardware as built - of which TMK and FWIW there was only one PCB issue, "ISSUE 2".

Hence verifying a remastered schematic matches the hand-written one will probably verify the remastered schematic matches all production units.

[CHRISJJ]

I actually see the same thing with the FPGA implementation, which is quite strange.

If that's FPGA Music 5000 driven by BBC Micro, I agree that's strange. I suspect a fault in the FPGA.

Yes, this is the FPGA Music 5000 driven by a BBC Master.

The only issue with the Drum text case is a shortened time interval between the first and second hits.

But based on your other comments, I think this is to be expected:

That's expected - due to command-line processing time delaying the first hit.

Agreed.

Although it wasn't present on the recording Steve posted from real hardware

Worth checking. E.g. count the bursts.