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

[ Thread Index | Date Index | More Archives ]

Le 21/05/2016 09:44, Thomas Huth a écrit :
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

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
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

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.


yes, thomas is right, instruction rounding to 4 cycles is the cause for this problem. In 68060, each instruction is assumed to take 1 cycle (this is not the real value, but it gives an approximation of the fact that the 68060 is much faster than 030/040), but then rounding takes place.

I have another work in progress branch of Hatari where I already changed this to not round to 4 cycles in such case (as well as various chnage regarding how faster clock is emulated), and still have working video emulation (many tests in video expect values to be multiple of 4).

No estimated date for this at the moment though, this still need some polishing.


Mail converted by MHonArc 2.6.19+