[sdiy] Reverse engineer an EPROM encoding?

[Ben Lincoln]

This is probably a naive suggestion, but does it use a format where the
per-sample value is on an exponential or log scale instead of a linear
scale? The output graph you sent for the plain old ramp looks like an
exponential curve to me, or like the comparison graphs on this page that
show perceived loudness versus acoustic intensity
(http://www.acoustics.salford.ac.uk/feschools/waves/wavetypes2.php).

I've read about digital audio formats in the past that used log or
exponential scaling instead of linear, because it means that for a given
bit depth, you get fidelity that is more optimized for how our ears (and
eyes) work, but I've never actually run across one. Maybe that was a trick
that Kawai used to improve the perceived fidelity of this device despite
its 12-bit design?

I haven't done the math, but I would think that if it were of that design,
then feeding a linear ramp into it would give you an output waveform like
the one in your scope photo.

On Wed, October 16, 2013 10:09 am, MTG wrote:
> So I'm still banging away on this Kawai R100 drum machine when time
> permits. The idea is to be able to make fresh sound ROMs for it. It's a
> great 12-bit drum machine. The unit uses a couple of ASICs where Linn
> and Oberheim, et al used counters. Here is the jist:
>
> AGU -> ROM -> DGU -> DAC (12-bit linear?)  [DAC312/AM6012]
>
> I assume AGU is Address Generation Unit and DGU is Data...  The
> schematic is widely available, such as
> http://www.burnkit2600.com/manuals/KAWAI_R-100_SRV.pdf .
>
> Now if you assume the whole thing is linear and you code up a ramp
> waveform and stuff it in and EPROM and press play, this is what you get
> out. NOT ramp. Some EXPONENTIAL thing. The sign bit is understood and
> the output wave is single-ended on the +15v rail (centered about half
> way).
>
> http://musictechnologiesgroup.com/blog/wp-content/uploads/2013/10/R100_first_ramp.jpg
>
> So there was this theory floated around on the web that they used some
> 12-bit DAT encoding method (http://www.rfc-editor.org/rfc/rfc3190.txt)
> in the ROMs that was expanded by the DGU. And as unlikely as that seems,
> it's not too far off. But just far enough to sound bad if you try and
> account for it.  RFC 3190 describes something not unlike uLaw where you
> have big Chord bits and smaller Step bits.
>
> I coded up something that becomes a ramp if you run it through RFC 3190.
> Simulate if you will. And this is what you get. It should be a nice
> ramp.  But it's still not.
>
> http://musictechnologiesgroup.com/blog/wp-content/uploads/2013/10/R100_non_ramp.jpg
>
> It has flattened out significantly though, so it's a step in the right
> direction. So I wonder if anyone is aware of any other 12-bit encoding
> schemes they might have used?? DAT didn't come out until after the R100
> so I think that was a red herring.
>
> GB
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>