A firmware update for the Oberheim Matrix 1000 Synthesizer
The slow response by the Matrix 6/1000 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 (V1.16) of the Matrix 1000 code, and how much CPU choking had been reduced. So I decided to at least try to understand what he had done and see if it could apply 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 had a new version of the Matrix 6 code that handles many of the MIDI parameter updates a lot faster than V2.13 Since I had already done this work for the Matrix 6, it seemed logical to take the time to apply these changes to the Matrix 1000 code as well. Some parm updates are 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
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 updates are much faster. Some of the VCF updates are much faster, some only a little faster (than V1.13/1.16) Some parameters update quickly with the original software, such as most of the envelope generator and LFO parameters. I did not touch these.
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 added Gligli's detune code to my firmware (with his permission), as this seems to be a popular addition. I also implemented a fix for NRPN parameter addressing that is equivalent to the one implemented by Gligli, but slightly different. In addition, I added code to fix the NRPN inc and dec functions, which I don't think would have worked as they were implemented. I have also added code to display parameter values as they are adjusted over MIDI, and the detune value as well. These will appear on the display until they are overwritten by the next normal code display update.
I have provided test copies of my code to several people. One suggested adding the parameter display feature (thanks!). I was very careful when making the edits to not affect normal operation of the Matrix 1000.
Here is an archive containing my latest code, which I am calling V1.20. It has not been exhaustively tested, but many people are using it and have not reported any problems. If you are interested in purchasing a programmed EPROM, I can supply them at $30 each, including S&H 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, that may be a better option, to avoid shipping and customs charges. Also, if I make any more changes (not expected) you can get them easily. The image here is the same one that I would use to program an EPROM.
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, 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 in my efforts. I have spent many hours working on this project. If people are willing to support my efforts, then I will keep the Matrix 1000 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.
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.
Also, in case you are tired of trying to decipher pin numbers and resistor values from the poor scan of the schematic that is on the web, here is a readable version of the Matrix 1000 schematic that I captured. I didn't bother with the power supply, as it's pretty simple and you can see what you need to see from the scan that's on the web. I moved some things around a little, as the size of symbols varies between schematic capture programs, and I didn't want to use a larger sheet size. If you spot any errors, please let me know and I will correct them. And after I captured those schematics, John Leimseider sent me a new scan of the original Oberheim Matrix 1000 schematics, which I have added to the archive, so now you have a choice of two readable schematics for the Matrix 1000.
Here is some information about how to remove and install EPROMs.
Please note: Taking a Matrix 1000 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.
Early Matrix 1000 issue with any new firmware
Someone whose M1K shipped with V1.03 firmware was having problems trying to use V1.11 or later firmware. It turns out that the circuit was modified very slightly at some point and this change is required to run any firmware released after that. If you look at the above-mentioned scans of the Oberheim schematics that John Leimseider provided, you can see mention of several ECOs. The one that seems to be critical for running the newer firmware is ECO 1207, which connected the PULSE output of comparator U4 to the CTS input of 68B50 U809. Before this ECO, pin 24 was tied to gnd, so that connection was removed. The M1K calibration firmware was changed to read the PULSE state using the ACIA chip's spare input, and will not run properly without this connection. ECO1207 also connected PULSE to the MUTE signal using a 1N4148 diode. This would tie the (open-collector) comparator output low during normal operation, since it's only needed for calibration. This change is not required to run the newer firmware, but is probably worth adding anyway.
Reassign rob key mode issue
I was recently contacted by someone who had discovered that the reassign rob key mode did not seem to be working. I was able to test this mode in simulation and confirmed that it seemed to behave the same as reassign mode. Further investigation revealed a small bug in the code which prevents reassign rob mode from working in every version of the firmware that I have looked at. Presumably not many people have tried to use this mode, or someone would have mentioned it to me before. Luckily, it's only necessary to change one byte in the code EPROM to enable reassign rob mode. The bytes in the area of the bug are 81 02 22 02. These are hexadecimal values. These bytes are located at the following offsets in the EPROM: V1.03 5003h, V1.11 536Bh, V1.13 536Bh, V1.16 536Bh, V1.20 5369h To fix the issue, you would change the second byte of the four to 03 instead of 02. So you would then have these hexadecimal bytes: 81 03 22 02. Make sure you see the correct pattern of bytes before making your edit. If you change the wrong byte in the EPROM, you will break the code.