21st-century rewrite of the Oberheim Matrix-1000 firmware. Sold with permission of the author, and including a royalty fee to him. Latest version: V1.20, 16-bit checksum: $21EC. Firmware chips available for €25 plus P&P (€2,50 within Germany, €5 for the world; if you live in the U.S. or Canada, please contact Bob Grieb/tauntek.com). Order form at the end of this document.
Installation instructions and documentation. Deutsche Version hier.
- 1 For people who know their way around electronics
- 2 Why you needed to buy a chip – and why you need to open the synth
- 3 Putting the new firmware into the old machine
- 4 What’s different?
- 5 Speeding up old hardware – how does it work?
- 6 GliGli’s V1.16 and Bob’s V1.20 – how they differ
- 7 Using NRPN
- 8 FAQ
- 9 Order Form
For people who know their way around electronics
- Backup memory banks 0xx and 1xx
- Insert firmware IC in socket U804
- Displays version number „120“ on switching device on
- See „What’s different“ notes for description of new features
- See „How it works“ section for description of new code functionality
Why you needed to buy a chip – and why you need to open the synth
The program running the Matrix-1000 synthesizer is called its firmware. On switching on, the Matrix-1000 shows the firmware version by displaying the three-digit version number. The last factory version was V1.11 – rumour has it that Oberheim lost the source code needed to develop the software, but it is just as likely that they lost interest in working on a machine that ran and sold well. The factory firmware contains a couple of bugs though – see the „What’s different?“ section of this documentation.
These days, whenever a machine like a router or a synthesizer needs an update, we are used to loading the software from the Internet and transferring it from our computer, just like writing data to an USB stick. This technology was not around when the Matrix-1000 was built. It is lacking the large, rewritable memory that you know from USB sticks and memory cards. Programs in these days used to reside in memory chips that were written in the factory – so the only way to update the machine is to open it up and replace this chip.
The new firmware is delivered in a chip called an EPROM – an acronym meaning „Electrically Programmable Read-Only Memory“. It holds 32KB of data – a millionth of what a 32GB memory stick stores these days. The data it holds has to be written with a special device called a PROMMER. And it can only be erased to be rewritten by hitting the microchip with high-powered ultra-violet rays (No need for you to do that.)
Putting the new firmware into the old machine
Tools needed: a cross-blade screwdriver to open the synthesizer and a small flat screwdriver or a knife to remove the old firmware chip.
It might be a good idea to start with backing up your sounds – i.e. do a bank dump of bank 0xx and 1xx, and record it into a MIDI sequencer. Replaying this MIDI file to your Matrix will restore your sounds in the very rare cases where the buffer battery is already weak and the synth’s memory gets corrupted when you touch the electronics.
Backup done? Then let’s start.
Disconnect the Matrix module from mains. Open It up by removing all the black screws on the side and the back, and then remove the black steel casing. The chip you need to replace sits in a socket named U804. It is in the lower right corner of the Matrix’s electronics board, to the left of the largest chip on the electronics board, the CPU. The firmware chip sits right next to it.
Wedge the blade of a small knife or screwdriver in between the chip and the socket. Rock it gently to loosen the chip and remove it. Take the new chip with V1.20 from the box. Make sure it is the right way round – there is a small notch on the IC which has to face upward, away from the synth’s front panel, just like the one next to it.
Be careful: It is quite easy to bend one of the pins by accident. Before using pressure to insert the new chip into the socket, make sure that all its pins are sitting correctly – it is best to insert one row of pins first and then bend them gently by putting some pressure on the opposite edge of the chip until the other row can be inserted into their holes. If one pin is bent and folded off rather than sitting in the socket, chances are that the synth won’t work – you will have to remove the chip, carefully straighten the bent pin and try again.
When the chip is sitting in its socket, connect the synth to mains and power it up. If the display shows the version number „120“ on switching on, you have succeeded. The old chip is no longer needed, but you may keep it in case you would want to restore the synth to its original condition.
The new firmware differs from the V1.11 factory firmware in these respects:
- It fixes the bugs concerning MIDI control of parameters 29 (ENV2 to VCA) and 53 (ENV1 Sustain) (introduced by Nordcore with V1.13)
- Unison detune can be controlled via MIDI CC #94. (introduced by GliGli with V1.16)
- While tweaking a parameter, the Matrix displays the value on its LED display
- Parameter can be controlled via MIDI NRPN, according to standard
- Fast control response: Smooth, musical control of the most-used parameters – the handling of 20 frequently-used parameters is speeded up to real-time. No stepping, no freezing.
Speeding up old hardware – how does it work?
In the Matrix, like in many MIDI-controlled analog synths, voice Modulation is done in software. Every 20ms, the synth recalculates the two LFOs, the three envelopes, the two ramps, and all the modulations via direct controls and via the name-giving modulation matrix, for all the six voices of the synth. The control voltages for the analog circuits are updated accordingly by the computer.
The problem is that this complex synth engine is keeping the old hardware quite busy – hardware that is running with a fraction of modern processing power. To be able to do it in time, the firmware works with pre-calculated tables. Every time a parameter is changed, these tables have to be adjusted. This takes time, so parameter changes tend to stack up and freeze the synth. You may think of the firmware as a very thorough office clerk processing your request – Form 24, VCF Resonance Adjustment Application – and while he is working, new requests stack up on his desk, while you are waiting. You know how that will make you feel.
GliGli’s V1.16 and Bob’s V1.20 – how they differ
I’ve described how the old hardware and software could not quite keep up with the Matrix‘ complex synth engine. You might know that the problem has been solved before.
In 2014, a French hacker called Gligli came up with a simple but elegant hack – it tells the clerk (i.e. the synth engine processing parameter changes) to take the top request form from his desk, and throw the others away. As turning a parameter control produces a lot more requests than you’d actually need, this is fine, although it may make parameter values jumpy. (The firmware with this hack is called V1.16, and is available for download on GliGli’s page.)
So how does Bob’s firmware differ? While 1.16 speeds up the M1000 by dropping parameter changes that cannot be processed, V1.20 speeds up handling of the most important parameters. (And it has that nifty feature where the value you are just playing is displayed on the LED.)
Getting back to the „clerk“ metaphor from above, the V1.20 firmware uses a different approach: it replaces the clerk with a trained specialist that can handle the most common requests a lot faster. They can be processed in real time and won’t block his desk. This is done with clever optimization of code that was written by very clever programmers in the first place, so you will realize that this was no small feat. More details can be found on the pages of the software’s author, Bob Grieb.
This allows for real-time manipulation of sound, beyond the limits of the modulation matrix. And there is no stepping – these parameters are now processed with the highest possible resolution of 20ms:
- 1 DCO1 Freq by LFO1 amt
- 3 DCO1 Init PW
- 4 DCO1 PW by LFO2 amt
- 7 DCO1 Fixed Mods
- 9 DCO1 Click
- 11 DCO2 Freq by LFO1 amt
- 13 DCO2 Init PW
- 14 DCO2 PW by LFO2 amt
- 17 DCO2 Fixed Mods
- 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
Other parameters might still lag, and changing the mod matrix will always take a moment for the synth to process – but this sounds worse than it actually is. The firmware allows for a very musical control of the sound – smooth real-time control will work just like you would expect it.
By the way: there are some software editors that circumvent the Matrix‘ limitations by implementing a version of Gligli’s trick – namely, only sending the last value of any parameter that you change. This means that you cannot use these programs for smooth real-time control of the Matrix’s parameters.
NRPNs (Non-Registered Parameter Number) are a MIDI standard to transmit parameter changes. In the original Matrix-1000 code, NRPN handling was in place but disabled by a bug. Gligli’s code activates it. Bob’s firmware fixes it. With the new firmware, you can use NRPN as an alternative to the system-specific SYSEX messages – SYStem EXclusive – that are meant for programming but not really for controlling. The advantages of using NRPN on the Matrix are:
- Real-time control of the Matrix with software and devices that don’t send SYSEX – as many DAWs and controllers like the Arturia Beatstep will only send NRPN messages.
- Other than the Matrix‘ SYSEX messages, NRPN messages are limited to one MIDI channel – when you have a couple of Matrixes in a MIDI chain you can make sure you are controlling only one of them.
- NRPN does not speed up anything – parameter changes via NRPN are handled just the way SYSEX commands are processed.
- NRPN does mean more rather than substantially less MIDI data – a SYSEX parameter control message is 7 bytes long, a full NRPN command takes 9 bytes – unless your DAW or controller sends only partial NPRN messages for updated values, which most controllers don’t do.
- NRPN will not enable finer control of Matrix parameters – although it is possible to transmit paramters with much higher resolution – 14bit, 16,384 values instead of the traditional 7bit, 128-step controls – the Matrix does not make any use of it.
This is what a NRPN message looks like for the Matrix-1000 – I’m assuming some basic familiarity with MIDI messages here:
- Send a MIDI CC message for controller #99. (Or 63h if you write the number in hexadecimal notation, like programmers do.) This is the upper part of the NRPN control number, the MSB. Both MSB and LSB together are telling the receiving device which of the 16,384 possibe NRPN controllers is used now.
- Then send any value as the parameter, e.g. 0. (Note: As the Matrix ignores it, you might just as well leave this CC#99, 0 sequence out. But most MIDI devices will not know this and send it anyway.)
- Send a MIDI CC message for controller #98. (Hex: 62h.) This is the lower part of the NRPN control number – the LSB.
- Send the # of the Matrix’s parameter as the CC value. For example, the VCF Cutoff parameter of the Matrixes has the number 21, so you send – exactly – 21 (or 15h in Hex).
- Send a MIDI CC message for controller #6. This is telling the receiving device that it is about to get the value of the NRPN control now.
- Send the new value of the Matrix‘ parameter plus 64. The synth will then set the parameter to the new value and display it on its LED display.
(Let’s add that strictly speaking, the NRPN standard calls for another sequence, CC #38 plus fine control of the transmitted value. This way, you can control parameters much finer than with the 127 steps of the normal CC standard. Modern synths may use this, but the Matrix doesn’t, and many controllers transmit either fine or coarse 127-step control but not both.)
Okay. But why do I have to add 64? The answer has to do with the way negative values are used on computers.
MIDI signals are transmitted in small packages called bytes. You may have heard from bytes, MIDI bytes are a bit different from „normal“ bytes on a computer, they have only 7 bits rather than 8, and can each hold a number between 0 and 127. To transmit negative values, they are re-interpreted following a convention named Two’s Complement. By this agreement,
- the value 0 means 0,
- values from 1 to 63 mean 1 to 63,
- 64 means the most negative value: -64,
- 65 means -63, 66 means -62, and so on,
- 127 means -1.
Unfortunately, NRPN is bad at negative values. So the Matrix programmers thought of a trick: shift the range of all parameters into an all-positive range by adding 64.
Let’s wrap this up with an example: Say you would like to control the amount of DCO1 PWM by LFO1, parameter 4, via NRPN. These are the MIDI control sequences:
- Max. neg. mod (-63): CC#99, 0, CC#98, 4, CC#6, 1.
- Min. neg. mod (-1): CC#99, 0, CC#98, 4, CC#6, 63.
- No mod (0): CC#99, 0, CC#98, 4, CC#6, 64.
- Min. pos. mod (+1): CC#99, 0, CC#98, 4, CC#6, 65.
- Max. pos. mod (+63): CC#99, 0, CC#98, 4, CC#6, 127.
There is one parameter where this would not work – VCF (Parameter 21) already has a value range of 0-127, so there is no need to add anything. Just send CC#99, 0, CC#98, 21, CC#6, VCF value.
To help you in programming your controller, I have prepared this PDF chart of all parameters and their ranges for SYSEX and NRPN control.
- I know that there is GliGli’s V1.16 EPROM that can be downloaded for free. What’s so different about this thing? – It takes a different approach in speeding up the Matrix – described above in the „How does this work?“ section – which guarantees for smoother sweeps, and, IMHO, allows for the most musical control of the speeded-up parameters. It really fixes NRPN. And V1.20 displays the value of a parameter while it is being edited. (And, by the way: let me tell you a secret. Bob does still offer free downloads as well on his site.)
- Is there a way to store the Unison Detune setting with a patch? – Unfortunately not. There is no room in patch memory for additional parameters.
- I’ve changed the EPROM but the synth does not work correctly. What went wrong? – Don’t panic. It is most likely a mechanical problem – maybe a pin was bent when inserting the chip into the U804 socket. Or you inserted it the wrong way round. Please check – and re-insert the original firmware chip. Of course, we may have sent you a defective chip – just send it back, we’ll send a new one, along with our apologies.
- Is my Matrix-1000 suited for this update? – Yes. Switch it on and have a look at the three-digit version number the synth shows on starting. There are some very old Matrix-1000 versions with firmware >V1.03 around which are using a slightly different way to store patches, so you might need a copy of the patch preset memory as well. In that case, please get in touch with me – in one case, even a small hardware modification was necessary (that Bob found out about).
- Do I need to backup my sounds before doing the upgrade? No. Carefully changing the firmware PROM in a switched-off Matrix does not affect its memory. Apart from that, the occasional bank dump is probably a good idea. Although the old buffer batteries seem to hold up rather well, but they will eventually fail. Good if you have a backup of your favourite sounds then.
- Why don’t you just insert a new CPU to make the old code run faster? – Good idea, and Gligli tried it. Unfortunately, there are a couple of problems involved. First, there is no modern pin-for-pin replacement for the Matrix’s old 6809 8-bit CPU – the only alternative is the 63B09 CPU that is just as ancient as the original processor and runs only at twice its speed. Second, the rest of the machine is not suited for communicating with faster processors. So although a more potent CPU is, in theory, feasible, e.g. with a 6809 processor core implemented in a Xilinx programmable logic chip, this would be a rather taxing engineering project. As would be rewriting the firmware for an Atmel or PIC microcontroller.
- I’d like to have this killer feature implemented in the firmware. Are you going to do it? – Most possibly not. There are so many more interesting old machines in need of repair and improvement, and the Matrix project is pretty much wrapped up. But you never know.
- Why are NRPN values interpreted with an offset? Why don’t they send the same values used in the SYSEX commands? – Because many MIDI controllers do not handle negative values correctly. The 64 ($40) offset is used to convert any parameter to a positive value range.
- I know for a fact that an EPROM chip costs about €3. Why do you charge me €25, you bastard? – Half of this money goes to the author of the firmware rewrite, Bob Grieb, as a recognition of the hours and hours he spent in analysing, understanding and improving the original code. The other half is for the chip, programming, packaging, handling and keeping this documentation, for eBay and paypal charges, and for the occasional beer/Apfelwein.
Firmware chips available for €25 plus shipping (€2,50 within Germany, €5 for international orders; for U.S. and NAFTA orders please contact Bob Grieb). Price includes V.A.T./MwSt. in Germany and EU, for non-EU destinations, additional taxes may be charged by customs. If you are a EU company, please send me your valid V.A.T. ID so I can prepare an invoice without VAT.
The chip is sold by Ingenieurbüro Günther Eggers, Tilsiter Strasse 2, D-75181 Pforzheim, Germany. Sold with permission of the author, and including a royalty fee to him.
Interested? Send me a shipping address, and I’ll send you an invoice via PayPal. After payment, the chip is sent within three working days.
The chips are sent as a Deutsche Post letter; this is the cheapest and fastest way. If you want insured shipping, let me know by selecting this option.
You may the return the chip within 2 weeks after getting it if you don’t like it. All I’d ask you is to bear the return shipping costs.