Re: [hatari-devel] Many changes to MFP

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 14 maaliskuu 2013, Nicolas Pomarède wrote:
> On 12/03/2013 13:11, Eero Tamminen wrote:
> > On tiistai 12 maaliskuu 2013, Nicolas Pomarède wrote:
> >> Well, in fact I also see the bug too :(
> >> 
> >> I think it's related to the latest changes I made to improve "Decade
> >> Demo - Reset part", I forgot to complete timer C/D to pass the number
> >> of delayed cycles.
> >> 
> >> I you try with rev 4373, I think rasters should be stable.
> > 
> > Yes, with that they work.
> > 
> OK, this is now fixed for good (it seems the TODO comment I left in
> mfp.c was for a good reason :) )

Verified.


Btw. As you mentioned cycles counter, this reminded me of timing
different TOS versions startup times with the profiler couple of
days ago.

For everything else profiler gave fairly sane looking TOS bootup times
based on the (old UAE core) cycles counts, but for TT, the time was
less than half of the actual time (a bit less than 2s).

I'm counting the time as: <spent cycles> / MachineClocks.CPU_Freq.

Spent cycles are counted with:
        if (bDspEnabled) {
                cycles = Cycles_GetCounter(CYCLES_COUNTER_CPU);
        } else {
                Uint32 newcycles = Cycles_GetCounter(CYCLES_COUNTER_CPU);
                cycles = newcycles - cpu_profile.prev_cycles;
                cpu_profile.prev_cycles = newcycles;
        }


Any idea why that could be so wrong for TT emulation?


	- Eero

PS. why the cycles counters are ints, instead of unsigned?