| Re: [hatari-devel] Correct cycles values? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel 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
Nicolas