Music 500 -> Music 5000 and Music 500 -> Music 3000

[hoglet]

Thanks for the help. The ALU seems to wander off into the bracken quite quickly from reset, yet despite changing all the logic ICs, I am still getting the same sound as I had before. Maybe there's a fault on the board somewhere that is causing this issue?

I hadn''t realized you had already swapped out all of the logic ICs.

What ICs haven't been replaced?

If you run the "Siren" test I posted earlier in the thread, do both systems sound (and scope) the same?

I think the key to debugging this will be to find the simpest test case where there is a difference.

Dave

[maniacminer]

Ah, yes, I removed all the ICs and replaced them with sockets (photos of that palaver are in this thread) - binned the faulty few, then replaced all the logic, then the RAM and then the DAC. I'll try the sine wave program again, the first time I ran it I didn't get a sine wave from it.

[maniacminer]

If you run the "Siren" test I posted earlier in the thread, do both systems sound (and scope) the same?

I connected up my Zoom recorder and measured both M5000's after running the program earlier in this thread. I don't get a sine wave out of either...

[hoglet]

I don't get a sine wave out of either...

Indeed - I need to fix the test program to generate a true sine wave. I'll post an update later.

But ignoring the waveform shape for now, it looks like the frequency is different between the two systems? Or are the two waveforums not on the same scale?

Dave

[maniacminer]

I don't get a sine wave out of either...

Indeed - I need to fix the test program to generate a true sine wave. I'll post an update later.

But ignoring the waveform shape for now, it looks like the frequency is different between the two systems? Or are the two waveforums not on the same scale?

The waveforms are the same, just taken at different siren intervals. I unplugged one M5000 from the Zoom and plugged it into the other, so they're not perfectly synchronised by any measure.

[hoglet]

Here's an updated version of the test program that should generate a fairly accurate sine wave.

m5000test.ssd

(1.5 KiB) Downloaded 2 times

The change is how the wave data is generated.

The old code did:

Code: Select all

FOR J=0 TO 127
J?&FD00=SIN(2*PI*J/128)*127
NEXT

This is wrong in two respects:
- It doesn't take account of the non-linear characteristic of DAC
- It doesn't correctly format the data as sign (1 bit) + magnitude (7 bits)

The new code does:

Code: Select all

FOR J=0 TO 127
S=SIN(2*PI*(J+0.5)/128)
T=22.903*LN(1+255*ABS(S))
IF S>0 THEN T=T+128
J?&FD00=T
NEXT

Dave

[hoglet]

Here's an updated version of the test program that should generate a fairly accurate sine wave.

m5000test.ssd

(1.5 KiB) Downloaded 4 times

The change is how the wave data is generated.

The old code did:

Code: Select all

FOR J=0 TO 127
J?&FD00=SIN(2*PI*J/128)*127
NEXT

This is wrong in two respects:
- It doesn't take account of the non-linear characteristic of DAC
- It doesn't correctly format the wave data as sign (1 bit) + magnitude (7 bits)

The new code does:

Code: Select all

FOR J=0 TO 127
S=SIN(2*PI*(J+0.5)/128)
T=22.903*LN(1+255*ABS(S))
IF S>0 THEN T=T+128
J?&FD00=T
NEXT

Dave

[maniacminer]

Here's an updated version of the test program that should generate a fairly accurate sine wave.

I have run the new code, thanks. I now get a sine wave output (yay!) There is a minor difference in amplitude between the two, but not really significant. The recording looks normal and is otherwise identical between the "good" and "bad" M5000's.

[hoglet]

The recording looks normal and is otherwise identical between the "good" and "bad" M5000's.

This is quite perplexing.

For that test to work, quite a lot of the Music 5000 has to be fine.

Maybe the failure affects just certain channels?

So I wonder if it's worth testing all 8 channel pairs work, by tweaking these lines:

Code: Select all

  270 C0=&FD00:REM Channel 0
  280 C1=&FD01:REM Channel 1

