[hatari-devel] Moai demo as regressed a lot since hatari 1.4

Laurent Sallafranque laurent.sallafranque at free.fr
Thu Jul 14 10:22:10 CEST 2011


Hi,

I've reverted the patch in dsp.c :: run to apply the rev 3144 patch 
(just to see)

With new cpu, it's KO (it was expected)
with old cpu and the latest release source, it works perfectly well. 
(demo + music)

So, this demo frezees because of timing between CPU and DSP transfers.
(I think that the 68030 CPU timings are better but still not perfect in 
new winuae core).

For example :
I don't know if winUae core (68030) takes into account that a real atari 
Falcon has a 16 bits bus and not a 32 bits bus.
(this generates more waitstates cycles when reading/writing to odd 
addressses or to non 4 bytes aligned memories in .L and .W access)

Do you know if there's a parameter in winuae core that allows to tell 
we're using on a 16 bits BUS ?
If not, do you think it's easy to implement ? (I don't think so, but I 
don't understand the 68x00 part of hatari well enough for now).

This may probably be a part of the answear (cycles and precision problems).

Regards

Laurent


Le 14/07/2011 09:16, Laurent Sallafranque a écrit :
> Hi,
>
> I've searched and found.
>
> I've recompiled a tens of older versions of hatari between 1.4 and rev 
> 3150 (wich was already KO)
> I've both compiled old and new CPU to do the tests.
>
> So, with old CPU, moai.prg run until rev 3144. r=Rev 3145 is KO
> with new cpu, moai.prg is always KO.
>
> The change in this release was the way to compute DSP cycles from CPU 
> cycles.
> It has improved many prgs, so I won't touch it before the next release.
>
> So, I'll still have to have a look at Falcon Timings to improve accuracy.
>
> Regards
>
> Laurent
>
>
>
> It seems that moai as never worked with the new cpu (I thought I had 
> tested it).
>
> Le 13/07/2011 00:19, Nicolas Pomarède a écrit :
>> Le 13/07/2011 00:10, Laurent Sallafranque a écrit :
>>> I've recompiled the 1.4 from source to do some tests :
>>>
>>> moai in 1.4 version ran well, and sound was nice
>>>
>>> Moai in 1.5 version new cpu freeze after the loading screen and 
>>> sound is
>>> dirty
>>>
>>> moai in 1.5 version old cpu freeze after the loading screen with no
>>> sound at all
>>>
>>>
>>> I've looked at crossbar.c, there's no major change between the 2
>>> versions (except my new code for hadshake transfers at 32 Mhz, but not
>>> it's not involved here).
>>>
>>> I think there's a major change somewhere that has downgraded sound in
>>> some case (moai is a good example).
>>> A falcon frequency ? some timings ? ...
>>>
>>> what is hg bisect for ?
>>
>>
>> hg bisect is very useful to find where a problem was introuced.
>>
>> If you know rev A was OK and rev B was bad, but you don't know where 
>> the change happened, bisect is your friend :)
>>
>> First mark current rev as bad, for example "hg bisect -b 3420" ; mark 
>> hatari 1.4 as good "hg bisec -g 2892". Now hg will revert sources to 
>> the "middle" of those 2 revs. Compile hatari, test and mark the 
>> result as good or bad with -g or -b (without a revision).
>>
>> Continue until you find the error, and  hg will tell you what 
>> revision caused the problem.
>>
>> So, you should find the cause in O(log(n)), which is quite efficient.
>>
>> Nicolas
>>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>




More information about the hatari-devel mailing list