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

[Thorsten Otto <halgara@xxxxxxxx>]

The question is: is a cycle-exact mode for 68040/60 needed or even possible?

If i understand it right, cycle-exactness is needed only for demos/games that rely on a certain sequence  of instructions to run in a known amount of cpu-cycles, in order to mess with the video-address or to switch colors/resolution. Given that there haven't been that much real machines with 040/060, and the timing of this processors is quite different depending on cache modes/processor configuration/type of memory in use, are there really any programs out there that make use of it and actually work on real hardware? I would bet that such programs would break on each end every change in configuration.

Thomas Huth <th.huth@xxxxxx> schrieb am 22:58 Dienstag, 13.September 2016:

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