i.e. to test channels 2 and 3, change them to:

Code: Select all

  270 C0=&FD02:REM Channel 2
  280 C1=&FD03:REM Channel 3

Or maybe it affects certain frequencies, which are determined by:

Low tone:

Code: Select all

  350 C1?&00=&BE
  360 C1?&10=&6D
  370 C1?&20=&01

High tone:

Code: Select all

  410 C1?&80=&BE
  420 C1?&90=&6D
  430 C1?&A0=&02

The frequency should be this value multiplied by 46875 then divided by 2^24:
- Low tone = 0x016DBE * 46875 / 2^24 = 261.6Hz (Middle C)
- High tone = 0x026DBE * 46875 / 2^24 = 444.7Hz
(assuming the wave RAM contains just one cycle)

Dave

[maniacminer]

So I wonder if it's worth testing all 8 channel pairs work, by tweaking these lines:

I ran the test on the other six channels on both units but the output is identical.

Sine Wave Test CH2 and CH3 good vs bad

Sine Wave Test CH4 and CH5 good vs bad

Sine Wave Test CH6 and CH7 good vs bad

[hoglet]

I ran the test on the other six channels on both units but the output is identical.

There are 8 further channels you could test as well (16 in total):
- Channels 8+9
- Channels 10+11
- Channels 12+13
- Channels 14+15

I expect they will also be identical, but it's probably worth confirming.

What ICs from the original Music 500 remain?

Dave

[maniacminer]

There are 8 further channels you could test as well (16 in total):

I expect they will also be identical, but it's probably worth confirming.

Yes, the signals are identical. However, something I did find rather weird, if I change the pitch values the "good" M5000 goes quiet but the "bad" M5000 tries to play the tones, when I picked values like 330 and 545 odd things happened...

What ICs from the original Music 500 remain?

None apart from the 7805.

[hoglet]

Yes, the signals are identical. However, something I did find rather weird, if I change the pitch values the "good" M5000 goes quiet but the "bad" M5000 tries to play the tones, when I picked values like 330 and 545 odd things happened...

That's very interesting....

Can you give a specific example of the register values that behaved differently?

Bit 0 of the LSB frequency register (&FDx0) has a special function - it's called the phase set bit, and also acts as a channel disable bit.

Setting this bit to a one (i.e. an odd number) should disable the corresponding channel.

It sounds like this is working correctly on the "good" M5000, but not on the "bad" M5000.

Can you double-check this?

The channel disable function is implemented by this bit of the circuitry:

If you have a test case where the "bad" and "good" are definitely behaving differently, I would probe around that area with a scope.

I would also check for shorts between DATA[0] (e.g. IC13 pin 3) and other signals. Especially other data bits, but it could be anything.

Dave

[maniacminer]

Cool, thanks. I wasn't aware of the function of bit0 on the LSB of the frequency register. Is there a list of these anywhere? I'll do some more tests today. I thought the "good" M5000 had become "bad" because it kept cutting out at different frequencies - there's always a risk 'scoping around a PCB that an inadvertent slip of the hand causes hours of repairs...

[hoglet]

Cool, thanks. I wasn't aware of the function of bit0 on the LSB of the frequency register. Is there a list of these anywhere?

The Music 5000 FPGA Wiki page contains my notes:
https://github.com/hoglet67/Music5000/w ... y-register

[maniacminer]

Cool, thanks. I wasn't aware of the function of bit0 on the LSB of the frequency register. Is there a list of these anywhere?

The Music 5000 FPGA Wiki page contains my notes:
https://github.com/hoglet67/Music5000/w ... y-register

That's an excellent resource, thanks! I scoped out the "good" and "bad" M5000 and yup, D0 is different and that drives data input to the flip-flop that in turn with ADDR0 drives the "mute" circuitry. I notice in some music that fades, those fades turn to crunchy fades on the "bad" unit - I suspect this is the reason, almost as if something is being done that should be inaudible. As for the cause, I am no closer to identifying it as everything is free-running, it just seems to go wild at some point. I couldn't find any shorts, I had a poke about with the multimeter between all the "data" lines and they read point-to-point normally and within 10R of 1kR to ground.

