Re: [hatari-devel] Improved YM2149 sound |

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]

*To*: hatari-devel@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [hatari-devel] Improved YM2149 sound*From*: David Savinkoff <dsavnkff@xxxxxxxxx>*Date*: Sat, 26 May 2012 16:49:24 -0600 (MDT)*Cc*: hatari-devel@xxxxxxxxxxxxxxxxxxx

On Saturday 26 May 2012 14:03, Nicolas Pomarède wrote: > On 26/05/2012 21:36, David Savinkoff wrote: > > Hi Nicolas, > > > > I'm going to air my thoughts so that you can analyse my reasonings. > > > > As regards Paulo's tables, they were measured well, making it possible > > for me to decide what was causing the non-linearities. I first thought it > > may be compression due to transistor gain so I was looking at sigmoid > > functions, especially tangent... but Paulo's tables disagreed. So I > > thought of a voltage source that could pull up with a given Thevinen > > resistance... Paulo's tables agreed. Next came circuit analysis and > > experimentation... The rest is history. Paulos's tables give > > justification to the math model. The math model allows me to determine > > the actual resistances and ac voltages... and allows me to use the > > derived formulas in further circuit analysis... The case is cracked wide > > open and can be tested against itself. Paulo's tables told me enough to > > let me see the rest of the picture... The math model goes beyond the > > tables now. > > > > > > What the math model does: > > > > - Paulo may have measured with per=0, but the math model gives a voltage > > level for any discarded high (or low) frequency because the residual > > voltage level is the dc component of that frequency. > > > > - Modeling of all combinations of discarded high frequencies (Quartet) > > and all combinations of non-discarded frequencies (Normal). > > > > - Paulo's tables do not impose limitations on the math model because the > > math model now describes Paulo's tables. > > > > The code meets the objective of the math model as mentioned above. > > The code does not differentiate between Normal mode and Quartet mode > > because it is not necessary to do so... There really is no Quartet mode, > > just filtered high frequencies... just like a real ST. > > > > When "normal" (non sample) music is played and any voiceX goes to per=0 > > (or per is any filtered frequency), the new code treats the voltage > > exactly as if it were filtered. This is what we want. Especially when it > > happens transiently. The new code does way more than Quartet mode. > > Simplicity leads to Generality! > > > > > > A table to represent Normal (ac + dc components) and Quartet (dc > > component) would have to be dimensioned: > > > > ((32 #ac+dc#)+(32 #dc#)) * ((32 #ac+dc#)+(32 #dc#)) * ((32 #ac+dc#)+(32 > > #dc#)) > > > > instead of the current: > > > > (32 #ac+dc#) * (32 #ac+dc#) * (32 #ac+dc#) > > Note that the current table treats Quartet mode the same as Normal mode > > by using the same table-value for both. > > > > I noticed that using the "-1" correction is a good substitute for a large > > look-up table. It works good because Paulo's Quartet table is related to > > the Normal table. Furthermore, the "-1" correction is already summed into > > the table with the other values. > > > > Picking 1 less from the Normal table as a Quartet value is a better > > approximation than picking the same value (the current method in Hatari). > > > > Picking 1 less also allows us to use the current table also! > > > > > > ps. > > I'll submit a comment patch tonight (pacific standard time). > > > > Please let me know if my explanations are not clear, or if I'm > > overlooking something. I'm now going to ponder the code changes > > you mentioned. > > > > Sincerely, > > David > > Hello > > I agree with your explanation, and especially with the fact that there > shouldn't be 2 "methods" depending on the fact that the ST is playing > samples or not, in quartet more or not. > > Having a math model that fits all case looks good to me (I know some ST > emulators are using different tables by trying to "detect" if the YM is > currently used to play samples or not, I never really "liked" this idea). > > But still, I think there should be a difference on whether you're > modulating volume on a voice with (tone ON and per=0) and on a voice > with (tone OFF and per=0), but in the case of your patch, only per=0 is > taken into account. > My patch detects when step = 0. This is what I want, because my patch should take effect whenever a frequency is filtered from the ouput of the YM2149. My patch is analog and does not touch the digital side of the YM2149 (and should not be controlled by the digital side either). I notice that Ym2149_ToneStepCompute() returns 0 whenever a frequency is dropped; If Ym2149_ToneStepCompute() is working correctly, then my patch will work correctly. > > Well, on the other hand, it's true that for per<=5 (or 80% of nyquist > freq), output is set to 1, so we get the same behaviour as a "1" output > when tone is OFF. Except that if voice is ON, we have a square wave on a > real ST, instead of a constant "1" signal in Hatari's model. > I see the constant "1" as the dc voltage left over after the high frequency is filtered (dc is not filtered by a lowpass filter). ac + dc components of YM2149 2v ____ ____ / \ / \ Equals 0v / \____/ \ ac component dc component +1v ____ ____ / \ / \ Plus 1v dc ____________________________ -1v / \____/ \ > > If I understand, you apply a 0.5 coeff in that case to mimic the fact > that the output power of the square wave is half the one of a constant > wave. And that 0.5 coeff becomes "-1" at the volume level, since it's an > exponential function. Is that it ? > As seen in the waveform figure above, the dc component is half way between 0v and 2v equalling 1v for this type of waveform. The YM2149 pulls up with a different impedance than how R8 pulls down. Thus, the voltage level is greater than half way for the YM2149. The math model accounts for this. Note that the "-1" table offset is a "good fit" for the function, it is not derived from it. David > > Nicolas

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [hatari-devel] Python UI questions** - Next by Date:
**Re: [hatari-devel] Improved YM2149 sound** - Previous by thread:
**Re: [hatari-devel] Improved YM2149 sound** - Next by thread:
**Re: [hatari-devel] Improved YM2149 sound**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |