[sdiy] Reverse engineer an EPROM encoding?

[MTG]

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