Re: [hatari-devel] WinUAE core freeze with ST emulation

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 31 toukokuu 2012, Eero Tamminen wrote:
> > Also, I don't like the idea of renaming that option from "compatible
> > cpu" to "prefetch cpu" because of
> > a) it's also named "cpu_compatible" in the WinUAE core
> > b) it's not only about enabling prefetch in the CPU core, but also some
> > 
> >    other things if I remember clearly (e.g. address error emulation).
> > 
> > So could you please keep the old name?
> 
> The reason why I added it was that at least earlier, unlike with old UAE
> core, it needed to be disabled for ST/E emulation to boot under WinUAE.
> I.e. it conflicted with old UAE settings.
> 
> I probably should run TOS tester again to see whether ST booting
> works now properly without disabling it.

Using current Hatari defaults, without my WinUAE patch:

* TOS v1.00 and TOS 4.x work

* TOS v3.x always fails with illegal instructions unless
  "--fpu-type 68882" is used

* TOS v1.02 - v2.06 and EmuTOS/ST freeze Hatari right at startup when
  VDI or GEMDOS mode is used, unless one specifies "--compatible no"
  option.  Without VDI nor GEMDOS mode, they boot also without that.


TOS 3.x / FPU needs to be set when Falcon/TT or their TOS is selected,
and doing that will be fine.


However, Hatari freezing isn't acceptable, so the "compatible" option
needs to be toggled for WinUAE.  But it messing up with old UAE options
isn't acceptable either.   I think this is release blocker.

There are two alternatives:
* Fix WinUAE core for 68000 enought that it doesn't freeze Hatari, or
* Use separate option for WinUAE prefetch stuff like my patch does.


> If it does, I guess then everything else except setting Falcon
> as default will be redundant from that patch...

Well, FPU setting is at least needed too...


	- Eero