Re: [hatari-devel] New WinUAE core issue with Bad Mood?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 04 joulukuu 2014, Nicolas Pomarède wrote:
> I'm currently merging with 2.9 beta 25, which represents quite a lot of
> changes since 3 months and a lot of conflicts while merging to resolve
> manually (for example, WinUAE added support for PPC emulation, as some
> Amiga's extension boards were released with PowerPC CPU ; this has no
> use for Hatari, but it makes the merging less straight forward)
> 
> Hopefully, I should have a working version soon to test, including the
> latest MMU fixes (in cases it helps with bad mood)
> 
> So, don't spend too much time looking for source of the problems, maybe
> the next version will resolve some of them. Else, some deeper analysis
> will be needed.

Some additional issues I noticed:

- EmuTOS 512k doesn't boot up in TT or Falcon mode, it just endlessly
  bus errors.


As to profiling, it works in ST, STE & TT mode, but asserts in Falcon mode.

It asserts also if I run:
  hatari --machine falcon --tos tos206uk.img

And do profiling after Hatari complains that TOS doesn't support
given machine type & Hatari switches to STE mode.  However, if
I start directly with:
  hatari --machine ste --tos tos206uk.img

Profiling works fine.


When I did cross-checking with previous WinUAE CPU core
(from end of September), the behavior differed:
- EmuTOS boots fine also in TT & Falcon mode
- Profiling works fine also in Falcon mode

But switching from Falcon to STE on boot still causes problems
for profiling.   I.e. there's some bug in Falcon -> STE
machine type switching with WinUAE core.


As to the cycles information provided to the profiler with
previously available methods, that information seems to be
now completely bogus for TT & Falcon.  Values are never sane,
either zeros or in millions, depending on where the profiler
takes them.

This is the profiler code for getting the cycles:
--------- profilecpu.c ------------
/* This is relevant with WinUAE CPU core:
 * - the default cycle exact variant needs this define to be non-zero
 * - non-cycle exact and MMU variants need this define to be 0
 *   for cycle counts to make any sense
 */
#define USE_CYCLES_COUNTER 1
....
#if USE_CYCLES_COUNTER
        /* Confusingly, with DSP enabled, cycle counter is for this
         * instruction, without DSP enabled, it's a monotonically
         * increasing counter.
         */
        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;
        }
#else
        cycles = CurrentInstrCycles + nWaitStateCycles;
#endif
------------------------------------

You can get debugging info for the values by setting
DEBUG define in profilecpu.c.


	- Eero