Fixed a 30 year old Roland synthesizer bug

In 2005, MT-32 music enthusiasts reported a difference in the LFO rate of Roland's third-generation Linear Arithmetic Synthesis implementation affecting both the CM-500 and CM-32LN modules , as well as the LAPC-N C-Bus boards. This wandering behavior noticeably manifests itself in a faster vibrato rate than that produced by the first and second generation LA products.

Comparison 1:

CM-32L (MUNT) - 356 KB FLAC CM-500 - FLAC 570 KB

Comparison #2:

CM-32L - 821 KB FLAC CM-500 - 795 KB FLAC

Comparison #3:

CM-32L - 1.35 MB FLAC CM-500 - 1.33 MB FLAC

These findings were brought to the attention of Roland Japan, who acknowledged the behavior as unintentional, but were unwilling/unable to investigate it further, as the ten-year support cycles of the affected products had passed.

Unfortunately, but rightly so, the resulting incorrect playback of the CM-500 and CM-32LN modules has made them somewhat undesirable among enthusiasts, despite the former's appeal by combining the CM-32L and CM-32L sound sources SC-55 in a single device, and its battery power functionality.

Over 15 years later, there is now a solution.

In 2020, the LFO discussion was revived thanks to the efforts and advice of Sergey Mikayev, or "sergm", of MUNT fame. Although an initial analysis was inconclusive, Sergey then focused on the notable MCU change introduced in the third-generation LA architecture - from the 8098 to the 80C198 - and soon discovered the probable cause in a publication. Intel outlining MCU upgrade considerations [1].

The following passage is relevant (where 8096/80C196 = 8098/80C198):

Intel Corporation wrote:

First, some information about the 80C196 is needed. The opcode set is a true superset of the 8096, but some improvements have been made to peripherals and timings. The crystal is divided by 2 on the 80C196, instead of 3, as on the 8096. This means that the 80C196 running at 8 MHz will have a state time of 250 ns, just like an 8096 running at 12 MHz.

Sergey explained that several linear arithmetic synthesis operations, including the software timers used to implement LFO rate, depend on state time. Since the use of a 12 MHz crystal oscillator has been maintained in the third generation LA architecture, Roland engineers may have simply not considered the reduction in state time (if it was even known) when they adapted the 8098 code for use with the 80C198. The consequence, of course, is unwanted, "faster" behavior.

In theory this should be fixable in software, but where there are still unknowns regarding some of the timer dependencies, the easiest solution seems to be Intel's suggestion to just run the MCU at 8 MHz to achieve the expected state time of 250 ns.

The 12 MHz -> 8 MHz crystal change was originally tested on a CM-32LN unit in mid-2021, where it quickly became apparent that MIDI communication was then interrupted. As further explained in the Intel documentation, changing the MCU clock also requires changing the serial baud rate divider, which in this application is used for MIDI I/O. Sergey identified this byte location [2], along with two additional software timer values ​​that needed modification, and a custom ROM binary was then written and swapped into the CM-32LN. This proved to be successful and behaved correctly, and a CM-500 unit was modified in the same way afterwards.

Specific changes to the v1.00 CM-32LN Control ROM (also used by the CM-500 and LAPC-N) are as follows:

10x1A8D: 1D5Fh -> 1388h20x215C: 17h -> 0Fh3

Fixed a 30 year old Roland synthesizer bug

In 2005, MT-32 music enthusiasts reported a difference in the LFO rate of Roland's third-generation Linear Arithmetic Synthesis implementation affecting both the CM-500 and CM-32LN modules , as well as the LAPC-N C-Bus boards. This wandering behavior noticeably manifests itself in a faster vibrato rate than that produced by the first and second generation LA products.

Comparison 1:

CM-32L (MUNT) - 356 KB FLAC CM-500 - FLAC 570 KB

Comparison #2:

CM-32L - 821 KB FLAC CM-500 - 795 KB FLAC

Comparison #3:

CM-32L - 1.35 MB FLAC CM-500 - 1.33 MB FLAC

These findings were brought to the attention of Roland Japan, who acknowledged the behavior as unintentional, but were unwilling/unable to investigate it further, as the ten-year support cycles of the affected products had passed.

Unfortunately, but rightly so, the resulting incorrect playback of the CM-500 and CM-32LN modules has made them somewhat undesirable among enthusiasts, despite the former's appeal by combining the CM-32L and CM-32L sound sources SC-55 in a single device, and its battery power functionality.

Over 15 years later, there is now a solution.

In 2020, the LFO discussion was revived thanks to the efforts and advice of Sergey Mikayev, or "sergm", of MUNT fame. Although an initial analysis was inconclusive, Sergey then focused on the notable MCU change introduced in the third-generation LA architecture - from the 8098 to the 80C198 - and soon discovered the probable cause in a publication. Intel outlining MCU upgrade considerations [1].

The following passage is relevant (where 8096/80C196 = 8098/80C198):

Intel Corporation wrote:

First, some information about the 80C196 is needed. The opcode set is a true superset of the 8096, but some improvements have been made to peripherals and timings. The crystal is divided by 2 on the 80C196, instead of 3, as on the 8096. This means that the 80C196 running at 8 MHz will have a state time of 250 ns, just like an 8096 running at 12 MHz.

Sergey explained that several linear arithmetic synthesis operations, including the software timers used to implement LFO rate, depend on state time. Since the use of a 12 MHz crystal oscillator has been maintained in the third generation LA architecture, Roland engineers may have simply not considered the reduction in state time (if it was even known) when they adapted the 8098 code for use with the 80C198. The consequence, of course, is unwanted, "faster" behavior.

In theory this should be fixable in software, but where there are still unknowns regarding some of the timer dependencies, the easiest solution seems to be Intel's suggestion to just run the MCU at 8 MHz to achieve the expected state time of 250 ns.

The 12 MHz -> 8 MHz crystal change was originally tested on a CM-32LN unit in mid-2021, where it quickly became apparent that MIDI communication was then interrupted. As further explained in the Intel documentation, changing the MCU clock also requires changing the serial baud rate divider, which in this application is used for MIDI I/O. Sergey identified this byte location [2], along with two additional software timer values ​​that needed modification, and a custom ROM binary was then written and swapped into the CM-32LN. This proved to be successful and behaved correctly, and a CM-500 unit was modified in the same way afterwards.

Specific changes to the v1.00 CM-32LN Control ROM (also used by the CM-500 and LAPC-N) are as follows:

10x1A8D: 1D5Fh -> 1388h20x215C: 17h -> 0Fh3

What's Your Reaction?

like

dislike

love

funny

angry

sad

wow