MFP / CPU clock ratio

A forum about the Hatari ST/STE emulator - the current version is v2.0.0

Moderators: simonsunnyboy, thothy, Moderator Team

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Mon May 08, 2017 12:57 pm

I can not comment on hardware logic. My knowledge in electronic is minimal.

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Mon May 15, 2017 11:35 pm

cpuclock170515.png


Here is what I have recorded so far using my mfpcpu4.prg program. I'd like to cross the result with the SID-like dephasing program. Currently I'm doing it just by listening to the sound but it would be much better with a good recording (high sampling rate). It requires fairly long record as some sounds take more than 30 minutes to complete a full phase. Anyway if someone is up to the task that would be great.
You do not have the required permissions to view the files attached to this post.

tin
Atari freak
Atari freak
Posts: 70
Joined: Mon Jul 23, 2012 7:59 am
Contact:

Re: MFP / CPU clock ratio

Postby tin » Tue May 16, 2017 6:01 pm

Which one of these prgs do you need to have sampled? I have an somewhat OK ADC connected to an ST for the sole purpose of measuring it. Half an hour would of course result in an >300MB 16 Bit 96kHz sample, but if you insist, I could do the sample :)

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Wed May 17, 2017 1:48 pm

Thank you tin I would appreciate that.

I have an updated version of the program that allow to change the SID parameters on the command line but I still have problems to communicate with my ST so it's not available at the moment. Meanwhile you can record my previous attachment . The idea is that the record must be long enough to have 2 silenced part in it (that's when the YM and the timer are in opposite phase). The sample resolution can be very minimum only the sampling rate matter. I hope it'll be fairly compressible.

tin
Atari freak
Atari freak
Posts: 70
Joined: Mon Jul 23, 2012 7:59 am
Contact:

Re: MFP / CPU clock ratio

Postby tin » Thu May 18, 2017 7:21 am

