Re: [hatari-devel] Correct cycles values?

[ Thread Index | Date Index | More Archives ]

Le 14/03/2013 11:01, Eero Tamminen a écrit :

Shouldn't the cycles shown in profile disassembly then be:
	cycles<<  nCpuFreqShift

Yes, if you want to display cycles in a human readable way,
nCpuFreqShift should betaken into account.

static inline void M68000_AddCycles(int cycles)
          cycles = (cycles + 3)&  ~3;
          cycles = cycles>>  nCpuFreqShift;

Ok, that can explain some of the emulation inaccuracy.

Shouldn't that function do rounding to closest shifted value to get
better accuracy, instead of rounding-up to next 4-divisable value:

No, the 4 cycles rounding is necessary on STF/STE where (nearly) all bus accesses are rounded to 4 cycles. They're some exceptions, such as instruction pairing, but the main rule is first to round motorola cycles to the next 4 cycles mutiple.

I can't tell for the falcon, I don't know if bus access are limited to 4 cycles too.

Are all of the values involved:
- cycles arg
- nWaitStateCycles
- BlitterVars.op_cycles
- CurrentInstrCycles+nWaitStateCycles

Such that they need to be shifted?

Yes, STF/STE blitter expects to run at the same speed at the 68000 on a 8 MHz bus. So same rules must apply if you want to keep cpu and blitter in synch when you emulate a 16 or 32 MHz CPU, then you also need to dividie blitter's cycles.

This kind of shifting was nowhere else (acia.c shifted in other direction).

That's intended too. All those shifting are correct, they're mostly hacks because it's much easier to have a common base freq of 8 MHz and divide cycles by 2 or 4 than to be emulate x2 or x4 more cpu instruction during the same loop, while still emulating the same number of MFP, FDC, ACIA, ... events


Mail converted by MHonArc 2.6.19+