[hoglet]

That's an excellent resource, thanks! I scoped out the "good" and "bad" M5000 and yup, D0 is different and that drives data input to the flip-flop that in turn with ADDR0 drives the "mute" circuitry.

I wonder if the Wave RAM writes from the host are somehow getting corrupted.

Are you testing on a Master or a Model B?

It might be worth confirming the "bad" M5000 fails on both machines.

Also, has this been modded for Master use? Double check the correct R/C values have been used.

Dave

[Dave C]

Out of interest does anyone know what BCE stood for in Ample BCE?
Dave C

[james]

Out of interest does anyone know what BCE stood for in Ample BCE?

Apparently even the author doesn’t know: https://www.stardot.org.uk/forums/viewt ... 29#p403829

[maniacminer]

I just assumed it was BBC Cassette Edition

[maniacminer]

That's an excellent resource, thanks! I scoped out the "good" and "bad" M5000 and yup, D0 is different and that drives data input to the flip-flop that in turn with ADDR0 drives the "mute" circuitry.

I wonder if the Wave RAM writes from the host are somehow getting corrupted.

Are you testing on a Master or a Model B?

It might be worth confirming the "bad" M5000 fails on both machines.

Also, has this been modded for Master use? Double check the correct R/C values have been used.

Dave

I was testing on a rather tortured (the nice Flash/SRAM board guinea pig) BBC Model B disc/Econet. I tried another couple of Beebs that I just got working (repair threads for those two!) and they performed exactly the same. I dug out the Master and tried that, after lots of aggro with GoSDC, Master RAM/ROM cartridges and ANFS 4.25 I ended up burning an EPROM and putting it in the ROM socket on the cartridge. Solved all that aggro and ended up, yup, exactly the same. So on the plus side, all the M5000's in a chain perform exactly the same as they did on any Beeb and the Master. The mod is a couple of track cuts and a bodge wire, a 470R resistor and a 220pF capacitor.

[daveejhitchins]

Also, has this been modded for Master use? Double check the correct R/C values have been used.

Dave

While at last weekend's ABUG my MUSIC 500 was tested on both a BBC and Master - worked on both. The mod I fitted, for the Master, was just the resistor version. I'm thinking that the resistor value and the TTL pin capacitance gives just enough delay to allow working on the Master!

Just a thought!

Dave H.

[maniacminer]

Also, has this been modded for Master use? Double check the correct R/C values have been used.

Dave

While at last weekend's ABUG my MUSIC 500 was tested on both a BBC and Master - worked on both. The mod I fitted, for the Master, was just the resistor version. I'm thinking that the resistor value and the TTL pin capacitance gives just enough delay to allow working on the Master!

Just a thought!

Dave H.

I think it is random as an unmodified M500 works fine on this Master. Perhaps it was problematic due to a change in the source of the 1MHz clock on the 1MHz bus? The B+ has a more complicated cycle stretching circuit, I guess the Master has that wad of TTL incorporated inside one of its ULAs? I'm thinking timing problem...

[maniacminer]

Well, this is strange.

I was pushing/pulling on ICs to see if there were any broken tracks or bad contacts and suddenly everything sounded good. Yay!

I couldn't replicate what I did, so I left it for a day and came back to it and thought what I was doing... I was holding the bottom of the IC extractor and wobbling an IC side to side and it came out of the socket and I put it back in. I reproduced it by putting my fingers back onto the IC in question (IC23/74LS257) and when I got to pin#3 suddenly everything was good.

I have scoped out the PCB and there's no problem with the tracks to and from this IC. It almost feels like a marginal timing issue. A finger is worth 100pF

OK, I've added 100pF on IC23 from pin #8 to pin #3 and yup, the problems vanished.

