mikro wrote: 30 Jul 2024 20:29
if I own an LC060 and can choose FPU: 68000, 68881, 68040 and 68060, which one am I going to choose as an average user?
I'm going to keep playing devils advocate and ask; are these LC users real or theoretical?
I used an LC for a while and as a programmer it was quite fun in a problem solving context.
As a non-programmer expecting things to actually work, I would absolutely not recommend it.
It would be great if those cheap LC's, which happily run 100 mhz, was a viable option if you don't want to gamble on very expensive and possibly fake Rev6's.
060ifsp? It did not install the integer support part unless you also have FPU = crashes galore on programs executing 68000 integer instructions no longer present on 68060. QED among others..
(Ok, this is probably a me-issue for using EmuTOS instead of CT60-TOS. I'm assuming the implementation inside CT60-TOS is not broken like the one in the Freemint repo was for the past forever amount of years)
Doom? I'd expect it to be a fairly common thing to test after getting yourself a fancy new fast 060?
It does not work on LC. Checks for 060 and if found assumes it must have an FPU and does a little bit of floating point math. Easy fix, but you'd need to be a programmer of course.
Apparently there was zero reports of this issue over all these years so a fixed official release was unlikely.
I put a forked version that works on LC on Github.
There was a whole slew of fresh SDL ports released quite recently. They're all compiled for 020-060 because why not, they wont run on 8mhz machines anyway so taking advantage of the better instructions makes sense (for anyone not old in the Atari game knowing about our gcc pecularity)
None of these will work on 060LC, or 030 accelerators without FPU unless you recompile them from source and know how to work around the no-start issue.
Or compile them for 000. I am unsure if this may cause integer instruction emulation to happen, which is not a nice tradeoff.
Mint? Surely it has to be annoying having to explain to LC users that they can in fact not use the 060 package on their 060? The 000-ST-STE one is the correct working one if you have a 060LC, regardless if you have an ST/STE or not.
You can possibly do a mix-and-match with the 000 package as the base and select parts from the 060 package.
mxPlay? Does a little bit of floating point in the GUI code. SoftIEEE would hardly dent performance here and make it run instead of not run on LCs.
(I'm not bringing this one up as some sort of attack because you made it. It's because I think it's the best one out there, the usage of float is perfectly normal and what it does would easily be handled by FPU emulation)
Being forced to use programs compiled for stock 68000?
If they aren't demanding applications then it doesn't matter, as long as you have a working 060ifsp :)
If they are I'd recompile them for 68020-60 or 68060 with suitable workarounds to get rid of the forced FPU check. SoftIEEE would work wonders here too to avoid having to do this.
So my question is actually sincere. Are those LC users real or theoretical? Hasn't everyone who tried one already been scared off when realising it is; mostly not working, requires a lot of troubleshooting and recompiling of old stuff, or unnecessarily crippled by having to run 68000 compiled versions of everything (if those are even available)?
As for the topic of FPU vs. non-FPU, fortunately Atari world has somewhat agreed to always release at least three versions of the app: 000, 020-60 and ColdFire. So there's no need to cripple FPU applications.
That setup is really: 000 (and for FPU-less people regardless of CPU type), 020-060 (won't even attempt to start if no FPU is present) and ColdFire.
I understand why it was made that way back in the days. Full 060 was cheap, and in the case of 030 accelerators the old ones had a socket for one. This is not necessarily the case today.
My gripe is mostly about the forced and completely artifical no-start on 020-060 compiled applications that are not even using floats. I rather it started, because many times it would work, but it is what it is since many years back - hence a real FPU or an emulator for such has been made pretty much mandatory today.
So no, I'm not putting it into the kernel. However I have absolutely nothing against supplying it in the archive, should someone develop something like SoftIEEE. Or maybe there could be an option in the boot menu to turn the emulator on, sure, that works, too.
I think that's fair. Even though I truly believe this kind of thing belongs in the kernel, it's easy for me to rant about stuff when I'm not the one having to support and explain.
But surely, a canned reply like this is sufficient with no other explanation needed?
"You bought the CPU model that is 1/10th the cost of the Premium model. Some things may or may not be slower - be happy it's now finally usable."