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.

[t-bone]

@Thomas Richter
SoftIEEE is a really exciting project. I am planning to upgrade my A1200 from a Blizzard 1230IV and 68882 FPU with something faster like a 060 card or an even Vampire v2 card.
So my questions are:
1. How good, bad or accurate in precision is the FPU implementation on a Vampire
v2 compared to a full 68060 and a real FPU?
2. Can I use e.g. FPU version of MaxonCinema 4D on a Vampire direct or will
I need your SoftIEEE to make it work?
3. I have heard the Vampire card does have some sort of MMU on it,
but virtual memory tools like VMM on Aminet surely won't recognize it
like a an MMU e.g. on a 68030.
Is there a way to create a program to re-route/translate instructions to
MC68k MMU or FPU to those used or expected by a Vampire's so-called
68080 CPU?
Then a Vampire FPU or MMU would be recognized as genuine MC68K MMU
or FPU respectively by any Amiga software using then. Thus, rather simple
conversion of instructiions into a different syntax for Vampire core rather than having
to emulate them all or entirely.

[Thomas Richter]

Originally Posted by t-bone

1. How good, bad or accurate in precision is the FPU implementation on a Vampire
v2 compared to a full 68060 and a real FPU?

You better ask Gunnar before he again attempts to threaten me. From what I know, the vampire has a double-precision FPU (56 bits), which likely has the consequence that the transcendental functions that are emulated by a "mini-code" in software have less precision (you need some extra bits for rounding), so I would guess approximately 48 to 40 bits precision. In worst case, probably single precision for them.



A 68881/68882 FPU or the full FPU of a motorola can do 80 bits for elementary operations, and for the transcendental functions you get about double precision (or a bit more than that), so again you loose some bits


SoftIEEE operates internally even with 96bits (it was easier than 80 bits), so you get 80 bits extended precision from almost anything. Transcendental functions may lack one or two last bits.

Originally Posted by t-bone

2. Can I use e.g. FPU version of MaxonCinema 4D on a Vampire direct or will
I need your SoftIEEE to make it work?

SoftIEEE is *not* for the vampire. It requires the exception mechanism of the real Motorola chips. The vampire does have a FPU, albeit one with some restrictions in terms of precision. I do not know whether it can run entirely in emulation, and if it does, whether its exception mechanism is compatible to any of the CPU models. Likely not.

Originally Posted by t-bone

3. I have heard the Vampire card does have some sort of MMU on it,
but virtual memory tools like VMM on Aminet surely won't recognize it
like a an MMU e.g. on a 68030.

Again, ask Gunnar for the latest marketing name of this unit. I would not call it a MMU, and it is seriously cut down - it cannot do memory remapping. From what I know, it can control caching on a page size of several K (I forgot its granularity) and access control on a another page size (was it 4K?). This is quite unorthogonal (two different page sizes), and it is by no means compatible to the real MMU. It is in terms of features somewhere between the transparent control registers of the EC CPUs and the MMU of the full CPUs, but too limited for virtual memory or the mmu.library.

Originally Posted by t-bone

Is there a way to create a program to re-route/translate instructions to
MC68k MMU or FPU to those used or expected by a Vampire's so-called
68080 CPU?

That would have been a good design, but from what I know, you cannot. Again, this is not the vampire thread, and I'm not an expert on it.

Originally Posted by t-bone

Then a Vampire FPU or MMU would be recognized as genuine MC68K MMU
or FPU respectively by any Amiga software using then. Thus, rather simple
conversion of instructiions into a different syntax for Vampire core rather than having
to emulate them all or entirely.

That was my original design suggestion to Gunnar (that is, to have some kind of software emulation available to cut down the hardware complexity in order to squeeze it into an FPGA), but no. Again, I'm not the right person to ask, but the main issue with the MMU is likely that it sits in a critical path from CPU core to RAM interface where it would limit the maximal clock frequency of the entire design.

[Karlos]

@Thor

I appreciate this is not the intention of the project but....

How feasible is it to extract the the IEEE code into a library that simply provides regular functions for performing the operations on floats and doubles, without all the trap emulation? Something like the mathieee#? libraries (or a replacement). In the first instance someone would need to call the functions directly to perform arithmetic but it I can imagine updating a compiler to support a softieee FPU target, so that you can just compile code directly for it.

Apologies if that's already been discussed, I'm a bit out of the loop.