Re: [hatari-devel] Correct cycles values?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 14 maaliskuu 2013, Nicolas Pomarède wrote:
> On 14/03/2013 10:10, Eero Tamminen wrote:
>> On torstai 14 maaliskuu 2013, Nicolas Pomarède wrote:
>>> For now, MachineClocks.CPU_Freq is not really used, it's just
>>> informative. You also need to check if cpu freq is 8,16 or 32 (using
>>> the >> operator to divide cycles by 2 or 4). No clean solution for now,
>>> it can be solved latter as it doesn't impact emulation itself. Add a
>>> special case for the TT if you need in your code.
>> 
>> Do you mean that CPU cycles are always counted using 8Mhz clock,
>> not the one at which the CPU is running at?
> 
> Yes, in a all cores/all cpu, cpu freq is always assumed to be 8 MHz
> (this is required to keep a constant ratio with other component like
> FDC, ACIA, ...).
> The effective 16 or 32 MHz freq is obtained by dividing each
> instruction's cycles by 2 or 4 :

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


> 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:
	if (nCpuFreqShift) {
		int mask = (1 << nCpuFreqShift) - 1;
		int half = 1 << (nCpuFreqShift - 1);
		cycles = (cycles + half + 1) & ~mask;
		cycles = cycles >> nCpuFreqShift;
	}
?


Btw. I noticed this in blitter.c:
----------------------------------
static void Blitter_AddCycles(int cycles)
{
        int all_cycles = cycles + nWaitStateCycles;

        BlitterVars.op_cycles += all_cycles;

        nCyclesMainCounter += all_cycles >> nCpuFreqShift;
        nWaitStateCycles = 0;
}
....
void Blitter_Control_WriteByte(void)
{
....
                        /* Start blitting after some CPU cycles */
                        CycInt_AddRelativeInterrupt((CurrentInstrCycles+nWaitStateCycles)>>nCpuFreqShift,
                                                         INT_CPU_CYCLE, 
INTERRUPT_BLITTER);
----------------------------------

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

Such that they need to be shifted?


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


	- Eero