A firmware update for the Oberheim Matrix6 and Matrix 6R Synthesizers
The slow response by the Matrix 6 to some MIDI parameter changes has been mentioned many times on the web. In the summer of 2014 I started a project to learn how the Matrix 6 code handles these updates, and how it works in general. This code is rather complex due to the number of features that it implements. Also, the structure of the voice update code was unlike anything I had seen before, and at first I had trouble making any sense of it. I sent an email to Marcus Ryle, who was kind enough to respond and give me some clues that helped me to understand the basic structure. It is this structure that lets the 6809 CPU handle so many different voice update features, but also makes handling parameter changes more difficult. After a few weeks of working evenings on understanding the code, I unexpectedly became the owner of a rather neglected Rhodes Chroma, the repair of which took up all of my spare time for the next six months or so. After that project ended, I decided not to pick up the Matrix 6 project again, as it seemed destined for failure. But then I started reading posts about Gligli's new version of the Matrix 1000 code, and how much the CPU choking had been reduced. So I decided to at least try to understand what he had done and see if it could be applied to the Matrix 6.
I started adding more and more comments to the code, and trying different things with a Verilog simulation of the M6R to see how the code worked. The simulator is a powerful tool and lets me examine any RAM location at any time, see when it changes, see where in the code it's accessed, etc. Below is a simulator waveforms screen shot. You can see the display contents changing as I press virtual switches, or send MIDI commands to it. The values in the Monitors section are the contents of RAM addresses that were being monitored for this specific test. This capture represents about 2.3 seconds of simulated operation, and took about 15 minutes to run.
Anyway, after a lot more evening and weekend sessions, I now have a new version of the code that handles many of the MIDI parameter updates a lot faster than V2.13 Some parameters are updated no faster than before. Here are the parameters that update faster:
1 DCO1 Freq by LFO1 amt
3 DCO1 Init PW
4 DCO1 PW by LFO2 amt
7 DCO1 Fixed Mods (not sped up in beta code that I sent out)
9 DCO1 Click
11 DCO2 Freq by LFO1 amt
13 DCO2 Init PW
14 DCO2 PW by LFO2 amt
17 DCO2 Fixed Mods (not sped up in beta code that I sent out)
19 DCO2 Click
21 VCF Init Freq
22 VCF Freq by Env 1 amt
23 VCF Freq by pressure amt
24 VCF Init Resonance
25 VCF Fixed Mods (not sped up in beta code that I sent out)
27 VCA 1 Init Amt
28 VCA 1 by Vel amt
30 VCF FM Init amt
31 VCF FM amt by Env 3 amt
32 VCF FM amt by Pressure amt
Some are much faster. Others may be just a little faster. The VCA and VCF updates are much faster. Some parameters update quickly with the original software, such as most of the envelope generator parameters. I did not touch them.
Note: If you are not familiar with the delays of the Oberheim Matrix software, and expect my version to have instant response to parameter changes, you will probably be disappointed. It's a lot better, in general, but of course with a 1980's CPU running at an instruction rate of 2 MHz, there will always be some delay. Actually, with any CPU there will always be some delay. It's just a question of how noticeable it is.
My changes do not discard or ignore any parameter updates. Rather the time to handle some of them has been reduced. I did not remove or disable any features of the Oberheim code.
There are two different issues related to MIDI parm updates. The first is how quickly the parms can be updated, i.e. is it possible to sweep the parameter and have the Matrix follow the sweep. The second is what happens to the 6809 CPU when we send it a sweep with lots of updates of the same parameter in a short time. When the MIDI buffer contains lots of commands, the Matrix code keeps processing them until it's empty. If the update command takes 50 mSec to process, and there are 50 of them in the buffer, the CPU stops responding to anything else for 2.5 seconds while it empties the buffer. This is very noticeable, of course. Here is a photo that compares two approaches to addressing the slow update problem.. The blue trace shows the voltage on pin 1 of a CEM chip (VCA2) in my Matrix 6R running the V2.14 code. The yellow trace is the same pin on a CEM chip in my Matrix 1000 running the V1.16 code. I generated a sweep of this parameter using a slider on my PC1600X, and fed the output into both synths at the same time using MIDI Thru on the Matrix 1000. (I don't have two Matrix 1000's, but for this test, the Matrix 6R should be equivalent.) The Matrix 1000 V1.16 code handles the parameters that take a long time to update (only certain ones) by waiting until the MIDI parameter update messages have stopped coming, then it applies the last one sent, so we see the voltage changing very quickly. This avoids the "CPU stall" caused by sending lots of MIDI parm changes to the Matrix 6 and 1000, but it doesn't actually sweep those parameters as the slider is being moved.
I have also implemented support for signed modulation amount MIDI parameter changes. This can be enabled or disabled using the Sysex Enable Master parameter, which now has four settings. 0 and 1 are the same as the V2.13 code. Settings 2 and 3 enable signed mod amt updates. Here is the difference:
Setting 2 does not adjust the parameter value, so 0-63 are positive values, and 64-127 become negative values, with 64 being the most negative and 127 being -1. So a slider that puts out 0-127 would have the positive part at the bottom, and the negative part at the top. If your controller puts out signed values, this is the one you should use.
Setting 3 adjusts the parameter value, so 0 is the most negative value, 63 is -1, and 127 is the most positive value. So a slider that puts out 0-127 would have the negative part at the bottom, and the positive part at the top, as you would expect. This is the setting that I use with my PC1600X.
MIDI parameter values are now checked against the valid range for that parameter. The original code did not do this.
I did not implement adjusting modulation matrix parameters using MIDI, as the EPROM is pretty full and there simply isn't room for that much new code.
When running on a Matrix 6 keyboard, my code should implement the same dead-band as the V2.13a code. The same EPROM image should be used in both the M6R and the M6.
I have provided copies of my code to many people. So far no bugs have been reported. I was very careful when making the edits to not affect normal operation of the Matrix 6. I have done limited testing of the code on both a Matrix 6R and a Matrix 6.
Here is an archive containing both V2.14 and V2.15 of the code. Someone recently discovered that version 2.14 did not support negative MIDI detune parameter values, so I created V2.15 firmware which does. If you want to purchase a programmed EPROM with this code, I am offering them for $30 each, including shipping to USA addresses.. I purchase the blank EPROM chips from ebay, so they are not brand new, as this part has not been made for many years. If you can find someone local to you that can program a 27C256 with V2.15, that may be an option, to avoid shipping and customs charges.
If you are closer to Germany than to the USA, and are interested in purchasing a programmed EPROM, please visit this site: http://www.untergeek.de/howto/oberheim-matrix-1000/
Note: No one other than Untergeek, Julien Voirin/Alpes Machines, and myself is authorized to sell this firmware. If anyone else tries to sell you a copy, please get it from us instead. Please DO NOT support people who are selling my (copyright-protected) code on ebay in various countries without my permission. I can't guarantee that they even have the correct EPROM image.
I am hoping that people who download and install this code and find it useful will consider making a small contribution to encourage me to tackle other projects. I have spent many hours working on this project. If people are willing to support my efforts, then I will keep the synth that I had to purchase for testing, in case I need to do more in the future, and will continue to support the code by answering emails, and making bug fixes as necessary.
Some people have made comments on the web about the CPU in the Matrix 1000 or 6 being the reason for the slow parameter changes. The 6809 is actually much more powerful than the Z80 used in the Prophet 5 and Six Track. The real reason for the slow response is more involved than simply the speed of the CPU and has to do with the overall architecture of the Matrix 6/1000 code, which was optimized for the voice update (real time) part at the expense of parameter changes. I don't think the designers expected the kind of MIDI update rates that people take for granted today.
Note: Please back up any patches in RAM that you care about before upgrading the code. They probably won't be affected, but this is still a good idea. If you are upgrading a Matrix 6 keyboard from an early version of the firmware, such as V1.05, rather than V2.13, you may need to perform an "initialization" after changing the EPROM to get the synthesizer to boot properly. Press and hold the red STORE button while powering up the keyboard to do this. Also, Tune and Calibrate afterwards.
Here is some information about how to remove and install EPROMs.
Here is some information for people who are curious about how the code works and why it can be slow to update parameters. It also contains some information on the process I used to make the changes.
Please note: Taking a Matrix 6/6R apart and replacing the EPROM must be done carefully, or damage to the synthesizer could result. It should only be attempted by someone familiar with this type of work. I will not be responsible for any damage to any instrument caused by either proper or improper use of the code offered here.
About that front panel "REMOTE" connector on the Matrix 6R...
The Oberheim Matrix 6 firmware does interrogate the remote connector to see if anything is connected. If it finds something, it generates a number of clock pulses (32 IIRC) which would be used by the remote device to shift its data out to the Matrix 6R. The data shifted in is OR'd with the data read from the switches on the front panel, and the result is processed normally. So the remote could activate the same switch functions that are present on the front panel. No display data was fed to the remote jack, so a remote device would not be able to show the M6R display contents. Probably Oberheim decided that MIDI would be a better way to control the device remotely, so they never offered a remote for sale. Just for fun, I programmed a PIC chip to read an encoder and send << ,< ,> ,>> key presses as the encoder is turned. Using this, I can adjust parameters up or down by turning a knob. But for some reason, the Matrix 6R code needs to receive the same remote data bits something like 5 times before it acts on them. This may have been to improve reliability or something, but it does slow down the operation of the remote. Also, the same delays exist for front panel/remote parameter changes as for MIDI parm updates. In fact the same code is used in both cases to implement the updates. So using a knob doesn't speed up anything.