[hatari-devel] Re: [Emutos-devel] Slow startup with Hatari 68060

[Thomas Huth <th.huth@xxxxxx>]

Am Fri, 20 May 2016 19:51:39 -0400
schrieb "Roger Burrows" <anodyne@xxxxxxxxxxxx>:

> On 21 May 2016 at 0:06, Vincent Rivière wrote:
> > 
> > Just tested with Hatari:
> > - usually, cold boot until welcome screen takes about 1 second
> > - but with a 68060 CPU at 8 MHz, it takes 12 seconds!
> > 
> > The same happens since EmuTOS 0.9.0, but worked fast with EmuTOS
> > 0.8.7.
> > 
> > When doing AltGr+Pause to enter the debugger, we can see that
> > EmuTOS is stuck in _run_calibration, more precisely in cal_loop.
> > 
> > I don't think this is acceptable.
> > We should at least investigate that before the release.
> > This does not seem to be acceptable.
> > 
> > Maybe my testcase is invalid because LOOPS_68060 assumes a 110 MHz
> > CPU? 
> If my original calculations were correct, I think the cycle times of
> the emulated 68060 are probably not correct.  My target time for the
> calibration loop to run is 100 milliseconds for a 110MHz system; an
> 8MHz system shouldn't take more than about 1.4 seconds.
> 
> Let's look at your results:
> The calibration code runs 100 outer loops, so if it is taking 11
> seconds to do that, each outer loop takes 0.11 secs or 110000
> microseconds.  Each inner loop is executed 110000 times, so each
> iteration is 1 microsecond.  At 8MHz, this means it's taking 8 cycles
> to do a subq/bpl; it should take 1 (the subq and bpl are completely
> overlapped in the 68060).

I think your calculation is right. You can also see this in the
debugger of Hatari, turn on "trace cpu_disasm" and continue running the
emulation for some instructions (e.g. "c 100"):

cpu video_cyc=   508   0@  1 : 00E00DFC 5380    SUB.L #$00000001,D0
cpu video_cyc=   512   4@  1 : 00E00DFE 6afc    BPL.B #$fffffffc == $00e00dfc (T)
cpu video_cyc=   516   8@  1 : 00E00DFC 5380    SUB.L #$00000001,D0
cpu video_cyc=   520  12@  1 : 00E00DFE 6afc    BPL.B #$fffffffc == $00e00dfc (T)

As you can see, the cycle counter is increased by 4 cycles for each
instruction.

That's simply because Hatari currently assumes that each instruction
takes a multiple of 4 cycles, see M68000_AddCycles() in m68000.h. This
is of course only true on normal STs, with plain 68000 CPUs, but that's
where the code in Hatari originally comes from (in the beginning, there
was only ST emulation), and unfortunately we're still somewhat stuck
with that code today. For example this assumption is currently also
still needed for the 16 MHz and 32 MHz emulation in Hatari, since the
cycles are simply divided by 2 or 4 in M68000_AddCycles() for these
frequencies. That of course would not work anymore if the cycle value
is less than 4. We need to fix that one day (also for supporting higher
frequencies than 32 MHz), but currently we're not there yet.

 Thomas