From: mrk@gvgspd.gvg.tek.com (Michael R. Kesti)
Newsgroups: rec.music.makers.synth
Subject: Re: WS RAM-corruption troubles
Date: 24 Jan 93 20:15:57 GMT
Organization: Grass Valley Group, Grass Valley, CA
NNTP-Posting-Host: gvgspd.gvg.tek.com

In article <C13EpG.1GA@sci.kun.nl> marten@cs.kun.nl (Marten van Hulst) writes:

> I can imagine situations in which even a sysex transfer is not possible
> any more, en THEN you are stuck!
>
> Do you know of situations like this, is it common, or do I have old ROM
> chips?

This may not be exactly what you are looking for, but I have had a similar
experience with a Digital Music Corp MX-8 midi data router/processor
scrambling its patch data and subsequently generating invalid sysex dumps.
The MX-8 "went crazy" while changing a patch's I/O routings when I had
inadvertently set up a data feedback loop.  The unit  had to be powered
cycled in order to regain control.  When powered back up, I found that a
number of patches (the first 8 or so) were partially overwritten with
trash.  Unfortunately, this is the region in which I had made recent
changes, so I didn't yet have a sysex dump from which to restore these
patches.  I proceeded to rebuild them manually, and, when I was done, I
immediately sent a dump to the DataDisk to protect myself from having to
rebuild them again (there's nobody who knows the value of a backup more
than a user who just lost some data!).  I then discovered that the number
of bytes in the dump was about 20% of previous dumps!  I sent a dump to
the computer (using the shareware package GETIT) to see if I could get a
full dump that way.  I found that I could not, and took advantage of the
ability to examine the data more closely on the computer.  I found that
the data for one of the patches that had been corrupted had a value of
0xF7 in the position where Chain Mask 1 should be.  Both the DataDisk and
GETIT were properly interpreting this as End Of Sysex, and terminating the
file upon its receipt.

Chain Mask 1 is associated with the MX-8's patch chain function, a feature
that allows the user to program a series of patch change commands that are
to be transmitted to the outputs when a given MX-8 patch is selected.  Bits
D0..D3 of this byte indicate whether chain elements 1..4 are enabled,
respectively, while bits D4..D7 are to be zeros, so that the data is not
interpreted as a status byte.  Apparently, when garbage was written into
the patch memory, bits D4..D7 got set to ones, and when the MX-8 sends a
dump, it makes no effort to check for "sane" data.

The 7 (0111B) in the lower nibble was appropriate (i.e., I had elements
1..3 enabled and element 4 disabled), so the problem became how to reset
bits D4..D7 (to which the user has no access!).  I found that manipulating
bits D0..D3 had no effect on the upper nibble, and eventually solved the
dilema by copying a patch whose data had not been corrupted into the
problem patch, then reconstructing the desired setup in the latter patch.
This got me more data per dump, but still not all of it.  I eventually had
to rebuild three patches before a complete dump could be attained.  I later
discovered still more invalid data.  For example, I subsequently used the
Compander function on a patch and found its ratio byte to be out of range.
It hadn't mattered until I set the compander enable to TRUE, but when
enabled, the Compander behaved in a very strange fashion!

It should have been a fairly simple matter to have incorporated data
sanity checks into the MX-8.  For example, in the case of the Chain Masks,
AND the byte with 0x0f before writing it to memory when the user alters it.
Alternatively, each data element of a patch could be "sanitized" as the
patch is loaded.  DMC, however, appears not to have done either of these,
so the potential for bad data exists.

Hey, hey, hey!  Let's be careful out there!

-- 
============================================================================
Michael Kesti  Grass Valley Group, Inc. | "And like, one and one don't make
    mrk@gvgspd.GVG.TEK.COM              |  two, one and one make one."
    !tektronix!gvgpsa!gvgspd!mrk        |         - The Who, Bargain