I doubt it's possible, the 800 ROM presets are saved in a very compressed format, very differently to the RAM patches. Earlier in this thread I mentioned that I had started decoding the ROM patch format, unfortunately I didn't get far as it's quite hard to decode and I couldn't spent a lot of time on it (and nobody else joined me in the effort to decode the ROM, despite I put the ROM image up for download so anyone could try).

My idea was to then make a (PC based) patch converter so that you can convert RAM patch banks into a custom ROM image that you can then burn onto an new (E)EPROM chip to replace the default ROM.
So you would have 800 custom ROM sounds (that you can change with some effort, i.e. by re-burning the (E)EPROM) in addition to the 200 RAM patches.

TBH I find 200 user patch locations are already a lot, many more modern synths have less than that, so a faster CPU is way more useful than more user patch memory.

That's very interesting, would you be able to share a schematic of your mod so that others could replicate it easily?

Did you try to contact him? He's some German guy who used to be on that German synth forum I linked to earlier in this thread, I'm not sure if he is still active on that forum.

I have two OB1000s - one black, one white. They sound the same to me as they alternate in slave mode. I'm also interested in what can be done to make these a little more responsive and robust with MIDI editing etc,

It got better I'd say, I don't have 113 so cutoff and some others are still quite slow, but e.g. DCO 1<>2 mix is super smooth.

That 20ms delay got reduced to 10ms with my changes, that's why it's better.

I can, but without the firmware changes, it's not really usefull as e.g. it makes all sounds play too fast.

I'll try to send him a private message on the german formum, see if he answers.

That's understood but there might be others here who would like to give the firmware hacking a go and for that they need to build the hardware mod first to be able to test their firmware hacks.

I have PM'ed him now (it's user 'nordcore' on sequencer.de) and brought this thread and your posts to his attention. Let's hope he gets back to us or posts in this thread directly.

Ok cool, I'll make a wiring diagram in the mean time.

Edit: here it is: http://sfx.gligli.free.fr/zik/m1k/m1k-wiring.pdf quick & dirty but hopefully easy to follow

yea definitely. My main point about the forced latency is that I believe if the sysex transmission abides the speed limit, then the machine should not lock up at all. I am making this assumption based on midiquest being "smooth" and also the controls on the Matrix not causing that issue, even if the left or right arrow are held for continuous modulation. (I am on a 6R myself .. but for all intents and purposes, everything should apply virtually equally).

I ran into a snag yesterday while commencing my work on the maxforlive device. I knew that Live didn't implement sysex, but I didn't know that they implemented completely truncating any sysex a vst or m4l device may generate.

If I could get a simple OSC -> MIDI converter for Windows, then I could bypass Live's shortcoming, so far it seems only the Mac world has these types of utilities though!!! I'll find a way though

Anyway .. I literally got my 6R the day you posted your CPU hack. I *love* the way this thing sounds, and I would love to join you and tux99 in breathing some new life into this thing

If anybody else wants to have the disassembly: ask. Don't expect to much, its barely what was needed to fix the bugs, and comments are in German.
There are parts of the engine, where I'm sure to have messed up the code/data setting, so there is a lot of work left to get a proper disassembly (=one which assembles back to working code, even after you change something). The engine is a lot more advanced code than the rest of the thing. (I suspect the engine was taken from the Matrix 12, and that was made when Oberheim had better days, so the programmer had the time to do some decent work... ) .

The EPROM bugfix is only for the Matrix 1000. The Matrix 6/6r have some different hardware for the timers and clock generation and the patch storage section is different, so the program is completely different, at least from a disassembly/patch view.

Sys-Ex control of the patch values is intended for patch editing, not for real time edit during playing. Direct VCF control with the sys-ex during play is abuse, if you need it in a patch/track, put it in the matrix. That is why the matrix is there! You'll get well scaled behavior on a reachable controller.

The Sys-Ex commands trigger one of a handful update routines, which recalculate the matrix-engine. Especially the "update all" subroutine is pretty slow (and that is what I have taken out of the VCF sysex to speed it up).

Midi input is read in a relative short queue (done in one interrupt). The engine timer interrupt (the other interrupt in the system, AFAIR(!) 60Hz), which does all the work, reads the midi data and updates the engine state.
So it is pretty easy to overrun the engine - and relative easy to avoid overrun: just don't send sysex to fast. (The matrix 2001 editor does that pretty well... )

A faster CPU would just be that: faster on crunching trough the midi data, so it could handle more midi data w/o getting stuck. To have, for example, faster envelopes, the timer must be set different. But than you have to modifiy the timing of the whole engine.

If everything speeds up with more CPU-Clock, the timers get a doubled up clock. (And the bus timing is halved, which might (not must!) lead to problems. If you get such problems: try to get CMOS chips for timer, B Version for UART, in general newer chips will be faster than specified ... )

The DCO timers must keep their original clock frequency, as they are only 16bit. (2MHz E-Clock/65536=30Hz =lowest pitch the Matrix 1000 can do, 60Hz would be a little too high. )

Nordcore>
Hello, thanks for joining!

Actually, I doubled the CPU clock, but added a frequency divider for E, so it's still at the original frequency, it's mandatory to get proper MIDI baud rate, DCO frequency and so on.

There's something I don't quite get, I red in a lot of places and you said it again that the internal engine is clocked at 60Hz from IRQ. The thing is, I don't see any signal on that line besides a few pulses while playing the voices. Also it's supposed to still be 60Hz with my mod, but the whole synth runs twice faster (envelopes, LFOs,...).

