exxos's Atari, Amiga & retro forum

derkom wrote: 25 Nov 2020 13:36

agranlund wrote: 25 Nov 2020 13:09 If you want, I can make you a firmware where the interface on the TF536 becomes the second interface so that you can have both enabled at the same time in 68030 mode.
Assuming the Lightning ST does "full" IDE decoding and responds as IDE-0 only (some interfaces does sloppy IDE decoding and responds as being all four interfaces at once but I really doubt the Lightning ST does that)

Sure, why not? Then I could potentially have much faster mass storage when booting MiNT, and stick with the slower storage for "regular ST mode".

As for what the Lightning responds to, it looks to me like it's IDE-0 only, because that's the only place HDDRIVER seems to see it. @czietz could confirm.

I had to remove the IDE header from my TF536 to fit everything inside the case but I used to run that one as the second interface in my machine.
Was handy to have a TOS partitioned drive in the first interface to be able to boot in both Atari TOS and EmuTOS, and having that second interface house a PC partitioned card for when I wanted to share large/many files with the PC instead of using ParCP.

@stephen_usher I just realized you're the guy behind init and MiNTOS! :thanksblue:

MiNTOS was mostly just porting the BSD utils over to MiNT plus adding boot scripts. Init is a relatively simple process really. I just followed the SunOS 4.1.x manual page for the design. :-)

VERY interesting thread - keep it up guys! :)

So I'm updating stuff in MiNT and after updating Bash, I can't run it because I don't have an FPU. e2fsck does not work either and I have to remove it from MiNT. Anything I can do? @mikro ?

Hmm... sounds like someone's been daft and linked the binaries with a version of libm requiring an FPU.

You could boot the machine into TOS and download an ancient version of bash from an atari.archive.umich.edu mirror and put it on your C: drive and then edit mint.ini to use that as your INIT shell. You may then be able to recover by copying the old versions back.

stephen_usher wrote: 26 Nov 2020 10:53 Hmm... sounds like someone's been daft and linked the binaries with a version of libm requiring an FPU.

You could boot the machine into TOS and download an ancient version of bash from an atari.archive.umich.edu mirror and put it on your C: drive and then edit mint.ini to use that as your INIT shell. You may then be able to recover by copying the old versions back.

Thanks. I think I might have found the cause here: https://github.com/freemint/m68k-atari- ... c/issues/1

All TT have 68030 and FPU.
Falcon computers have 68030, but not all of them have FPU.

We already have the -m68020-60 target which generates efficient code for 68020/68030/68040/68060 but requires an FPU.

Would it make sense to add a new GCC target -m68030 without FPU for those Falcon without FPU?

I'm using a 68000 version of bash 4 for now... I'll have to read into this more carefully. Hopefully there is a way to compile for non-FPU 030s

That's a stupid decision to assume an FPU. Unless a program needs to link in libm it should *NEVER* touch the floating point processor full stop.

This is similar to stupid people on Windows and Linux assuming full OpenGL support on the display just to open a dialog box to say there's an error (such as no OpenGL detected).

Assumptions make an ASS out of U and ME.

Atarian Computing wrote: 26 Nov 2020 10:36 So I'm updating stuff in MiNT and after updating Bash, I can't run it because I don't have an FPU. e2fsck does not work either and I have to remove it from MiNT. Anything I can do?

Well, that comes naturally when using gcc generated binaries from the 68020-60 FreeMiNT builds. Quoting gcc docs:

-mhard-float
-m68881
Generate floating-point instructions. This is the default for 68020 and above,

I don't think there is a FreeMiNT build specifically for 68030 without FPU. You should be able to use the 68000 binaries, though. Or you could persuade FreeMiNT maintainers to add a built target.

czietz wrote: 26 Nov 2020 11:29

Atarian Computing wrote: 26 Nov 2020 10:36 So I'm updating stuff in MiNT and after updating Bash, I can't run it because I don't have an FPU. e2fsck does not work either and I have to remove it from MiNT. Anything I can do?

Well, that comes naturally when using gcc generated binaries from the 68020-60 FreeMiNT builds. Quoting gcc docs:

-mhard-float
-m68881
Generate floating-point instructions. This is the default for 68020 and above,

I don't think there is a FreeMiNT build specifically for 68030 without FPU. You should be able to use the 68000 binaries, though. Or you could persuade FreeMiNT maintainers to add a built target.

Obviously, this makes sense for those in the know, but how am I, an end-user, expected to deduce that by making a logical choice between:

68000 binaries for MiNT
68020-60 binaries for MiNT
ColdFire binaries for MiNT

Am I really expected to read gcc docs before downloading a binary that seemingly should work? And this rant is not directed to you in any way, @czietz. Just venting.

How much of a performance hit would I get by using 68000 binaries? (edit: Mikro already responded in Github that it shouldn't be noticeable so I'm cool with that)