exxos's Atari, Amiga & retro forum

Badwolf wrote: 28 Jun 2022 13:47 If only we knew someone a dab hand with a bit of assembly, eh, @agranlund?

So.. I couldn't resist :lol:

Here's a software FPU emulator for Atari:
http://www.happydaze.se/wp-content/uplo ... /fpemu.zip

It's impressively slow and I have no idea how accurate it is.
The core is lifted from NetBSD, with a bunch of modifications to make it work on TOS.
Should work on 68000 up to 68030 for now. I'll need to add some additional code for 68040+ stack frames

Anyone have any good suggestions for programs I could test this thing with?


My Atari gets a score of 1% compared to a TT with real FPU :lol:


You're not really going to want to be running things that makes heavy use of an FPU but I think it can still be useful for easier stuff?
Especially considering most things compiled for 68020-60 and against Mintlib requires an FPU no matter if the program actually use it or not..



And nope, it doesn't work with BasiliskII.
Or rather, the original TOS LineF handler is only active in the TOS context of the emulator and not in the Mac one.
I'll figure something out eventually, either have it detect the presence of FPU emulators or just build it right into Basilisk..

I just found out about that XBRA protocol you are supposed to use when overriding system vectors.. better late than never I suppose :)
I've updated the FPU emulator to do so.

Kronos runs fine with the software FPU.
That OpenGL test looks correct but we're talking frames-per-minute rather than frames-per-second :lol:


I have an old and unfinished WIP version that's using the Linux soft-fpu core too.
Now that I figured out how to hook it all up and make it work for supervisor mode, I'm tempted to finish that one too and see if it's a tiny bit faster or not - The NetBSD one is almost all C while the Linux one is almost 100% asm.
The main difference would be that the Linux one falls under GPL license instead of BSD, if that makes a difference to anyone.

Very awesome! Extremely useful for MiNT users who have machines without an FPU! Thank you!!

Steve wrote: 10 Jul 2022 11:29 Very awesome! Extremely useful for MiNT users who have machines without an FPU! Thank you!!

Yeah, I'm one of those users and I got fed up with the "This program requires a 68881" for stuff that really doesn't use floats much or at all :D

Apparently TOS 1.xx is using LineF for non-fpu stuff.. so for now, it wont work on that old TOS.
I wouldn't really expect anyone using TOS1 to have a use case for a software FPU but you know, for the purpose of completion I'm going to have to add a special codepath to support it.

Bah, go back to MiNT 1.10, early Mintlibs and gcc 2.7.2 and you don't have to worry about all the broken things added in the last 30 years. :-)

Takes less memory and runs faster too.

agranlund wrote: 10 Jul 2022 11:34 Apparently TOS 1.xx is using LineF for non-fpu stuff.. so for now, it wont work on that old TOS.

Yes, that's true, up to 1.04, AES & desktop abuse the LineF handler to shorten some function calls. But that's no big deal, TOS <= 1.04 doesn't support 68020+ anyway,.

I wouldn't really expect anyone using TOS1 to have a use case for a software FPU but you know

That simply won't work. Software using Line-F opcodes for math ops most likely will also use some 68020+ addressing modes, and simply crash on plain 68000.

Setup: MegaST4, TF536, TOS 2.06, MiNT

The Emu need still work ...

frank.lukas wrote: 10 Jul 2022 13:19 Setup: MegaST4, TF536, TOS 2.06, MiNT

The Emu need still work ...

XAAES_SYS.jpg

Yeah there seems to be two problems here:
1)
I had been testing in a setup that had MiNT SECURELEVEL 0 but I see now that it doesn't seem to work if you set it to 1 or 2.
(fpemu.prg gets killed by mint)
This I can investigate and see if I can fix somehow.

2)
Xaaes probably isn't dynamically updating the FPU status in the System Window?
If that window would check the _FPU cookie, or try to hardware detect it, each time it was opened then it would show the FPU correctly but I guess it doesn't.
I assume Xaaes probably checks for FPU on startup and stores that info to be forever displayed in the info window (which makes sense since you can't really hotplug an FPU)

This I probably can't do anything about.

Gembench, Kronos, and so on should show the presence of an 68881 if everything works though.

I posted this thread to the freemint mailing list so probably @mikro might chime in with freemint specific peculiars. Either way it doesn't really matter if the xaaes reports show an FPU or not, as long as console programs that check for an FPU work that's the main thing.

CPUFPU Program also doesn't show the FPU just like MiNT/XaAES do ...