Looks like the thesis with the timer for the engine is wrong.
Timer 2 in one of the 82C54, clocked by E, generates IRQ.
I'm not that sure, as it is some time ago, but I always thought I had that (before repair: missing) timer pulse on the scope of an Matrix 6R where the timer chip was broken.
(In the 6R there is a different chip for that function - but it should be the same function. BTW: You could even find some M6 code parts for the display left behind in the Matrix 1000 code... )

Ok, I just put the 6809 and the original crystal back, and I get that 60hz pulse, there must be something wrong with my mod...

That is strange. If the IRQ is missing, I would expect that the synth looks like dead. (As sound and display both are done in that interrupt. )
(At least that was the behavior of the 6R with the broken timer chip. )

Okay, progress!

I made myself a sort of devkit by replacing the firmware rom by a ram chip and a microcontroller to update it, the wiring is really ugly but it works fine so far.
I found out why the 50Hz IRQ clock wasn't there, I'm clocking the timer chips at 2Mhz but the registers are accessed at twice that speed by the CPU, so some register writes were not properly done, I fixed that by doing all timer register writes twice in the firmware.

By clocking the IRQ at 400hz, but doing the sound engine update only 1 in 8 times, I think I fixed the slow MIDI parameters update while keeping the right overall timing, some parameters are still quite slow (filter env amout, vca level, ...) but they probably need the same kind of changes made to cutoff in 113.

I attached a quick demo of me tweaking the sound thru midi sysex.

(After I get a couple of M1000s, naturally )

@nordcore, thank you for joining this discussion!

@gligli, sounds great! you have essentially cracked it. Now it appears that the firmware on the 6/6R is still quite different than the 1k. I have *zero* experience with eprom assembly, but I'm familiar with C coding, so I think if I read up on it, I might gain a bit of understanding. Can you point me (and anyone else) to some reading material to familiarize myself with this process. If I can create a similar devkit here to work on the old buddy, I'd like to help.

Sounds great gligli, that's what I would call a productive sunday, you work really fast!!



You will have to pay someone local to you to socket the cpu in your M1000 (I very much doubt gligli has any intention to do that for others).
The rest seems straightforward once gligli makes the updated firmware image available.

I'm not sure I understand the above correctly. Is the above purely a firmware mod or did you change the hardware wiring compared to your pdf schematic for this?

If the above is purely firmware changes then wouldn't it be possible to do that with the stock cpu too (200hz and 1 in 4 times respectively), wouldn't that already provide a great improvement without any hardware mod?

I'll be down to buy at least two of whatever comes out of this thread. I seem to buy another M6 or M1000 for peanuts every year or two.

Sure, I have some friends who could do that for $0 even.

The "double register write" is a workaround, at least I would not rely on getting the registers written on the next try.
One could clock down the CPU on such access to slow peripherals. (Would require some (simple) programmable logic chip. Switching Clock should not be a problem for the CPU, as long as it is synchronous = glitch free. )

That would not help much, as the slow sys-ex is a result of the CPU taking too long to process the midi data.

The CPU is barely capable of handling the matrix engine during musical use. What some expect here is to use a patch change in musical context - that would require a complete different firmware concept. The current firmware is made to have a fast part (using the matrix) and a slow part (changing the patch).


Another trick to get rid of the "stuck" midi might be a slight rearrangement of how the update works:
Now, a midi command is taken, the parameter value is updated in the patch storage, than the associated update subroutine is called.
There you might just set a flag for the required update. Than look if there is another midi byte pending. Process that midi byte first. Until the queue is empty, *now* clean out the doubles (an "update all" might cancel an "update some part") and process that.

It's a firmware mod, but I think it needs the faster CPU, as it has to do 8 times as many MIDI updates. I don't think there's any CPU time left with the stock one!

Still, it's just a first step, the new CPU can also handle 2 times faster synth engine updates, I just need to find how to change all the time-based parameters (envelopes, LFOs, portamento) to keep the right timing.

This is f*cking awesome!

Just out of curiosity; how does the envelopes sound currently? Double the speed, or glitchy?

Yes it's not a clean solution, but it seems reliable, and it keeps the hardware mod simple. Plus the CPU generates its own clock and the master clock directly from the crystal, so it won't definitely be a simple mod.
That's a really good idea! I think even just a bit flag that's set each time any kind of update is required, and then one "update all" call before the sound engine update in case the bit is set would be simple and work nicely.

They work as usual except the lowest and highest env times are both twice faster.
I had glitches with the faster LFOs tho, I'll have to check that again now that I worked around those timer update problems.

Hi,
I tried some flavor of Nordcore's idea for slower midi parameters (filter env amt, vca level, ...), that is delay the full synth update until MIDI queue is processed instead of once per message. I had to fiddle with it a bit but it now works nicely. Those params are still a bit steppy when you change their value too fast, but it can't be compared with the >1s delays they created before!

I think there's still a problem with negative amounts to get MIDI fully usable, but this is probably not a hard fix.

Keep it going, mate!

I'm working on getting a midi sysex parser together for Ableton Live. Once this is complete, the MaxForLive device comes next for parameter control. Based on Nordcore's information, I think my original suspicions were mostly wrong. Never-the-less, if it's necessary to implement some breaks to keep the parameters changing within a certain amount of milliseconds, it can definitely be done.

But an elephant in the room remains - what about the M6/6R OS? Nordcore also mentioned enough things work differently that the changes cannot be made the same on the 1000 vs the 6. I'm truly kind of lost when it comes to disassembling and reassembling an OS like this, but once I get the Max project done, I will try to find some reference material to get some knowledge on the subject. Still open to suggestions if anyone has them

Nice.