[sdiy] Reverse engineer an EPROM encoding?

[Tom Wiltshire]

Isn't Mu-law quite likely? Have you tried that? It was widely used for 8-bit samples, so it'd have been current when people moved up to 12-bit.
According to this Wikipedia article, there's an "A law" variant too - same idea, different curve.

http://en.wikipedia.org/wiki/Μ-law_algorithm

(Compare the image at the bottom of the page with your R100_first_ramp.jpg)

Either way, you're just hunting for a compensation curve. Cheater's idea of deriving it by experiment isn't too far out - it might be doable with sufficient accuracy.

I can see real benefits to be had from such an encoding on a drum sample system, since drum hits typically have a short loud peak, followed by a longer body of sound at a much reduced (and reducing) amplitude. With a limited 12-bit resolution, that'd mean that most of your signal will actually be only 8 or 10 bit. Anything you can do to mitigate against that is going to be a plus.

T.



On 16 Oct 2013, at 18:09, MTG <grant at musictechnologiesgroup.com> 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