Re: [hatari-devel] Bug in Hatari 2.0

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 01/29/2018 08:37 AM, Thomas Huth wrote:
> On 28.01.2018 23:26, Eero Tamminen wrote:
[...]
> > > > 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.

Mega STE had 68000 with optional 68881/2 FPU.

I assume it was through line-F opcodes instead of being
memory mapped like 3rd party solutions...?


> We don't (and never did) support the MMIO FPUs in Hatari.

Yes.


> 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.

I'm not so sure dialog is a good idea, because FPU selection
might be there for Falcon & TT, so dialog is annoying if user
just temporarily runs ST.

I think it's better just to output console warning.

Attached is a patch doing that.  Although I think it's done after
CPU core is initialized, it makes the issue also to go away.


	- Eero

diff -r 047de3d63a27 src/tos.c
--- a/src/tos.c	Sun Jan 28 22:50:08 2018 +0200
+++ b/src/tos.c	Wed Jan 31 00:06:04 2018 +0200
@@ -625,6 +625,11 @@
 		TOS_CheckSysConfig();
 
 #if ENABLE_WINUAE_CPU
+	if (ConfigureParams.System.nCpuLevel < 2 && ConfigureParams.System.n_FPUType != FPU_NONE)
+	{
+		Log_Printf(LOG_WARN, "FPU is not supported in 68000/010 configurations, disabling FPU\n");
+		ConfigureParams.System.n_FPUType = FPU_NONE;
+	}
 	/* 32-bit addressing is supported only by CPU >= 68020, TOS v3, TOS v4 and EmuTOS */
 	if (ConfigureParams.System.nCpuLevel < 2 || (TosVersion < 0x0300 && !bIsEmuTOS))
 	{