New code, explanations, schematics – Understanding the Matrix

Part of the new M-1000 schematic

Enter the Matrix – finally the R/W decoder is legible.

Looking to get the latest revision of Bob Grieb’s firmware rewrite mentioned below? Click here. 

As you may have seen in this blog, I really care about my old Matrix-1000 rack synths. A wonderful piece of retro technology from the final, post-DX7 phase of classic analog synthesizers. There have been attempts to improve on the old 6809 firmware code, most notably by Gligli, a French hacker best known for his SCI Prophet 600 hardware/firmware retrofit. His improved firmware, known as V1.16, introduced a couple of tricks:

  • It enabled NPRN control of the Matrix‘ parameters by removing a small bug
  • It sped up the VCF parameter control by skipping seemingly unnecessary calculations
  • It told the synth to discard all parameter edits except the most recent one, thereby keeping the synth responsive.

This is a huge improvement and makes the Matrix feel and behave almost like a modern instrument. But it gets even better.

Matrix-6 project, Matrix-1000 upgrade

Bob Grieb has been analyzing the Matrix-6/1000 code for months. I guess you can say that these days, not even Marcus Ryle does understand the code as well as Bob does. Here is his explanation why the Matrix-6/1000 machines are not real-time responsive to parameter changes in the first place – it is the downside for the immense amont of real-time modulations the Matrix is capable of – 22 fixed modulation paths, 10 matrix modulation slots, 3 envelopes, 2 LFOs and 2 ramps. To implement that in software the programmers used a special technique; a pre-calculated memory area for each voice called the voice update stack. Quote:

This stack contains pointers to code, ptrs to variables, and some pre-computed values. Only pointers to the code needed to handle the enabled features are placed on the stack… This is a very fast and efficient way to update the voice cv’s.
A downside of this approach is that when parameters change, the stacks need to be updated for all six voices. Some parameter changes just affect one number on the stack, so that number can simply be changed very quickly. But some parameters can change the size of the stack. This is a problem, as the update values for that parameter may be in the middle of the stack.

This means moving around chunks of memory to make room for the updated parameters, and it has to be done for all six voices, which takes the ancient 8-bit, 2-MHz CPU a couple of milliseconds. When you turn an external VCF controller, all these parameter changes add up, and the machine freezes for a long, terrible moment, until it catches up. (Read Bob’s full description of the issue here.)

GliGli’s main trick is to tell the machine to discard anything but the last Sysex command. He also noticed that sometimes the stack is rebuilt although this is not technically necessary. And this is the road that Bob has been following. He rewrote parts of the firmware to handle a set of about a third of the parameters much, much faster – including VCF frequency and resonance, DCO PW and LFO control, and VCA level. Changing these parameters with an external controller will be smoother than with older firmware, others – increasing the effect of a modulator in the mod matrix – will still cause the machine to glitch.

Update, 2016: Now that you’ve made it this far, you’ll be glad to learn that Bob made his revised code available for Matrix-1000s and Matrix 6/Rs. You can get a firmware EPROM from him or, if you are in Europe, from me – just follow the links above. 

This was originally a project for the Matrix-6, but Bob ported it over to the Matrix-1000. In the process, he also redrew the schematics, so that after all these years, there is finally a legible circuit diagram for the M-1000 on the net. Incidentally, it prompted another guy to scan his printed schematic and send it to Bob, so that there are now not only one usable version but two. (Download link to ZIP archive here.)

Verwandte Artikel:

13 Gedanken zu „New code, explanations, schematics – Understanding the Matrix

  1. Hi, I am trying to make a Ctrlr panel for the matrix1000. I have two things I don’t understand on the sysex dump: Checksum, how is it calculated? What are all the bytes for in the global-parameters dump called Group Enables (One bit per patch, LS bit first) / byte 36-161? If you know the answer I would be glad if you could post it here. Thanks

  2. yes there is already a Ctrlr panel but it is a „forever beta“ version. I would like to enhance it to cover all features of the Matrix1000. I used group mode too on my two matrixes, but the lag is quite important, so not extremely useful. Thanks for your (very fast) answer, but sorry I don’t get how you can make a sum out of many 6bit/7bit etc. values and cram them into one 7 bit value? Sorry if this is trivial. I know a „bit“ or two about binary notation but never had to calc a checksum.

    • I googled about checksum addition, this is a Roland checksum but it must be something similar. I think I will find out by trial & error: Add each of the values, one by one. Each time the value exceeds 127 (7Fh) subtract 128 (80h) from it. Finally subtract the resultant value from 128 and you have your checksum!

      Thanks for letting me know about the group mode. I didn’t think that it must be set for each patch.

  3. Hi unty, my Ctrlr panel is almost finished. It features a librarian, full recall of parameters and a randomizer. It is a joy to use it with rom v1.20 (will definitely pay these 10$). But now I got a „problem“ – though not sure if this is a feature: Is it normal that the M1k in unison mode makes a pitch rise on key release? It seems to be an even 12 halftone step… It sounds cool but I could find no way to change it (e.g. get rid of it). Thanks.

  4. I think it will just take a few days until I will release v1.0beta. I would be glad if you could betatest it. These days it is hard to find willing betatesters :) Thought I still have one big prob: when in group mode the M1k will send garbled data between sysex messages (starting with F0, sending a bunch of bytes and then starting the correct message with F0, so no F7 on garbled bytes). This confuses Ctrlr and it can’t receive the messages correctly. I’m afraid I won’t be able to fix this. What do you think, would Bob Grieb be willing to fix this in the firmware? Maybe I should ask him.

    • I haven’t tested group mode for some time (I gave up on the group mode and worked on other parts). I did test it again now and it seems to work! It just bothers me that the builtin midi-monitor of Ctrlr does not display it correctly. It looks like it looses half of the dump but this may be just the midi-monitor displaying it wrong. It is a fact that the M1k sends garbage when in group mode. I did test this with several midi-monitors that are showing the dumps correctly including the garbage in-between. Well, I will have to test this some more. Maybe I am lucky and it really works. There is no control in any way for midi-input behavior of Ctrlr. You just have to rely on it doing it right.

      Btw. are you using group mode (having 2 or more M1k’s)? What pc system do you work on (Mac, Win, Linux)?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.