exxos's Atari, Amiga & retro forum

For bash it wouldn't be at all noticeable as it spends most of the time waiting for input.

Maybe FreeMiNT should at least mention it somewhere (outside of the Github issue tracker) that the 68020-60 builds require an FPU.

Well, it does print that text message that it requires an FPU, doesn't it. ;)

To complicate things even more, 020+ kernel builds do not require FPU at all.

If more TF536 FreeMiNT users start popping up, we may reconsider adding another target but it's not as easy as adding one more line into our build scripts.

mikro wrote: 27 Nov 2020 07:03 If more TF536 FreeMiNT users start popping up, we may reconsider adding another target but it's not as easy as adding one more line into our build scripts.

How many more do you need? I'm one. :)

I haven't actually installed FreeMiNT yet on any TF536 machine, but having it bootable on my Stacy is the eventual goal. Using the 68000 builds isn't the worst thing, but being able to use a proper 68020+ build would be nice. Really it depends on how "not as easy as adding one more line" it is. I won't be heartbroken if it's not worth the effort.

I can confirm that the 68000 build + 68030 kernel works fine here without FPU and you'll get memory protection.

Use fastram.prg rather than maprom.prg if you're using the 68030 kernel though - MINT needs the MMU for its memory protection feature.

agranlund wrote: 27 Nov 2020 10:01 I can confirm that the 68000 build + 68030 kernel works fine here without FPU and you'll get memory protection.

And that much is probably fine with me. The 68030 kernel is certainly the most important part, and the rest being 68000 isn't really a problem, so I'd say if building the whole thing for 68030 without FPU is a non-trivial task, it's probably not worth it for just a few users.

agranlund wrote: 27 Nov 2020 10:01 I can confirm that the 68000 build + 68030 kernel works fine here without FPU and you'll get memory protection.

Use fastram.prg rather than maprom.prg if you're using the 68030 kernel though - MINT needs the MMU for its memory protection feature.

I have the 192K boot-roms and then I seem to have to load the 256K EmuTOS after for MiNT to boot. I shouldn't need fastram.prg? I have MMU and the speed in MiNT indicates that fastram is ok. I also have almost 20MB of fastram used as well.

@mikro
Hey Mikro are you aware of any lighter weight bash alternatives compiled for mint? I find bash to be very sluggish on my 030's. Of course I have tried mksh from the sparemint repo but it doesn't support bash alias commands. It's kind of funny that Linux distros are not using bash any more because they say it's bloated lol, I think they mainly use 'dash' now. But yeah if you get a spare moment I'd appreciate it if you looked in to it. Thank you

Atarian Computing wrote: 27 Nov 2020 11:44

agranlund wrote: 27 Nov 2020 10:01 I can confirm that the 68000 build + 68030 kernel works fine here without FPU and you'll get memory protection.

Use fastram.prg rather than maprom.prg if you're using the 68030 kernel though - MINT needs the MMU for its memory protection feature.

I have the 192K boot-roms and then I seem to have to load the 256K EmuTOS after for MiNT to boot. I shouldn't need fastram.prg? I have MMU and the speed in MiNT indicates that fastram is ok. I also have almost 20MB of fastram used as well.

Yeah it's only if you're booting from TOS2.06 it's needed. EmuTOS is able to find and register the fastram by itself :)

Steve wrote: 27 Nov 2020 12:35 Hey Mikro are you aware of any lighter weight bash alternatives compiled for mint? I find bash to be very sluggish on my 030's. Of course I have tried mksh from the sparemint repo but it doesn't support bash alias commands. It's kind of funny that Linux distros are not using bash any more because they say it's bloated lol, I think they mainly use 'dash' now. But yeah if you get a spare moment I'd appreciate it if you looked in to it. Thank you

IIRC, ST MiNT (https://subsole.org/st_mint) also uses mksh, maybe its newer version supports aliases?

Yeah, dash is an option but it's not 100% bash compatible. But it's a good idea, maybe we should really consider a more lightweight shell.