So I installed a 68881 FPU into my Mega STe along with the corresponding GAL and
things are mostly fine. Sysinfo says it's there, after running the FPU emulator, FPUTEST
says it passes, but Gembench 6 says "I+O FPU not supported".
Not sure what that means exactly? I know the implementation of the FPU on the Mega
STe is different than the TT and Falcon. (we're back to Line F stuff, right?)
Is that what it's reporting?
Thanks.
I+O FPU not supported?
Moderator: troed
I+O FPU not supported?
Welcome To DarkForce! www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
Re: I+O FPU not supported?
Read the readme
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
-
- Moderator Team
- Posts: 5389
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: I+O FPU not supported?
IO mapped FPUs are evil. They need you to implement the 020/030 coprocessor interface protocol in software. Ouch yeah.NO IO MAPPED FPU ASM CODE for MSTE & STFM - simply not supported.
IO mapped FPU works different than the FPU on the 030 CPU with Falcon etc. So 2 FPU tests would need to be programmed and wouldn't have any correlation to each other anyway.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
Re: I+O FPU not supported?
Okay, gotcha. Thanks guys!
Welcome To DarkForce! www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
- frank.lukas
- Posts: 664
- Joined: Fri Jan 19, 2018 11:52 am
Re: I+O FPU not supported?
Use GemBench 4.03 ...
Re: I+O FPU not supported?
Ah.... Thanks Frank.
Welcome To DarkForce! www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 1040
-
- Posts: 117
- Joined: Fri Dec 27, 2019 9:01 pm
Re: I+O FPU not supported?
Just for reference: I lately checked a 16 MHz Falcon 030 vs. a 16 MHz MSTe using a software LineF emulation. Both switched to a 68881. Using a Fractal (control panel) test program, the speed difference between the hw LineF implementation of the 68030 and the software emulation on the 68k was about 5x in this test, slightly fluctuating with the fractal parameters (due to the constant overhead the LineF software emulation creates).terriblefire wrote: ↑Wed Jun 02, 2021 8:11 amIO mapped FPUs are evil. They need you to implement the 020/030 coprocessor interface protocol in software. Ouch yeah.NO IO MAPPED FPU ASM CODE for MSTE & STFM - simply not supported.
IO mapped FPU works different than the FPU on the 030 CPU with Falcon etc. So 2 FPU tests would need to be programmed and wouldn't have any correlation to each other anyway.
Granted it was only one test (GB 6 still ignored the LineF emulation, telling me that there was no FPU to test, while GB 4 still seemed to use the IO addr directly to execute its FPU test), but it should give an idea of what to expect speedwise on the 68k and how high the overhead is.
Re: I+O FPU not supported?
GB6 doesn't support IO mapped. Simply because the results from GB4 were massively different between IO Mapped and LINE F. The comparison was meaningless.
But as @terriblefire, the overhead is all in software with IO mapped. So you're really only benchmarking RAM speed more than the FPU. Aside from that, almost nothing really uses the LINE F FPU, IO mapped, never heard of any software for it.
If people are *really* that bothered about missing IO mapped FPU tests, then create me a lib I can interface to and I can add it to GB6, but even so, the bulk of the overhead will be simply ram speed because of the instructions overhead. Plus you still cannot really be compared to a LINE F FPU the 030 CPU can access it at full speed without software emulation. So it will always be inherently many times faster than IO mapped. Caches will also increase speed because of faster "RAM loops".
GB6 IIRC looks for the FPU to be registered correctly with cookies.
But as @terriblefire, the overhead is all in software with IO mapped. So you're really only benchmarking RAM speed more than the FPU. Aside from that, almost nothing really uses the LINE F FPU, IO mapped, never heard of any software for it.
If people are *really* that bothered about missing IO mapped FPU tests, then create me a lib I can interface to and I can add it to GB6, but even so, the bulk of the overhead will be simply ram speed because of the instructions overhead. Plus you still cannot really be compared to a LINE F FPU the 030 CPU can access it at full speed without software emulation. So it will always be inherently many times faster than IO mapped. Caches will also increase speed because of faster "RAM loops".
GB6 IIRC looks for the FPU to be registered correctly with cookies.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
-
- Posts: 117
- Joined: Fri Dec 27, 2019 9:01 pm
Re: I+O FPU not supported?
Well it's a chicken-egg situation (and ATARI's not so clever usage of the LineF instructions in the 1.x ROMs made LineF emulations even slower due to necessary address checks for the ROM).exxos wrote: ↑Thu Jun 03, 2021 7:45 pm GB6 doesn't support IO mapped. Simply because the results from GB4 were massively different between IO Mapped and LINE F. The comparison was meaningless.
But as @terriblefire , the overhead is all in software with IO mapped. So your really only benchmarking RAM speed more than the FPU. Aside from that, almost nothing really uses the LINE F FPU, IO mapped, never heard of any software for it.
If people are *really* that bothered about missing IO mapped FPU tests.. Then create me a lib I can interface to and I can add it to GB6, but even so, the bulk of the overhead will be simply ram speed because of the instructions overhead. Plus you still cannot really be compared to a LINE F FPU the 030 CPU can access it at full speed without software emulation. So it will always be inherently many times faster than IO mapped. Caches will also increase speed because of faster "RAM loops".
GB6 IIRC looks for the FPU to be registered correctly with cookies.
In this fractal test app I can see the advantage of the FPU on the 68020/30/40 even over a good fixed point assembler implementation; compared to a software floating point lib most compilers otherwise would use, even the FPU with or without LineF emulation on a 68k will give you a speedup.
How much will also depend on what instructions or real world fpu applications you actually use or test - also in GB (I haven't found any docs about what is used there - yet).