BenOVR wrote:Meanwhile you can record my previous attachment . The idea is that the record must be long enough to have 2 silenced part in it (that's when the YM and the timer are in opposite phase). The sample resolution can be very minimum only the sampling rate matter. I hope it'll be fairly compressible.

OK, great, I'll send you a PM with the results, probably this weekend.

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Wed May 24, 2017 7:33 pm

Just another unrelated thing I was thinking about:

When writing the register #13 we know it resets the envelop shape. But does it reset the envelop period counter as well ?

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Wed May 24, 2017 8:52 pm

BenOVR wrote:Just another unrelated thing I was thinking about:

When writing the register #13 we know it resets the envelop shape. But does it reset the envelop period counter as well ?

Hi
I don't have my tests with me at the moment, IIRC it doesn't, but I will try to check this (using a rather low freq and writing in reg #13 it is easy to see if the envelope' peaks still happen at the same moment)
Nicolas

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Wed May 24, 2017 9:03 pm

npomarede wrote:
BenOVR wrote:Just another unrelated thing I was thinking about:

When writing the register #13 we know it resets the envelop shape. But does it reset the envelop period counter as well ?

Hi
I don't have my tests with me at the moment, IIRC it doesn't, but I will try to check this (using a rather low freq and writing in reg #13 it is easy to see if the envelope' peaks still happen at the same moment)
Nicolas


Thanks. That's what I would assume. Usually does not have a real impact as the envelop period is usually low.

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Fri May 26, 2017 3:45 am

My latest and more precise results with a long run of mfpcpu4.prg:

stfpal-zoom.png
Overview

stfpal-overall.png
Zoomed
You do not have the required permissions to view the files attached to this post.

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Fri Jun 09, 2017 1:47 pm

BenOVR wrote:
npomarede wrote:
BenOVR wrote:Just another unrelated thing I was thinking about:

When writing the register #13 we know it resets the envelop shape. But does it reset the envelop period counter as well ?

Hi
I don't have my tests with me at the moment, IIRC it doesn't, but I will try to check this (using a rather low freq and writing in reg #13 it is easy to see if the envelope' peaks still happen at the same moment)
Nicolas


Thanks. That's what I would assume. Usually does not have a real impact as the envelop period is usually low.

Hi
I had time to check this aspect of the envelope generator, and this time again the measure is not what was expected or documented :)
The measure is made by using envwave 8 (pattern \|\|\|\) with envper=$1F4, ie 500 Hz. This means the volume changes every 0.002 sec.

So,first the reference wave :
ym_env_ref.png

Then, I change volume to 0 in the middle of the 3rd env phase. We can see it's immediately taken into account :
ym_env_vol0.png

Now, at the same point where volume was set to 0 on the previous wav, I write value 8 into reg 13, which is known to restart the wave from the beginning :
ym_env_restart.png

We can see that volume is set to max again (not as high as the 1st time, but that's due to the filtering in the STF), but more important we see that a new phase of 0.002 sec is also started.
So, writing to reg 13 restarts the env pattern immediately, but it also resets the env_per counter to 0 to immediately start a full phase.

In summary, measures on a real YM shows that most documentation / emulation are wrong or incomplete ; period counts up from 0 to max_per, noise counter is incremented twice slower than tone counter and writing to envwave register does both a restart of the wave pattern and a new phase.
The only thing I can't measure by recording my STF output to a wav file is whether per=0 gives the same result as per=1 for tone generator (it's the case for noise and env). It would require a logic analyzer to sample up to 125 or 250 kHz.

All those changes are included in the next version of Hatari for improved sound accuracy.

Nicolas
You do not have the required permissions to view the files attached to this post.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: MFP / CPU clock ratio

Postby Steven Seagal » Fri Jun 09, 2017 8:19 pm

That's a nice test that seems conclusive.
Wonder if there are cases (tunes) where we can hear a difference? I can't with Closure or Nostalgic/Credits for my part.

But I'm not sure the noise counter goes at half the speed of the tone counter, because slower noise counter sounds worse to me in Action-Biker #1 for example.

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: MFP / CPU clock ratio

Postby troed » Fri Jun 09, 2017 8:51 pm

Steven Seagal wrote:Wonder if there are cases (tunes) where we can hear a difference? I can't with Closure or Nostalgic/Credits for my part.


I'm not sure the cause is one that has been identified yet (maybe the noise period?), but all of 7an's recent songs have hi-hats that are TOO LOUD in Hatari compared to target hw. They sound better in sc68. Haven't tested STeem SSE, sorry :P No Windows ..

(It's a big enough difference for me as a non-audio guy to easily pick it out as well ;))

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Fri Jun 09, 2017 10:39 pm

Steven Seagal wrote:That's a nice test that seems conclusive.
Wonder if there are cases (tunes) where we can hear a difference? I can't with Closure or Nostalgic/Credits for my part.

I don't think there're many tunes where you can actually hear difference (else many people would have reported sound issues in emulator since years :) ). But it's certainly possible to hear slight difference in some sync buzz sounds that would be designed on purpose to fool emulators.
But I'm not sure the noise counter goes at half the speed of the tone counter, because slower noise counter sounds worse to me in Action-Biker #1 for example.

What do you mean by "sound worse" ? Did you actually compare real STF output with emulation, or is that just when comparing both emulation method ? I just ran BIG demo on my STF and for me emulation sound is closer to real HW when noise counter goes twice slower than tone counter. And in the measure I made for which I posted screenshots before, we can really see that for per=31 tone oscillates twice more than noise.
Maybe the difference you hear is due to the post processing filters used in Steem. The filters used to simulate the analog behaviour of the signal can really modify the final result (as Troed reported with some 7an music not closely emulated yet under Hatari)

Nicolas

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: MFP / CPU clock ratio

Postby Steven Seagal » Sat Jun 10, 2017 7:06 am

The comparison is between STE + TV vs Steem test build "MAME-like" + multimedia speakers.
But it's possible you do something else than MAME in Hatari.
For reference, in MAME it is:

Code: Select all

    m_count_noise++;
    //if (m_count_noise >= (OPTION_HACKS?2:1)*(psg_reg[PSGR_NOISE_PERIOD] & 0x1f)) //test
    if (m_count_noise >= (psg_reg[PSGR_NOISE_PERIOD] & 0x1f))
    {
      /* toggle the prescaler output. Noise is no different to
       * channels.
       */
      m_count_noise = 0;
      ASSERT(!(m_prescale_noise&0xfe));
      m_prescale_noise ^= 1;

      if (m_prescale_noise)
      {
        /* The Random Number Generator of the 8910 is a 17-bit shift */
        /* register. The input to the shift register is bit0 XOR bit3 */
        /* (bit0 is the output). This was verified on AY-3-8910 and YM2149 chips. */
        ASSERT(m_rng);
        m_rng ^= (((m_rng & 1) ^ ((m_rng >> 3) & 1)) << 17);
        m_rng >>= 1;
      }
    }



Notice the "prescaler output" is toggled, and we take a bit from the RNG only when it's set: could it explain the /2 impression?

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Sat Jun 10, 2017 8:22 am

The code in MAME looks correct, it gives half freq for noise compared to tone. If you want to be sure, play noise with per=31 under steem and save the result as a wav and compare this with the images I posted before, compare this also with tone having per=31. This is the best test to see if your emulation is correct.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: MFP / CPU clock ratio

Postby Steven Seagal » Sat Jun 10, 2017 9:21 am

Hmm, and where do you see it's half freq?
Here is the tone part:

Code: Select all

      m_count[abc]++;
      if(m_count[abc]>=TONE_PERIOD(abc))
      {
        ASSERT(!(m_output[abc]&0xfe));
        m_output[abc] ^= 1;
        m_count[abc]=0;
      }


It goes at the same speed except for tone '1' is 1, for noise '1' is 0 or 1 depending on the RNG.

EDIT: and '0' is 0 for tone, 0 or 1 for noise depending on the RNG.

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Sat Jun 10, 2017 10:32 am

Steven Seagal wrote:Hmm, and where do you see it's half freq?
It goes at the same speed except for tone '1' is 1, for noise '1' is 0 or 1 depending on the RNG.

EDIT: and '0' is 0 for tone, 0 or 1 for noise depending on the RNG.

It's half-freq in the noise generator you posted above. m_prescale_noise is toggled every time m_counter_noise >= noise_per, which means a new RNG value is computed every two times when m_counter_noise>noise_per. So, RNG is called twice less often than toggling tone output, which effectively gives a x2 difference in freq for similar tone/noise value.
You should really study the signal output of Steem as a wav file, this is the only "clean" way to really measure if Steem produces the correct phase length, just listening to complex tunes is not enough.

Nicolas

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: MFP / CPU clock ratio

Postby Steven Seagal » Sat Jun 10, 2017 11:55 am

Alright, initially I thought you said the noise counter itself was half slower.
The difference it makes is quite audible in the example I gave.
Guess the problem was up to now, noise freq was double in Hatari, but look at this:

Code: Select all

void psg_tone_advance(int psg_tonemodulo_2,int &psg_tonecountdown,
                      bool &psg_tonetoggle) {
  psg_tonecountdown-=TWO_MILLION; 
  while (psg_tonecountdown<0){           
    psg_tonecountdown+=psg_tonemodulo_2;             
    psg_tonetoggle=!psg_tonetoggle;                   
  }
}

void psg_noise_advance(int psg_noisemodulo,int &psg_noisecountdown,int &psg_noisecounter,bool &psg_noisetoggle) {
  psg_noisecountdown-=ONE_MILLION;   
  while (psg_noisecountdown<0){   
    psg_noisecountdown+=psg_noisemodulo;   
    psg_noisecounter++;                       
    if(psg_noisecounter>=PSG_NOISE_ARRAY){     
      psg_noisecounter=0;                       
    }
    psg_noisetoggle=psg_noise[psg_noisecounter];   
  }
}


In Steem, this frequency aspect was correct already.
This code is difficult to understand (for me at least), but we can see that for noise it is ONE_MILLION, for tone TWO_MILLION.
On the other hand Steem didn't use the proper RNG algorithm, it just used rand(), and it used a countdown.

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Sat Jun 10, 2017 1:02 pm

Steven Seagal wrote:Alright, initially I thought you said the noise counter itself was half slower.

That would be the same: whether the counter is incremented as 125 kHz (as I do now in Hatari) or whether it's incremented at 250 kHz but you skip 1 phase every 2 phases (as done in MAME), it gives the same waveform result (the only difference would be the transition between 2 noise per value, but that would really be hard to hear).
I can't say if the correct method used in real YM is to increment noise counter at half freq or to increment it at full freq and skip 1 phase. It would need to decap a chip to know that (or to write a rather more complex test program as I did for tone per, changing noise per at very precise cycle, but I don't think it's worth the effort)
In Steem, this frequency aspect was correct already.
This code is difficult to understand (for me at least), but we can see that for noise it is ONE_MILLION, for tone TWO_MILLION.
On the other hand Steem didn't use the proper RNG algorithm, it just used rand(), and it used a countdown.

From what I saw in original Steem sound code, they used a different method when changing per counter : they don't take the value into account immediately, but they wait for the end of current phase to apply the new value. This is not how real YM works anyway, but this makes the code more complex for sure.

Nicolas

User avatar
BenOVR
Atariator
Atariator
Posts: 25
Joined: Wed Nov 02, 2016 7:54 pm
Contact:

Re: MFP / CPU clock ratio

Postby BenOVR » Sun Jun 11, 2017 3:54 pm

Nice work. Thank you.

With sc68 for a long time I've always reset the envelop counter at the same time the envelop shape was written without knowing if it was right or not.

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Sun Jun 11, 2017 8:50 pm

BenOVR wrote:Nice work. Thank you.

With sc68 for a long time I've always reset the envelop counter at the same time the envelop shape was written without knowing if it was right or not.

It was also more or less reset in Hatari, but that was mainly due to a side effect in the period computation and also because no one ever reported sthg about it :)
At least, things should be clearer now, even if not all those recent measures will have an audible result on sound emulation, we should have a more accurate idea of the inner work of the YM.

Nicolas

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Thu Jun 29, 2017 8:57 am

npomarede wrote:In summary, measures on a real YM shows that most documentation / emulation are wrong or incomplete ; period counts up from 0 to max_per, noise counter is incremented twice slower than tone counter and writing to envwave register does both a restart of the wave pattern and a new phase.
The only thing I can't measure by recording my STF output to a wav file is whether per=0 gives the same result as per=1 for tone generator (it's the case for noise and env). It would require a logic analyzer to sample up to 125 or 250 kHz.

All those changes are included in the next version of Hatari for improved sound accuracy.

Nicolas

Hi
'tin' made some measures of a test program I sent him using a signal analyzer, and this confirms that per=0 gives the same output signal a per=1 for tone generator.
So, hopefully, all the "logical" work of the YM2149 should now be known.
The remaining part that can make a difference is the filtering method to mimic the digital->analog output of the YM2149 ,which can be very subjective depending on what everyone used to hear on his own speaker / CRT screen back then.

Nicolas

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: MFP / CPU clock ratio

Postby troed » Thu Jun 29, 2017 10:14 am

npomarede wrote:The remaining part that can make a difference is the filtering method to mimic the digital->analog output of the YM2149 ,which can be very subjective depending on what everyone used to hear on his own speaker / CRT screen back then.


(Except the very big difference in 7an's hi-hats of course, which are not due to what people are used to hearing .. ;))

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: MFP / CPU clock ratio

Postby npomarede » Thu Jun 29, 2017 10:18 am

troed wrote:(Except the very big difference in 7an's hi-hats of course, which are not due to what people are used to hearing .. ;))

Yes, let's say that at the moment (at least in Hatari) the "subjectivity" of some filters is sometimes too far from reality :)

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: MFP / CPU clock ratio

Postby Steven Seagal » Thu Jun 29, 2017 4:16 pm

For hi-hats in Hatari, we know it wasn't really the filter but noise frequency.
The filter is very subjective because it depends on the TV/monitor/connection. There is not only one good filter.
I recently could hear the output of my STE on PC speakers through the phono connection: yuck! To be accurate we should emulate all parasites due to bus activity, pixel colour etc.


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 1 guest