Re: [hatari-devel] UAE 68030 MMU + prefetch + instruction and data cache emulation

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


Hi,

Tested with hatari 2.0.0, MMU on, cycle exact and prefetch mode ON, 14 Mo, Tos 4.04 FR, 24 bits mode addressind ON, no Patch timer_D, no boot faster by patching TOS...

I've removed my hatari.cfg before testing.


   X_tasie works well with 2.0.0 and MMU activated.

_ (underscore) demo runs well too (until the 4th screen, but that's another problem.


With the latest source, both demos freeze (probably because of cpu <-> dsp timings as I can see when I debug).


To be noticed : these 2 demos runs only in MMU mode.

There's certainly a regression in the current version and MMU.

Regards
Laurent



Le 30/07/2017 à 13:19, Nicolas Pomarède a écrit :
Le 30/07/2017 à 12:53, Laurent Sallafranque a écrit :
Hi,

A few tests done with the new core :

- rainbow 2 (use the MMU) : OK
- X_tasie demo (runs with MMU) : KO (probably because of CPU timings, as it's locked between DSP and CPU exchanges) - _ demo : it seems to have regressed (both 68030 and non 68030 cpu). Before, it was running at least the 3 first screens before freezing, but now it freezes at start.

- a few more demo tested, that are working, (they probably don't use the MMU). But with the 2 cycles instructions timings, they look strange, or music is full of glitches, ...

I'll do some more tests.

The best now for hatari would be to have 68030 + MMU + cycle exact (nevermind if the MMU instructions are not cycle exact, there's never involved in time critic loops).

That's the Falcon standard CPU.

Thanks for the new CPU Tony and Nicolas.


hi

thanks for the tests ; for those that don't work, did they work with Hatari 2.0 and the same settings ? It's important to know if regression is due to latest MMU changes or if it was already wrong before.

Nicolas





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