Re: [hatari-devel] Hatari startup freeze regression with 030 MMU + EmuTOS + non-VDI screen

[ Thread Index | Date Index | More 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 later.)

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 [1] is used for screen, Hatari freezes.

For example:
$ hatari --tos etos512k.img --machine falcon --dsp none --memsize 4 --cpu-exact on --mmu on -m

[1] 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)


Mail converted by MHonArc 2.6.19+