I think I may have reported this before, but ran into it again today.
Hatari's WinUAE appears to be ignoring the 68881's precision and
rounding control bits.
These bits determine nearest or chop rounding, which are quite important
when trying to convert to/from fixedpoint values.
This causes small negative numbers (e.g. -0.0001) to round to zero when
the integer part is extracted, and when subtracted and scaled to extract
the fraction in fixed point form, it produces a negative value. This
generates an invalid fixedpoint value (integer & fraction differently
signed) in my code.
It can be worked around by using a carefully chosen bias during
conversion, and configuring round-to-nearest (which is what it seems to
be doing regardless of FPCR) but this wasteful, and only works for an
expected range anyway.
I guess this is a UAE thing not a Hatari thing, but it would be good if
somebody can check and decide if this can be fixed?