[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
I believe the CPU/core is reporting divergent elapsed-cycles information to
the DSP and to the rest of the devices (particularly MFP). Or some
functional equivalent - duplicate and divergent calculations of elapsed
time.
This is what my tests are saying to me. If somebody can figure out how/why
that is happening and fix that, then it will be worth spending time on
cycle accuracy. Trying to fix the cycle sums before solving this will
probably be quite frustrating, at least in terms of making demos etc. work
and perform properly. :-/
If I can find some time I'll try to look at how that stuff actually works
inside Hatari. All I can say for now is that the DSP and MFP receive
divergent time information, however good or bad that information happens to
be in absolute terms.
Best,
Doug.
On 31 December 2015 at 13:24, Nicolas Pomar=C3=A8de <npomarede@xxxxxxxxxxxx=
>
wrote:
> Le 31/12/2015 14:14, Douglas Little a =C3=A9crit :
>
>> Hi Nicolas.
>>
>> I found the cause for the sound problem, it's related to the change
>> I made to pass a more accurate cycle count to DSP_Run. Unfortunately
>> it can't work at the moment until 68030 cycles are more accurate in
>> Hatari (by taking into account bus access time, as it's already the
>> case for 68000 STF mode).
>>
>> Basically it made the DSP runs for many more cycles than what the
>> CPU ran, causing some sync problem between DSP/CPU.
>>
>> I will revert the change to still get some sound in the meantime.
>>
>>
>>
>> Good news that you found the cause! I do find it a little strange though
>> - because I don't use the DSP for audio. In my case, if the DSP/CPU get
>> out of sync the program will lock because they are used synchronously.
>> This is exactly what happens in testing if I make a mistake with the
>> synchronous pattern. There are no timecritical mistakes possible without
>> 'program death'. There is no non-determinism in this respect.
>>
>> So why CPU/DSP timing would affect codec output is unclear. Of course it
>> could be affecting things earlier in the sequence - in the TOS crossbar
>> init code or TOS boot sequence. Then it could begin to make more sense
>> maybe... still odd though as TOS code should always synchronize
>> explicitly (unlike me) and not care about actual performance of any
>> device.
>>
>
> I must admit I didn't deep too much in the demo to see what part is
> sensitive to this cycles difference ; especially the difference is not th=
at
> often, it's mostly when some hardware registers are accessed and some wai=
t
> states must be added. If I count the wait states (and give more cycles to
> run to the DSP), sound is not here anymore, which is quite odd as there
> isn't that much IO accesses per VBL.
>
> Well, better improving the cycles per instruction, as looking at all the
> possible issues that the differences can create could be endless :)
>
> Nicolas
>
>
>
--089e0102e3de56a68b0528321da1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>From what I can understand so far, and what I=
9;ve seen in tests, there is an underlying problem which will foil attempts=
at fixing the cycle accuracy of the Falcon CPU.<br><br></div>I believe the=
CPU/core is reporting divergent elapsed-cycles information to the DSP and =
to the rest of the devices (particularly MFP). Or some functional equivalen=
t - duplicate and divergent calculations of elapsed time.<br><br>This is wh=
at my tests are saying to me. If somebody can figure out how/why that is ha=
ppening and fix that, then it will be worth spending time on cycle accuracy=
.. Trying to fix the cycle sums before solving this will probably be quite f=
rustrating, at least in terms of making demos etc. work and perform properl=
y. :-/<br></div><div><br></div><div>If I can find some time I'll try to=
look at how that stuff actually works inside Hatari. All I can say for now=
is that the DSP and MFP receive divergent time information, however good o=
r bad that information happens to be in absolute terms.<br></div><div><br><=
/div><div>Best,<br></div>Doug.<br><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On 31 December 2015 at 13:24, Nicolas=
Pomar=C3=A8de <span dir=3D"ltr"><<a href=3D"mailto:npomarede@xxxxxxxxx.=
fr" target=3D"_blank">npomarede@xxxxxxxxxxxx</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">Le 31/12/2015 14:14, Douglas Little a =C3=A9crit =
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi Nicolas.<br>
<br>
=C2=A0 =C2=A0 I found the cause for the sound problem, it's related to =
the change<br>
=C2=A0 =C2=A0 I made to pass a more accurate cycle count to DSP_Run. Unfort=
unately<br>
=C2=A0 =C2=A0 it can't work at the moment until 68030 cycles are more a=
ccurate in<br>
=C2=A0 =C2=A0 Hatari (by taking into account bus access time, as it's a=
lready the<br>
=C2=A0 =C2=A0 case for 68000 STF mode).<br>
<br>
=C2=A0 =C2=A0 Basically it made the DSP runs for many more cycles than what=
the<br>
=C2=A0 =C2=A0 CPU ran, causing some sync problem between DSP/CPU.<br>
<br>
=C2=A0 =C2=A0 I will revert the change to still get some sound in the meant=
ime.<br>
<br>
<br>
<br>
Good news that you found the cause! I do find it a little strange though<br=
>
- because I don't use the DSP for audio. In my case, if the DSP/CPU get=
<br>
out of sync the program will lock because they are used synchronously.<br>
This is exactly what happens in testing if I make a mistake with the<br>
synchronous pattern. There are no timecritical mistakes possible without<br=
>
'program death'. There is no non-determinism in this respect.<br>
<br>
So why CPU/DSP timing would affect codec output is unclear. Of course it<br=
>
could be affecting things earlier in the sequence - in the TOS crossbar<br>
init code or TOS boot sequence. Then it could begin to make more sense<br>
maybe... still odd though as TOS code should always synchronize<br>
explicitly (unlike me) and not care about actual performance of any device.=
<br>
</blockquote>
<br>
I must admit I didn't deep too much in the demo to see what part is sen=
sitive to this cycles difference ; especially the difference is not that of=
ten, it's mostly when some hardware registers are accessed and some wai=
t states must be added. If I count the wait states (and give more cycles to=
run to the DSP), sound is not here anymore, which is quite odd as there is=
n't that much IO accesses per VBL.<br>
<br>
Well, better improving the cycles per instruction, as looking at all the po=
ssible issues that the differences can create could be endless :)<span clas=
s=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Nicolas<br>
<br>
<br>
</font></span></blockquote></div><br></div>
--089e0102e3de56a68b0528321da1--