68060 sources

[JezC]

Interesting, might have to save up a bit & try my luck...and hope it's a genuine working example!

Same here. I'd like a Raven one day as well

[mikro]

I'm going to keep playing devils advocate and ask; are these LC users real or theoretical?

Please do, I always like to hear arguments from an experienced party. And good point. So far I have been aware only about a couple of shy attempts to run CT60 with the LC model. But as you mention later, this may change with (still selling) CT63s and the shortage of full 060s.

As a non-programmer expecting things to actually work, I would absolutely not recommend it.

I think this is the reason why we don't see such issues / posts: people read that they need the full 060, period. So nobody bothers. Except you, a true pioneer again! So I enjoy reading your POV, because it's something new after all those 20+ years. Your findings about LC (in)compatibilities are therefore very interesting because yeah, nobody has bothered.

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.

I'm not sure I understand your reasoning here: if it's not too demanding, we have a 000 build. If it is, we have a 020-60 build but you still think a SoftIEEE would help here? How so? If it's so demanding, it is perhaps due to heavy FPU usage so how SoftIEEE would help here?

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 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.

If I understand you correctly, you're unhappy about applications which do not supply 000 versions (like old builds of zview or mxplay) while they really don't use FPU that much.

In general, there are various ways how to approach this (in order of complexity / annoyance):
- do nothing, just recompile some applications also for 000 (as it happened to zView) or patch them where necessary (060fpsp, doom)
- create a SoftIEEE and hope it will be enough for most cases
- introduce a -msoft-float target (here you can see that I'm advocating for EC/LC users, too! ) ... but this again begs the question *what exactly* are we hoping to achieve there... the speed difference between -m68000 vs. -m68030 (or -m68060) -msoft-float will be almost invisible

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.

Do I get it right that the hypothetical SoftIEEE for Atari is basically https://github.com/agranlund/tftools/tr ... /src/fpemu extended to support EC/LC 060?

"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."

If one day an Atari SoftIEEE makes it into the kernel, I'll find this post and copy&paste this very message to show as soon as one enables the emulator in the boot menu.

Just because there's a minority of confused people out there (I'm being diplomatic with the word 'confused') shouldn't mandate that 'we cannot have nice things'.

No, the point is elsewhere. Usually the dumbest users are most vocal (just look at the top post creators in the Atari Falcon030 FB group...) so all it takes is one user who claims some BS, it gets traction, it gets into some posts/manuals/howtos... And some things that should not have been forgotten were lost. History became legend. Legend became myth. (how many people still believe that FreeMiNT = CLI stuff? how many people believe that enabling MP "decreases compatiblity" ? I could go one and on... and it is all sourced back to some confused individual who just posts it at the right time and at the right place)

[agranlund]

The main point is mostly that if you try an LC you will encounter different kinds of road-blocks one after the other. If you can code then you can pick them off one by one as you encounter them. But my belief is that FPU emulation would do a great deal to remove many or most of these in one single swoop.

Sometimes it would actually emulate something, and sometimes the performance impact of that emulation wouldn't be so bad or even noticable (mxPlay)
Sometimes it would be incredibly slow and unusable (Quake) - but that is still no worse off than not being able to start it at all.
Sometimes it would not emulate anything but only serve as being able to even start 020-060 compiled applications.

No matter how you look at it I fail to see why something like that could ever be a bad thing?

I'm not sure I understand your reasoning here: if it's not too demanding, we have a 000 build. If it is, we have a 020-60 build but you still think a SoftIEEE would help here? How so? If it's so demanding, it is perhaps due to heavy FPU usage so how SoftIEEE would help here?

If there is a 000 build of something then yes it could be run. Some integer stuff may now end up under emulation but who cares if it's something that isn't really demanding.
But then the same could be applied for everything. Why are we wasting time building separate 000,020,030,040 and 060 versions of Mint if the 000 build should be good enough for everyone regardless of CPU?

If there is a 020-060 build then that build does not work on LC.
You are greeted with "This program requires FPU, kthxbye, sucks to be you!". The originator of that message has no idea if the program actually requires FPU.

