|Re: [hatari-devel] Hatari startup freeze regression with 030 MMU + EmuTOS + non-VDI screen|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 30/05/2022 à 23:09, Nicolas Pomarède a écrit :
Le 30/05/2022 à 21:56, Eero Tamminen a écrit :
Everything was fine with TOS boot tester, until I started testing
EmuTOS with 030 MMU. That seems currently completely broken, Hatari
freezes at startup with 100% CPU usage.
There's no freeze with TOS v3 or v4, but with latest EmuTOS 1024k and
512k versions, Hatari freezes to black screen.
(With 0.9.x EmuTOS versions screen is white and freezes happens a bit
It does not matter whether TT or Falcon is emulated, or at what clock,
or what other options are used.
As long as 030 + MMU is enabled in cycle-exact mode, and something
else than VDI mode  is used for screen, Hatari freezes.
$ hatari --tos etos512k.img --machine falcon --dsp none --memsize 4
--cpu-exact on --mmu on -m
 maybe video interrupt emulation is now broken with cycle-accurate
030 MMU emulation?
I can see it too, I will have a look tomorrow I think.
this is now fixed ; I tested Falcon or TT in CE mode with or without MMU
and everything runs correctly now.
There was an error when updating cycles during the STOP state which
altered the internal timers in cycInt ; unlike WinUAE Hatari has 2
different cases to count cycles depending on whether the cpu runs in
cycle exact mode or not and the check for MMU was not correct there
(eventually this 2 ways of counting cycles (dating from old UAE core)
will go away one day to have more common logic with WinUAE)