[hatari-devel] Cycle exact 68040/68060 mode in Hatari

[Thomas Huth <th.huth@xxxxxx>]

 Hi Nicolas, hi Toni,

I've run into an issue with the CPU core where I'm quite unsure about
the right way to fix it ... maybe you can help?

Since Nicolas recently merged the latest changes from WinUAE into
Hatari, and improved the CPU frequency <-> cycles handling, I wanted to
give the cycle exact 68040/68060 mode another try.

First, we need the following two patches in Hatari to get it running at
all:

diff -r e79424af8fd8 src/cpu/custom.c
--- a/src/cpu/custom.c  Mon Sep 12 18:11:19 2016 +0200
+++ b/src/cpu/custom.c  Tue Sep 13 22:36:53 2016 +0200
@@ -455,11 +455,6 @@
        if (p->cpu_model >= 68040 && p->cachesize && p->cpu_compatible)
                p->cpu_compatible = false;
 
-       if (p->cpu_model >= 68040 && p->cpu_cycle_exact) {
-               p->cpu_cycle_exact = 0;
-               error_log (_T("68040/060 cycle-exact is not supported."));
-       
-
        if ((p->cpu_model < 68030 || p->cachesize) && p->mmu_model) {
                error_log (_T("MMU emulation requires 68030/040/060 and it is not JIT compatible."));
                p->mmu_model = 0;
diff -r e79424af8fd8 src/cpu/newcpu.c
--- a/src/cpu/newcpu.c  Mon Sep 12 18:11:19 2016 +0200
+++ b/src/cpu/newcpu.c  Tue Sep 13 22:36:53 2016 +0200
@@ -5641,6 +5641,7 @@
                                        LOG_TRACE_PRINT ( "cpu video_cyc=%6d %3d@%3d : " , FrameCycles, LineCycles, HblCounterVideo )
                                        m68k_disasm_file(stderr, m68k_getpc (), NULL, 1);
                                }
+                               currcycle = 0;
 #endif
                                r->instruction_pc = m68k_getpc();
                                r->opcode = get_iword_cache_040(0);


But after enabling the code this way, the cycles still look very wrong.
Many instructions do not take any cycles at all, currcycle stays 0
quite often.

After looking into cpuemu_24.c, I do see any calls to
do_cycles_ce020_internal() or a similar do_cycles...() function in there.
Looks like this is due to addcycles_ce020 (int cycles, const char *s)
which is returning immediately if isce020() returns false.
And isce020() returns false because of this:

	if (using_ce020 >= 3)
		return false;

Why is this code there? I have a hard time to understand the reason for
these two lines... don't we want to have a do_cycles_ce020_internal()
in cycle-excact 68040/060 mode?

Thanks for any help,
 Thomas