If there is only a 020-060 build an no 000 you are now out of luck.
This scenario exists. And it makes sense, typically games which will not run on a stock ST anyway so why not optimise for the better integer instruction set. If something is barely hitting 30fps on an 060, then yes I would build for 020-060 only because why bother with the hassle.
If you don't have experienced using an 030 accelerator without FPU, or an 060LC then how obvious is it that these CPU flags are also implying hard FPU requirements and even worse that "helpful" code in Mintlib that will refuse the thing from running on non-fpu systems -- when mintlib has no idea if I am actually using floats or not. It's nuts.

An -msoft-float option will only work in practice if the programmer actively knows and cares about non-fpu machines.
It's too easy to do the "wrong" thing, since the "wrong" thing is the default (wrong being extremely subjective here )
Besides, we have 10+ years of existing binaries with "This program requires FPU" in programs that may or may not require FPU.


By demanding I'm thinking mostly on game ports. And as I typed that I do realise I am quite narrow minded.
I've worked in games since, too long, so that's naturally where my mind goes.
But keeping on that trail, seeing as a modest 68060 is just about fast enough for late 486 or early Pentium1 era things, all but very few of these will have been fixed point due to economics, wanting to reach the widest audience possible in a time when FPU's were not yet fully the norm on the DOS side of things.

This is where my, perhaps narrow minded; "almost nothing is actually using FPU but still the thing wont start because whoever put that message into mintlib is an asshole that hates poor people" comes from
In that context. Yes, SoftIEEE will be a solution and it doesn't even have a performance impact - it's mostly there to be able to start the thing that doesn't even use FPU.
In reality, it's quite possible that I am wrong and a lot of things are indeed using FPU to the extent that emulation is a futile effort.

SDL remakes can of course have done it different after the fact, but let us at least assume that the majority of anything you'd possibly want to port that originates from the DOS era and is playable on a comparatively slow 68060 will not have been using floating point in the original DOS release.
There is Quake, being an early P1 game and one of the first PC games without a fixed-point codepath, but then shortly after that x86 performance quickly started accelerating towards crazy town - so forget most of what came after.
So yes. there is Quake...

Do I get it right that the hypothetical SoftIEEE for Atari is basically https://github.com/agranlund/tftools/tr ... /src/fpemu extended to support EC/LC 060?

If it was me, I think I would have started from scratch based off the one inside m68k-Linux instead of that one which I extracted from NetBSD. Or even better, ask the Amiga guys nicely if it's possible to borrow the SoftIEEE sources for an Atari port. I'm assuming it would need to be extended to deal with being invoked from usermode, and the usual kernel glue differences etc but since it's already designed as a standalone thing I'm thinking it has to be a win in terms of work involved.

Now, it probably isn't me since I caved in and got a full Rev6, and by that loosing the powerful motivation by necessity.

[mikro]

No matter how you look at it I fail to see why something like that could ever be a bad thing?

Apart from the confused users dilemma discussed above there's one more thing to consider and that is whether this really fixes a problem or hides it. From your recent list:

060ifsp: as it turned out, the 060FPSP package does install the integer part, it just prints an error. So no issue with LC/EC here.

PMDoom: there was an explicit check in the code; now it has been fixed thanks to you. Nothing to do with the check in mintlib.

FreeMiNT: this is something which needs to be fixed on that side. Be it mint060.prg not working on the LC/EC or that *all* applications from the 020+ archives require FPU. With a SoftIEEE, this wouldn't be so obvious. Now I can put it into out issue tracker and think about 'clean' solutions.

mxPlay: tough one. The gui certainly doesn't need FPU so a SoftIEEE would excel here. I assume your plugins would be also very happy in a FPU-less environment. However the "060 plugins" all require heavy usage of the FPU, so what do I get with a SoftIEEE? Complaining users that their super-duper 100 MHz 68LC060 stutters in mxPlay! Outrageous! What's the proper solution here? Yup, to provide 000 builds.

Why are we wasting time building separate 000,020,030,040 and 060 versions of Mint if the 000 build should be good enough for everyone regardless of CPU?

Yes, why indeed. I'm tempted to write "politics".

The kernel is special, it has to have a separate version of at least 000, 030, 040 and ColdFire. It has nothing to do with optimisations but more with features compiled in. The 040 one is further split between Milan and Aranym, this is something which I hope to see one day resolved but as I said, nothing to do with optimisations. Maybe even 030 and 040 could be merged one day but again but that's it. 000, 020+ and CF would remain separated indefinitely.