Damn, I've been through this board, removed all the ICs, replaced them with sockets, put the ICs back in, same problem, then replaced all the TTL with the exact parts (one 74F04 - the remainder LS) - exactly the same problem, then all HCT, same, then all F, same. I tried mixtures, same. Something's gone for a Burton somewhere on the PCB, and a 100pF capacitor seems to solve it will it last?

[hoglet]

OK, I've added 100pF on IC23 from pin #8 to pin #3 and yup, the problems vanished.

Well done fixing this.

In Paul Vernon's decription of the difference between an original M500 and an original M3000 there is a second capacitor mentioned. Specifically, he says:

and an additional 220nF capacitor added to pins 7 and 8 of IC 10.1

Looking at the photo, this is 220pF, not 220nF.

I'm bringing this up because this change seems unrelated to the M3000 addressing change, and so possibly is a fix that Chris found was needed occasionally, so was fitted to later units.

This capacitor is slugging the nS7 signal, possibly to remove a glitch. Now what's interesting is one of the places nS7 is used is on the async clear of IC3, which latches the channel disable signal. A glitch on nS7 would cause a channel to be enabled when it should be disabled.

This is the exact part of the circuit your testing showed was failing.

I don't quite see how your capacitor would have the same effect, but it's possible it does, by changing the sequencing of the inputs of IC10.

Dave

[dp11]

Interestingly, reading Pauls page it says the Studio Mixer automatically detect the M3000 has anyone seen the work ? If so how do it work? Maybe time to do some disassembly.

[maniacminer]

OK, I've added 100pF on IC23 from pin #8 to pin #3 and yup, the problems vanished.

Well done fixing this.

In Paul Vernon's decription of the difference between an original M500 and an original M3000 there is a second capacitor mentioned. Specifically, he says:

and an additional 220nF capacitor added to pins 7 and 8 of IC 10.1

Looking at the photo, this is 220pF, not 220nF.

I'm bringing this up because this change seems unrelated to the M3000 addressing change, and so possibly is a fix that Chris found was needed occasionally, so was fitted to later units.

This capacitor is slugging the nS7 signal, possibly to remove a glitch. Now what's interesting is one of the places nS7 is used is on the async clear of IC3, which latches the channel disable signal. A glitch on nS7 would cause a channel to be enabled when it should be disabled.

This is the exact part of the circuit your testing showed was failing.

I don't quite see how your capacitor would have the same effect, but it's possible it does, by changing the sequencing of the inputs of IC10.

Dave

Yup, adding a 100pF capacitor between pins #7 & #8 of IC10 achieves the same effect. LOL the amount of time I've spent on this... I'll do this mod to all the other "broken" M500s I've got.

[hoglet]

Yup, adding a 100pF capacitor between pins #7 & #8 of IC10 achieves the same effect. LOL the amount of time I've spent on this... I'll do this mod to all the other "broken" M500s I've got.

Very interesting!

At least this is now semi-official! It would be interesting to hear Chris Jordan's take on this.

I expect if you looked at nS7 on a fast enough scope there would be a glitch (as the A[2:0] inputs transition from 101 to 110 via 111).

Dave

[maniacminer]

There are runt pulses on that 74138, but the other "good" M500 also has them and that somehow doesn't exhibit this problem. Although one thing I have noticed is the PSU voltage on the "good" M500 is 4.65V and on the "bad" it is 5.1V maybe the lower voltage prevents the runt pulses from having an effect? Perhaps more modern TTL is fast enough to "see" them?

[daveejhitchins]

There are runt pulses on that 74138, but the other "good" M500 also has them and that somehow doesn't exhibit this problem. Although one thing I have noticed is the PSU voltage on the "good" M500 is 4.65V and on the "bad" it is 5.1V maybe the lower voltage prevents the runt pulses from having an effect? Perhaps more modern TTL is fast enough to "see" them?

Think I'd be wanting to try it out with 5V . . . Just to eliminate the low Voltage being the culprit. - Dave H.