---In oberheim@yahoogroups.com, <bobgrieb@...> wrote :

Even a mod that uses the stock firmware with a replacement CPU, would not be identical to the original. If the point is to be identical, then why make any mods at all The point isn't to make a new synth but to improve the current synth by fixing bugs and adding features. Even if you were to look at it as a "new synth", a good reason why would be that no one is making an affordable, pure analog,  polyphonic  synth. Especially not one that fits in a 1U. 

My statement about not being completely backwards compatible to the original was in regards to patches. I think this is an issue with any upgrade. Even a fully stock firmware with a CPU replacement has potential to have differences because the timers or analog outputs may not be identical with a new chip no matter how closely you model at. And what then, as soon as you make additions to the firmware you essentially are creating a new synth. The general tone of which will still be that of the M6 line since it's using the same analog voice path.

I believe the way to go is a ground up rewrite of the feature set of the M6 in C. Even better if there's one that's a CPU socket compatible replacement like p600fw had with Teensy++ 2.0 into the Z80 socket.

 It will be easier to improve upon, which is whole point of a modding project in the first place. Kiwi technics and the p600fw project have proved this to be a viable path and have made great success with single a single developer. Writing a firmware in C opens up the option of having many collaborators. If you go the route of hacking features into the original firmware using hardware sims, you limit the pool to a very small number of people who know that kind of tech.

 

Reverse engineering and understanding the original firmware is important to understand how the LFOs, envelopes and cross modulation of such work per cycle. I would assume the project would want to improve the bit depth of those parameters as well, as a big request of the M6 series is to add smooth filter sweeps, which would benefit greatly from a 24bit midi implementation, but aliased to the original filter stepping. For LFO and Envelope you could have an original clock synced version and then add snappier envelopes for better percussion options. Once you have a good C platform for that it's easy to add many different shapes to both. Having to do that by injecting mods into the binary blob wold be a big undertaking for any new addition which would have to include regression testing to make sure it doesn't interfere with any of the original code in some unforeseen way.

My point is, no matter what, it's not going to be original, in the sense that original patch dumps might have slight tonal differences, so why shoot for perfection. The point isn't to restore it like it's a rusting vintage car, but to make a hot rod out of an old engine and chassis, for less than a new sportscar.