However the build archives... my initial goal with the freemint builds was to cut down the number of archives to a bare minimum - ST/STE, 020+ and FireBee. However there was some pressure to keep the old way building things, i.e. to provide CPU variants for every CPU model, so I did that, too. But as mentioned above, I hadn't realised the implications (that every application is in fact linked against m68020-60 mintlib/gemlib so it's kind of pointless). So most likely those CPU builds will go away at some point.

If there is only a 020-060 build an no 000 you are now out of luck.

Besides, we have 10+ years of existing binaries with "This program requires FPU" in programs that may or may not require FPU.

I would have a hard time coming up with an application which provides 020+ builds only and have no source code available for a possible 000 recompilation.

An -msoft-float option will only work in practice if the programmer actively knows and cares about non-fpu machines.
It's too easy to do the "wrong" thing, since the "wrong" thing is the default (wrong being extremely subjective here )

I would argue that the "wrong" thing here is assuming that "-m68000" (or no argument at all) is not the sufficient default for everybody because it is. Whether the developer consciously chooses usage of "-msoft-float" or "-m68020-60" (which is described in the manual as one using the FPU *by default*) doesn't matter. If someone doesn't know the implications of the switches, he shouldn't use them, it's as simple as that IMO.

This scenario exists. And it makes sense, typically games which will not run on a stock ST anyway so why not optimise for the better integer instruction set. If something is barely hitting 30fps on an 060, then yes I would build for 020-060 only because why bother with the hassle.

And this is again the argument mentioned previously: how important is to bother with -m68020-60 -msoft-float vs. -m68000 ? If someone presents me good evidence that look, Descent gives 15 FPS on -m68000 but 20 on -m68020-60 -msoft-float, then we're talking. Otherwise I maintain my position that it's just easier to recompile given application for -m68000 than inventing FPU emulators.

Now, it probably isn't me since I caved in and got a full Rev6, and by that loosing the powerful motivation by necessity.

I'm afraid that this is the strongest point of this debate: I'm in the same pool, so is everyone with their CT60s so far. I'd gain nothing from spending my time on convincing Amiga guys to give me their emulator code or ripping it from NetBSD/Linux and adapting for Atari.

Yet another way of looking at this problem is that until very recently, nobody has ever coded an FPU emulator. So the check in mintlib protected users against sudden crashes (remember, FPU crash = trashed video, audio, keyboard, OS etc, not just exiting the application). Is that worse than forcing users to actively seek 000 builds of given application? I would argue that it is not.

So TL; DR version of all this chaotic set of my thoughts would be that for having a kernel FPU emulator I would need first to see:

- a reliable, ideally both 030 and 040/060 EC/LC friendly, FPU emulator
- some convincing examples that compiling against -m68000 is not enough and/or some examples of applications which can't be recompiled for -m68000 and yet being very useful on LC/EC models with an emulator
- a reason why this can't be just a simple PRG so all TOS, EmuTOS, MagiC etc users can benefit from it, too

[terriblefire]

- some convincing examples that compiling against -m68000 is not enough and/or some examples of applications which can't be recompiled for -m68000 and yet being very useful on LC/EC models with an emulator
- a reason why this can't be just a simple PRG so all TOS, EmuTOS, MagiC etc users can benefit from it, too

Over on the Amiga side of things we frequently find we have binaries without sources and the person that created them has long since departed the scene.

Thing is you already have to emulate some instructions on the 060 because they're not in the CPU compared to the 000/030. (Unless things are compiled 060 clean which is rare). I guess this is just an extension of that.

[mikro]

the infamous CT60 5s delay option. Despite being OFF by default, for freakin' 20+ years there's every now and then an idiot who read somewhere that it's a good idea to turn it on ("it improves compatibility") and then spams forums with question like "Why is Quake 5 FPS on my setup, did I buy wrong CPU?"

It took only a month: it seems my 68060 is stuck at 7.16 Mhz....

[phoenixdownita]

y

Also LC060s are abundant and cheap. They can run at ~100 mhz, people just need to start compiling using the -nofpu option. Even if they don't, with SoftIEEE, you can still run FPU code and get more performance out of it than with a 68882, people just need to stop being snobs about the FPU.

Well...
This SoftIEEE?
SoftIEEE.jpg

