OBERHEIM SYNTH group photo

Yahoo Groups archive

OBERHEIM SYNTH

Index last updated: 2026-04-28 23:39 UTC

Message

Re: [oberheim] Re: Dream on, geek: The Überh eim Matrix-1000 Project

2014-07-23 by Bob Grieb

I could be wrong about the use of a compiler.   Saw some strange things, like a branch
to the next instruction, that I never thought a human would do, but I guess it could have
been overlooked.  Also, some branches to rts instructions.  If this code was written in 
assembly, then the people who wrote it are very clever indeed!  Messing with the stack 
in the MIDI code.  Very scary.   
 
Love the story about dropping the code disk.  No backup?   Hard to imagine, even back
then.  I guess those disk paks were expensive for the PDP-8 or 11.
 
Have you done much AVR assy coding?  I have done lots of PIC assy, but no AVR.
 
I did see a bunch of places in the code where they used a little loop to create a delay
when talking to the hw.   It wouldn't be that hard to find those and change them.
The simulator is good at things like that.  In the calibration code, they are using the 
timers in the VIA chip, not code loops.  But making an FPGA with a 50 MHz 6809,
which would need its own local Flash for code and also fast SRAM seems like a lot
of work, and for sure would be SMT, which means most people couldn't build it
themselves, as opposed to using a Teensy which makes it a pure sw project.
 
Also, based on what I have heard about some of the delays in the current code, even 
a 6809 that was 25 times as fast might not really solve the problem.  Seems like the 
structure of the code needs to change as far as how MIDI updates are handled.
 
Bob
 

________________________________
 From: "analog gear margus.kliimask@... [oberheim]" <oberheim@yahoogroups.com>
To: oberheim@yahoogroups.com 
Sent: Wednesday, July 23, 2014 9:49 AM
Subject: Re: [oberheim] Re: Dream on, geek: The Überh eim Matrix-1000 Project
  





Hi,



On Wed, Jul 23, 2014 at 3:24 PM, Bob Grieb bobgrieb@... [oberheim] <oberheim@yahoogroups.com> wrote:

 
>  
>    I have started comparing code between the 6 and the 1000.   Found some routines
>
>that are exactly the same.  Probably lots of the code was ported over, with changes 
>
>to the patch storage format, and for the oscillator frequency difference. 
>
>
>    Looks like the code for these units was NOT written in assembly.  I am guessing 
>
>a C compiler was used.  (The Six Trak, Max, and Multi-trak, on the other hand, were coded 
>
>in Z80 assy)   I wonder if the C code is still around.   The names of the programmers
>are in the code.  Maybe one of them still has a copy?  Having the source code would
>make this a much simpler project.    
>
>
> 

If this code came from a C compiler I would really love to get my hands on this one. The core part of the code (signal generation) is very tight and highly optimized, not a single C compiler I've been playing with (eg. for AVR family) generates that good code. Besides, different parts of the code have quite different style and are obviously written by different people. 

I tracked down one of the original programmers ten years ago. The story he told me was that core of the code (originally written by Ryle and Doidic, two geniuses) was ported from Xpander to Matrix-6, changing MIDI and adding the new User Interface, and then from M-6 to M-1000, adding the next User Interface and making more changes to MIDI. The code was done with a cross-assembler on a PDP. Then one day, before the M-1000 firmware was 100% finished the removable disk with the sources fell on the floor, and there were no backups. So they shipped it out as is. End of the story, and the source code. 

This is what was told to me. Anyway, the later the part of the code the sloppier it looks. M-1000 code has quite a lot of dormant code from M-6, and even from Xpander, that is not used. Plus a lot of simple and pretty basic errors that would have been fixed if they had had more time (a few of them were fixed by someone in 1.1.3 hack). Plus unfinished MIDI implementation, etc etc. 

Concerning simply running it on 6309 at clock speed higher than 2 MHz, that has been discussed here: the code uses a _lot_ of cycle counting and loop based timing.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.