The Roland CM-500 is a digital synthesizer sound module released in 1991 that combines two incredibly powerful engines into one unit. However, in 2005 enthusiasts of the Roland MT-25 (one of the engines that went into the CM-500) noticed a difference between the vibrato rate on the MT-25 and the CM-500, rendering it less useful as now midi files would need to be adjusted before they sounded correct. Now thirty-something years later, there is a fix through the efforts of [Sergey Mikayev] and a fantastic writeup by [Cloudschatze].
They reached out to Roland Japan, who decided that since the device’s lifecycle had ended, no investigation was warranted. That led the community to start comparing the differences between the two systems. One noticeable difference was the change from an Intel 8098 to an 80C198. In theory, the latter is a superset of the former, but there are a few differences. First, the crystal frequency is divided by three rather than two, which means the period of the LFO would change even if the crystal stayed the same. Changing the 12 MHz crystal out for 8 MHz gave the LFO the correct period, but it broke the timings on the MIDI connection. However, this is just setting the serial baud rate divisor, which requires changing a few bytes.
Replace the ROM chip with a socket so you can slot your newly flashed PDIP-28 64kx8 ROM into a quick desoldering. Then swap the crystal, and you’ll have a machine that matches the MT-25 perfectly. The forum post has comparison audio files for your enjoyment. Finally, if you’re curious about other fixes requiring an inspiring amount of effort and dedication, here’s a game installer that was brought back from the dead by a determined hacker.
*MT-32
Thumb up, nice proper hack which is about fixing something that needed it rather than “because I can”.
I imagine that this wasn’t good for Roland’s business as people returned their product when it would have been trivial for them to fix.
From the writeup, it took 14 years for anybody to actually notice there was a problem — which is not exactly a surprise, as nobody back in the day was doing side-by-side comparisons of vibrato rates. If there had been complaints while the CM-500 was a going concern, it would almost certainly have had a manufacturer fix, but there just weren’t. Nobody was returning their devices over this, because the only people who knew about the discrepancy had bought them at least a decade ago.
Which is not to say this is not an awesome hack. It’s great! But the fix being applied in this manner is for a bug that caused a slight-to-moderate audio difference in the output of a given MIDI file or sequence between when it played through the CM-500 and through the MT-25, and that difference only under certain circumstances. It’s hard to fault Roland for not putting their research/repair effort into a long-discontinued product.
While this was a bug caught by users and brought to the manufacturer’s attention after the product was deemed end-of-life, it should have been caught by the manufacturer with good regression testing. Even something like HP’s old signature analysis could have caught this by sampling the output data streams for a “good” test set. If they did regression testing, then their test suite was deficient of the problematic midi (I did not read the referenced article, so my perspective is from the viewpoint of basic tenants of testing, and I don’t “know” MIDI).
I have done a lot of development with the 80C196C, with a dynamic 8/16 data buss, among other differences. That series was originally designed for automotive use, but obviously was used for other products (I used it for avionics). I initially evaluated this processor back in 1987 when it first came out. I was trying to use the timers to generate an external, 12 bit ADC sample clock, but ran into problems. It seems that their “improved” (over the 8096) timer operation had a “bug” (I never used any older parts). The BIG problem was that its output verified with a frequency counter, yet the resultant FFT of the sampled data had a high noise level and was “smeared”. I was new to the FFT so I didn’t fully understand some of its quirks. During the time I was struggling with this problem, I had a scope hooked up to the sample clock and out of the corner of my eye I could see that it lost sync sometimes. I changed scopes and it was still there. When I expanded the trace timebase to include more and more samples, I could see the problem: at the sample rate I used for the crystal I used, the processor was dithering the timing to meet the programmed timing ON AVERAGE. I reported this to the Intel reps and two weeks later they verified, “yah, that’s the way it works, but we didn’t know that until you pointed it out” (dah). They weren’t going to fix it “in time” for my project, so we retooled the ADC sample clock into an EPLD we had onboard and I continued development after a two week+ detour.
I think you’re missing the point. The new chip didn’t sound ‘wrong’ or ‘bad’, just a tad different in specific circumstances. So even with regresson testing this wouldn’t have been noticed. Only when you would do it simultaniously with the old and the new chip and listened to both outputs at the same time (comparing them).
It’s not for nothing that it took 14 years to discover this difference (rather then fault).
Maybe you missed my point about the reference to HP’s digital signature analysis that uses a baseline “signature” to compare against the UUT (i.e. the new one) so see if anything changed (see https://hpmemoryproject.org/an/pdf/an_222.pdf). And, my impression was that it was a timing thing (old processor was xtal/3 and new was xtal/2 using same xtal and if that wasn’t compensated for in the code to change the processor settings, the timing of the output is off, which is what I understood to be the issue).
Roland never made a MT-25; it was the MT-32.
Xactly
Roland is a joke and their products are full of bugs, that they don’t fix. Not even recent products like the rc500.
“Replace the ROM chip with a socket so you can slot your newly flashed PDIP-28 64kx8 ROM into a quick desoldering.” – Isn’t a few words missing here?
Gary numan used Roland synth on his fury and other mid 80s albumns not as good s sound ad the moon’s the Roland sound was a bit too polished and machine like for me john foxx still uses analogue synth to give more organic sound
Instructions unclear; now being pegged by a big cock woman. Send help.