An Obscure Code Bug in the Sequential Six-Trak and MAX , and a new firmware version for the Six-Trak

The symptoms:

I recently got an email from Stephan Kuempel, informing me of some strange behavior he had discovered in his Six-Trak several years ago. When MIDI mode 4 was selected, so that each voice could have its own timbre, and its own MIDI channel, he noticed that a few parameters could not be controlled properly using MIDI CC's, but only for the top two voices. When I was working on the Max and Multi-Track code revisions not too long ago, I also set up a computer simulation of the Six-Trak for comparison. I was able to use this simulation to look into what was happening in the situation that he described.

The cause:

It turns out that in the MIDI CC processing code, there is a small bug. In one place they need to multiply a value by three to form a table look-up address. To do this, they do a left shift, which is the same as multiplying by two, and then they add in the original value to get three times the original value in the accumulator. The problem is that when they do the left shift, they use an instruction that also shifts in any carry from a previous operation. They don't clear the carry first. If it happens to be set (1), instead of n x 3, they will get (n x 3) + 1, which is an incorrect result. Because of the previous operations, the carry is only set for the top two voices, so only they have the problem. When the CPU gets the wrong table address, it jumps to an incorrect location, and more or less crashes, although it seems to recover, after doing a bunch of things you don't really want it to do. The fix is quite simple. I just had to change the code to use a different left shift instruction that does not use the carry flag. The Z80 CPU has both types. This fixed the problem.

Here are EPROM binary images of versions V9 and V11 of the Six-Trak code, which have the errant opcode changed to fix the bug. I have also changed the displayed version number of the V11 version to V12. The version number and the op code fix were the only two changes. (two bytes total) The V9 file only has the op code fixed. I left the version number alone.

Unfortunately, the SCI MAX uses the exact same code for CC parameter updates, so it has the same bug. Here is an archive which contains V05 of the MAX code with the one-byte change to fix the bug. No other changes were made.

A New Firmware version for the SCI Six-Trak:

I was recently asked if I could add Unison detune to the Six-Trak. While I was working on that, several other features were suggested which I have also implemented. So I now have a version which I am calling V14. (The version number will display as 14) Here are the new features:

1) Unison detune has been added. To allow storing the setting with the patch, I used the Oscillator Fine Tune parameter to control the detune amount. If the patch does not enable Unison mode, or if MIDI mode 4 is selected, this parameter works normally. When detune is enabled, oscillator fine tune amount is set to 0.

2) Patches can now be selected using the value pot. In Program Select mode, the value pot will now scroll through the programs as it is turned. Two ranges are used. 0-59 and 40-99. When the pot is turned two steps beyond 59, the high range is selected. When it's turned two steps below 40, we switch back to the low range. This may seem a little odd, but trying to cover the entire 0-99 range with the pot made the steps too close together and hard to control. Patches can also be selected using the keypad, as before.

3) A new parameter (front panel #37 or MIDI #39) has been added. It's global, and is not stored with each patch. In fact, it's reset at power up. This parameter has three values, 0, 1, and 2. When it's set to 0, all voice LFO's behave normally. When it's set to 1, all voice LFO's are reset to the "no modulation" state when the voice is assigned. When it's set to 2, all voice LFO's are set to the "full modulation" state when the voice is assigned. So this parameter allows the LFO's to sync to the start of a new note. It can be controlled using MIDI, the same as other parameters, but there is only one of them, not one per voice. So all voices will have the same setting.

The new firmware has only been tested by a few people, so I am not ready to sell programmed EPROMs. But if you have a way to program your own 27128, 27C256 or 27256, and want to try it, you are encouraged to do so, with the understanding that this code has not been well tested, and I would really appreciate any testing results, so that I can consider it "released". Please do not erase your old code EPROM, as it's always good to keep it for reference. If you use a 27256 or 27C256, place the code at offset 0x4000 in the EPROM. If you fill the buffer with 0FF's first, and then load the image, the buffer checksum should be 0x0EC3. If you use a 27128 or 27C128, the checksum should be 0x4EC3.

The new code also contains the 1-byte change that I made to fix the CC bug mentioned at the top of this page.

Here is an archive containing a binary image of the new firmware.

Here is some information about how to remove and install EPROMs.