Betatesting SoftIEEE FPU emulator

[Thomas Richter]

Originally Posted by amifan

Has anyone tried this with a TF1260 LC and Lightwave 3.5 FPU version? I followed the instructions for installation but get a guru error when running Lightwave. Not sure what to do next.

I suggest following the instructions in the beginning of this thread would help. Install MuForce, Sashimi, run MuForce as such:

 MuForce RAWIO DISPC STACKLINES=32

before starting lightwave, then start Sashimi, then right Lightwave, and then report its output here. What else?

[shelter]

Originally Posted by mfilos

I'm under the impression that you need to disabled FPU before running ShapeShifter as it uses a SoftFPU as well.

At least in my Vampire, I disable it before running it via a script.

I'm not so sure? There's an SoftFPU extension you can install in MacOS, I don't run that.

If test and enable FPU in WinUAE, Shapehifter starts fine and boots MacOS...
Since I don't have an FPU on my real Amiga I have to test it in WinUAE.

With no FPU, using SoftIEEE, Shapeshifter starts but MacOS crashes, both in WinUAE and on my real Amiga.
I tried running MUForce for some sort of output but it just freezes everything.

With that being said, Shapeshifter isn't exactly bug free itself.

[Thomas Richter]

That is expected. MacOs likely patches the line-F vector itself, so SoftIEEE is "out". This is not even ShapeShifter.

[shelter]

I guess there's no way to remove SoftIEEE on the fly, once it's loaded, it can't be disabled?

[Thomas Richter]

No, simply because the (emulated) FPU got enabled, and hence programs expecting the FPU to work could have been loaded in the mean time. If you now disable it, programs that are currently running and attempt to use the FPU would simply crash.

[Thomas Richter]

Originally Posted by amifan

Has anyone tried this with a TF1260 LC and Lightwave 3.5 FPU version? I followed the instructions for installation but get a guru error when running Lightwave. Not sure what to do next.

Ping! Please react.

[amifan]

Sorry, I have not had a chance to access my Amiga the last few days, I will try this weekend

[shelter]

I tested it on the TF1230 and Lightwave 3.5 FPU version ran fine. Slow ofcourse, but it did run.
So it got to be a TF1260 specific problem or an installation issue.

[braunaudio]

Found an interesting quirk of the software.

I've been using it on an A4k-TX with an LC68060 fitted to an A3660 (speed geek gals), and running the software from the startup-sequence.

What I've now found is that this will cause the machine to hang on a black screen when a reset is initiated (either by the reset pins on the MB, or by Ctrl-Amiga-Amiga).

What threw me, was that it seemed to somehow stay in effect after power down, and even with the boot drive removed it wouldn't do a reset from the KS splash screen.

Will try an replicate this within WinUAE shortly.

[Thomas Richter]

SoftIEEE has no reset-resident parts in it, none whatsoever. So whatever you see is not caused by SoftIEEE.

[SpeedGeek]

Originally Posted by braunaudio

Found an interesting quirk of the software.

I've been using it on an A4k-TX with an LC68060 fitted to an A3660 (speed geek gals), and running the software from the startup-sequence.

What I've now found is that this will cause the machine to hang on a black screen when a reset is initiated (either by the reset pins on the MB, or by Ctrl-Amiga-Amiga).

What threw me, was that it seemed to somehow stay in effect after power down, and even with the boot drive removed it wouldn't do a reset from the KS splash screen.

Will try an replicate this within WinUAE shortly.

I'm not sure exactly what an A4k-TX is but the A4000T needs the extra wait state feature described in the documentation. A4000T users are lucky if they can even get an occasional boot without it.

Also, WinUAE can probably emulate the NCRscsi.device hardware but not the timing problem it causes on the A4000T.

P.S. A3660 overclocking will probably fail with the A4000T.

EDIT: The A4k-TX is not an A4000T.

[braunaudio]

Originally Posted by Thomas Richter

SoftIEEE has no reset-resident parts in it, none whatsoever. So whatever you see is not caused by SoftIEEE.

Completely what I expected, and yesterday when I was troubleshooting, the simple act of removing the call brought back the ability to carry out warm resets with KS3.2.1.

Today however is a different story as they are now gone again.

@speedgeek, the A4k-TX is the motherboard designed by Hese around an EATX form factor (based upon the A4000CR)

[RDP]

Is this the current thread for this software?

1. SysSpeed freezes machine when it tried to benchmark FPU. System freezes so hard I cannot even CTRL-A-A to reset, must use power button.
2. AIBB crashes on examining system.

Are these expected not to work?


thanks!
RDP

[Thomas Richter]

Originally Posted by RDP

Is this the current thread for this software?

Yes.

Originally Posted by RDP

1. SysSpeed freezes machine when it tried to benchmark FPU. System freezes so hard I cannot even CTRL-A-A to reset, must use power button.
2. AIBB crashes on examining system.

Are these expected not to work?

They are expected to work, and actually did work on my end as far as I remember. Ensure that there are no other "software improvements" patching the CPU exception vectors. In case of doubt, run SoftIEEE directly upfront running these benchmark programs.

[RDP]

I think AIBB is causing me general problems, so have removed it from testing. Currently just looking at SysSpeed.

Only fun stuff in my SS and US is MuProtectModules and MuFastRom, everything else quite standard.

I took softieee out of the SS, and ran it just before SysSpeed. It froze in the same manner.

When testing FP actual usage I use LightWave 5.0. I notice when starting up and in use my mouse becomes very very jerky in the movements, and everything is just crazy crazy slow, probably slower than it should be?

I recall some years back using a library that I think you created that would stop programs from hard crashing when trying to access the FP by having the same jerky mouse outcome? I wonder if that library might be the issue? I need to search for that thread! UPDATE: Found it: https://eab.abime.net/showthread.php?t=107530 . Even with my update to 3.2 from 3.1.4 maybe I have a residual library causing issues? Just a guess!

Happy to try a FP program that you know 100% should work.

Sysinfo: I saw someone post on the previous page their MFlops rate from Sysinfo. Around 0.91. Mine is 0.00! At least it does not crash the system! Installed MuReDox and now get 0.02.


thanks!
RDP

[RDP]

I bit of an update: Installing latest MMULibs (might have been already!), and MuReDox has fixed the jumpy/slow mouse issue in Lightwave!

thanks,
RDP

[Thomas Richter]

Great that you found it - I was too late in responding. The reason for the jerkiness is that the FPU emulation is compute-intensive and operates entirely in the exception processing of the CPU which blocks other tasks from execution. MuRedox performs an online patching of executables such that emulation runs in user mode, and the exception overhead is avoided. It is of course still slow.

I believe AIBB has some problems with the 68060 in general, but maybe there was a patched version somewhere. However, please do not expect high speed - the emulation is of course quite slow.