75MHz Rev 4 + SoftIEEE = 0.13MFlops:
Rev4-75.jpg

25MHz 68882 = 0.66MFlops, ~5x faster:
68882-25.jpg

40MHz 68040 = 7.67MFlops, 59x faster:
040-40.jpg

50MHz 68050 = 28.01MFlops, 215x faster:
Rev6-50.jpg

100MHz 68050, 56.00MFlops, 430x faster:
Rev6-100.jpg

SoftIEEE is no option in my opinion, at least not the one in that benchmark. Is there a less precise but faster version of it?

Hold on just a sec, I just downloaded the latest softieee AND MuRedox and on a cd32 with tf360 in sysinfo with an LC060@50mhz it shows 0,47 mflops …. not bad.

You need the latest softieee for MuRedox to work, it’s a JIT patcher for the fpu and in my case moved the mflops from 0.08 to 0.47 (I can see why for softieee library alone ThoR is not interested into faster impl given the cost is in the line F handling and all the magic he had to pull off for proper emulation).
I have not checked if aibb shows any reasonable numbers (if it works at all) but if the sysinfo value is “indicative” then I expect an LC060@75mhz to be almost on par with your 030+882@25mhz sysinfo score.

What that could mean is that anything that requires fpu and is deemed acceptable when running on a 882@25mhz would be fine on softieee + MuRedox if it runs, in addition it could also mean that lower precision impl of softieee (not sure one can easily reuse the already existing faster impl) could translate in even higher perf. I believe ThoR mentioned there are soft impl meant for speed that could be 2x/3x as fast as his at reduced precision … alone they would do very little without MuRedox (I experienced a 6x perf increase in sysinfo so the cost was the emu not the math) but with it if the sw can deal with the lower precision one can enjoy a nice boost. It’s all theoretical obviously as if you really need a fast fpu you should have a full 040/060.

None of the above would make Quake run acceptably by itself or allow the 060 demos to realize their awe factor, just so we’re clear.

Could you test on your system LC060@75mhz the combo newest softieee + MuRedox and see what you get?
It is possible the sysinfo data severely overestimates the actual perfs so it may not translate to real life matching over an 882@25mhz, still impressive results for the 2 tools.

Note: my LC060 can on.y work up to 62.5mhz, anything else is unstable/lock so I can’t test much on my side.
ThoR mentions that some SW does not like to be JIT patched so MuRedox is not for everything.

[alenppc]

but if the sysinfo value is “indicative” then I expect an LC060@75mhz to be almost on par with your 030+882@25mhz sysinfo score.

LC060 running at 100 MHz on the 1260 achieves a score of 0.94 mflops.

Note: my LC060 can on.y work up to 62.5mhz, anything else is unstable/lock so I can’t test much on my side.

The problem is not your LC060 but the fact that most TF360s will only overclock to 67 MHz max. Only a few will be able to achieve 94Mhz and I have never managed to get one to achieve 100, but for those kinds of tests, it's best to use a TF1260 or 4060.

[phoenixdownita]

Note: my LC060 can on.y work up to 62.5mhz, anything else is unstable/lock so I can’t test much on my side.

The problem is not your LC060 but the fact that most TF360s will only overclock to 67 MHz max. Only a few will be able to achieve 94Mhz and I have never managed to get one to achieve 100, but for those kinds of tests, it's best to use a TF1260 or 4060.

Do you know if the work Steven has done on 1260/4060 could help?
I have noticed you removed a recent tf360 fw from your support website due to “issues on a full cpu” … was the LC060 more overclockable on it?

At any rate a big thank you to Steven for releasing the TF line of accelerators and all the builders for making them available to the rest of us.

[alenppc]

Do you know if the work Steven has done on 1260/4060 could help?
I have noticed you removed a recent tf360 fw from your support website due to “issues on a full cpu” … was the LC060 more overclockable on it?

At any rate a big thank you to Steven for releasing the TF line of accelerators and all the builders for making them available to the rest of us.

The new firmware improved chip ram speed and CD drive compatibility but unfortunately it had the bug that prevented the full CPUs from booting.
Stephen spent months trying to figure why the production PCBs could not overclock well, with Chucky, supaduper and me testing along, but I don't think we ever managed to clearly figure out why. I don't think it's a firmware issue, more like a hardware limitation for some reason.