Re: [hatari-devel] Bug in Hatari 2.0

[Thomas Huth <th.huth@xxxxxxxxx>]

On 28.01.2018 23:26, Eero Tamminen wrote:
> Hi,
> 
> On 01/28/2018 08:11 PM, Nicolas Pomarède wrote:
>> Le 28/01/2018 à 17:23, Thomas Huth a écrit :
>>> Thanks! With that config file, I can reproduce the crash even with the
>>> latest version from the Mercurial repo. Seems like the problem is when
>>> you specify an FPU together with the GEMDOS hard disk. I was able to
>>> reproduce it with this minimal config file, too:
>>>
>>> [HardDisk]
>>> bUseHardDiskDirectory = TRUE
>>> szHardDiskDirectory = /tmp/hatari/gemdos.drv
>>>
>>> [ROM]
>>> szTosImageFileName = /tmp/hatari/etos512k.img
>>>
>>> [System]
>>> n_FPUType = 68882
>>>
>>> The "n_FPUType = 68882" seems to trigger a re-initialization of the CPU
>>> tables (even though it likely should not do that) as soon as you press
>>> the OK button in the GUI. I guess that somehow kills the special
>>> GEMDOS HD opcodes of Hatari, so that you finally run into a crash.
>>> Unfortunately, I currently don't have much time for further debugging
>>> (for the next 1.5 weeks) ... so either somebody else needs to have a
>>> closer look or this has to wait a little bit.
>>
>> when I try this with my config, it just prints :
>> FPU is not supported in 68000/010 configurations.
> 
> After this message, our WinUAE CPU core code forces FPU model to zero.
> 
> This looks like long standing bug in our WinUAE CPU core, which has
> been there at least since WinUAE 2.3 code import.
> 
> One can install FPU to ST and I'm pretty sure Hatari has supported
> ST+FPU configurations earlier, at least with oldUAE CPU core.  Thomas

No, FPU can not work in 68000 mode, since it needs Line-F. We don't (and
never did) support the MMIO FPUs in Hatari.

With the old UAE core, your only option was to select 68020+FPU, i.e.
there even was not a separate FPU configuration available.

>> Does this need a specific CPU or machine type to see the problem ?
> 
> Yes, the one with which you got that warning (68000/010).
> 
> As Roger stated, you need to press F12 & Enter, after which
> you will see just illegal instructions.  Happens also with
> normal TOS.
> 
> Attached patch makes that issue go away, but I didn't test
> whether FPU emulation actually works properly with ST emulation.

That's the wrong way. We should rather tell the user with a dialog that
FPU is not possible, and force the ConfigureParams to FPU_NONE.

 Thomas