Re: [hatari-devel] Bug in Hatari 2.0

[ Thread Index | Date Index | More Archives ]


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.


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 @@
+	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))

Mail converted by MHonArc 2.6.19+