[hatari-devel] WinUae CpuCore New patch with 3 important changes

[Nicolas Pomarède]

Le 12/10/2011 23:44, Laurent Sallafranque a écrit :
> Hi all,
>
> I've just uploaded a new patch for the winUae core.
>
> I know I should have split this patch in 3 parts as it concerns 3
> different things, I apologize for that.
>
> This patch does 3 things :
>
> 1) I've reintruduced the nCurInstrCycPos in all the cores and the call
> to M68000_AddCyclesWithPairing(cpu_cycles) in the 68000 core only.
> Like this, there's less work to do now to upgrade the compatibility of
> this new core.
>
> I've done some Atari St(FE) tests : some demo runs, some are not yet
> running, but it seems to be quite often the same problem (bus error at
> addr $7, ...)
>
>
> 2) I've fixed all the cycle exact cpus.
>
> Now these cpu's are running. Of course, I haven't yet implemented the
> cycle exact into thedifferent components of hatari.
> I think we should try to reach thesame level of compatibility with the
> new core as we had with the old one before using the cycle exact.
>
> Now, only the 68040 + MMU doest'n run.
>
> I've found something strange : if I change the core while hatari is
> running (for example switching from 68030 to 68000), hatari doesn't
> reparameters correctly.
> I have to save my new parameters into hatari.cfg, quit hatari and then
> restart it to allow the changes to be taken into account). This will
> have to be fixed.
>
>
> 3) I've found and corrected the problem with all the falcon demos and
> games that need to run at 32 Mhz only.
>
> This fix EKo System, Are you experienced, Lost Blubb, Time out, Cebit93
> demo, outline 2006 intro, bounds42, watership, ...)
> I've tested all of them with 68030 CPU and prefetch mode activated.
> I've tested some of them with 68030 no prefetch and some of them with
> 68030 cycle exact.
>
> Some of them still have some glitched or a noisy music, some other works
> well, but all runs when they were freezing before at 16 Mhz.
>
> The problem was in the call of add_cycles (I shouldn't multiply the
> cycles by 2).
>
> Could someone confirm that these programs run well now ?
>
> Best regards
>
> Laurent

Hello Laurent

regarding your patches, as it fixes 3 important things, it would be 
better to do 3 commits for each separate problem you fix, else we just 
see a global commit, and it's hard to see which part of the commit is 
related to point 1), 2) or 3).

In that case, if they were regression, we could not use the "bisect" 
option of Mercurial, because all the changes are in only 1 changeset.

Please, post individual patches for each issue next time.

Thanks

Nicolas