All FreeMiNT builds again available and more!

[mikro]

It took way more time than I had anticipated (not due to the task's complexity but due to my laziness ;-)) but I have finally finished it. So without any long foreword, what's new?

• Separate builds for 68000, 68030, 68040, 68060, 68020-60, Aranym and FireBee (so unlike the previous, "raw", builds you don't have to download all of them). These builds are prepackaged as 1-19-cur (at the time of writing) without any configuration files, so you can basically just overwrite your installation, if you prefer a seamless and minimal upgrade. Every archive contains only modules applicable to given CPU (i.e. no netusbee module in FireBee builds, no ethernat module in all but 060 build etc)
• Fully bootable ST/STE/Hatari, TT/Falcon/Milan/Hades/CT60, Aranym and FireBee builds. And when I write fully bootable, I mean including Teradesk, freemint tools (ifconfig, nfsmount, ...), bash and a few tools from coreutils (ls, cp, ...) to ease your life when doing some debugging and/or saving application output, all visible from the command line. Basically it's the previous aranym build on steroids, see the screenshot, this is what you get with zero work on your side. ;)
• Aranym builds are now compiled for 68040 CPU (as opposed to 68020-60 in the past)
• Separate TOS USB drivers package download, it really didn't make sense to group it with kernel builds
• Version folders on bintray so when you click the "Files" tab, you don't see a thousand previous builds but just the current version

I have tested it on Aranym (easy) and my CT60 Falcon, worked out of the box but it's impossible there aren't some bugs hidden :).

Of course, nothing prevents you to customise the prepackaged (default) configuration to your needs (e.g. networking).

Latest versions are available from https://freemint.github.io/#snapshots, as usual. I hope it encourages some new users to give FreeMiNT a try, bug reports are always welcome: https://github.com/freemint/freemint/issues :)

P.S. Don't forget to boot with NVDI enabled (except the Aranym build).

[marss]

Thanks

[jury]

Nice. Will try it hopefully soon. Thanks.

[robdaemon]

Fully bootable ST/STE/Hatari, TT/Falcon/Milan/Hades/CT60, Aranym and FireBee builds.

This is awesome! Thank you!

One question on running this in Hatari - does it have OLDTOSFS enabled? Not being able to use GEMDOS drives seriously limits use of this in Hatari.

[JeanMars]

Hi mikro,

nice initiative
I had to rename mint\1-19-cur\xaaes.km to mint\1-19-cur\xaaes040.km to boot properly on Aranym.
However, this is not the end of the story:
I don't have my host drive(H:) anymore, I'm did not dig into this but AFAIK, only Aranym configuration matters here no?
Also my network configuration was not working (used to with prevous version).

If that can help, here are my 2 mint folders: http://vision.atari.org/download/temp/mint.7z

Thanks!
Jean

[ThorstenOtto]

Aranym builds are now compiled for 68040 CPU (as opposed to 68020-60 in the past)

I think most of the tools don't use FPU that much, but for those that do, 68020-60 is actually the better choice for Aranym. Yes, Aranym emulates a 68040, but since it is designed to emulate everything as fast as possible, it also emulates the FPU instructions that would normally not be supported by '040.

Great job to have that finally working again, and better than ever!

[ThorstenOtto]

does it have OLDTOSFS enabled?

I guess not. That code hasn't been tested for years, maybe it does not even compile anymore. And actually, it was only a workaround in old mint versions, before there was a "real" filesystem driver for mint.

Not being able to use GEMDOS drives seriously limits use of this in Hatari.

When running Mint, i guess Aranym is a better choice anyway. There you will also have access to host filesystem, you can even boot from it.

[Eero Tamminen]

does it have OLDTOSFS enabled?

I guess not. That code hasn't been tested for years, maybe it does not even compile anymore. And actually, it was only a workaround in old mint versions, before there was a "real" filesystem driver for mint.

Not being able to use GEMDOS drives seriously limits use of this in Hatari.

When running Mint, i guess Aranym is a better choice anyway. There you will also have access to host filesystem, you can even boot from it.

Helmut had OLDTOSFS enabled in his own MiNT branch and I think he did also some patches for it around 2013, but I don't know whether they ever ended in upstream MiNT sources. There was some discussion about this here: http://www.atari-forum.com/viewtopic.php?t=25567

For MiNT Aranym is normally better because it has more NativeFeatures, and is much faster because it doesn't try to be cycle accurate. If one wants to test MiNT with something corresponding to real Atari machines or do code profiling, then Hatari is better choice though.

[Kroll]

Thank you very much

[wongck]

Thank Mikro, as always excellent idea.

[Gaiyan]

Many, many thanks!

[BlankVector]

Great job!

[mikro]

I had to rename mint\1-19-cur\xaaes.km to mint\1-19-cur\xaaes040.km to boot properly on Aranym.

Actually, this is the most interesting point - are you sure about this one? Because the algorithm in xaloader is: check the _CPU cookie and append its value to create xaaes0<cpu value here>.km, in the case of Aranym, xaaes040.km. xaaes.km is a fallback filename, used when the cpu-based one hasn't been found. It definitely works in the bootable builds.

However, this is not the end of the story:
I don't have my host drive(H:) anymore, I'm did not dig into this but AFAIK, only Aranym configuration matters here no?
Also my network configuration was not working (used to with prevous version).

If that can help, here are my 2 mint folders: http://vision.atari.org/download/temp/mint.7z

On the other hand, this one is easy - it seems you didn't download freemint-1-19-cur-aranym.zip but freemint-1-19-cur-060.zip instead. :)

[mikro]

does it have OLDTOSFS enabled?

I guess not. That code hasn't been tested for years, maybe it does not even compile anymore. And actually, it was only a workaround in old mint versions, before there was a "real" filesystem driver for mint.

Not being able to use GEMDOS drives seriously limits use of this in Hatari.

When running Mint, i guess Aranym is a better choice anyway. There you will also have access to host filesystem, you can even boot from it.

Helmut had OLDTOSFS enabled in his own MiNT branch and I think he did also some patches for it around 2013, but I don't know whether they ever ended in upstream MiNT sources. There was some discussion about this here: http://www.atari-forum.com/viewtopic.php?t=25567

It is always better check than speculate: https://github.com/freemint/freemint/bl ... LDEFS#L123

It's the sole purpose of the Hatari build.

[ThorstenOtto]

It is always better check than speculate

Oops, you got me

But unlike aranym, Hatari emulates more than one cputype, so theoretically, you would need hat000, hat020 targets etc. But there are already to much different kernels.

[Eero Tamminen]

But unlike aranym, Hatari emulates more than one cputype, so theoretically, you would need hat000, hat020 targets etc. But there are already to much different kernels.

IMHO only two types would be interesting for Hatari:
* 000 ST/STE one
* 030 one with MMU / memory protection

I'm experimenting with running Linux in Hatari so latter would be interesting comparison point.

(uCLinux has at least at some point worked also on ST.)

[joska]

Great work mikro It almost renders VanillaMiNT obsolete now, I can drop my old build-scripts and just fetch a build from bintray. I will probably change VanillaMiNT from a full distribution to an "add-on" to the official fully bootable build.

[*] Separate builds for 68000, 68030, 68040, 68060, 68020-60, Aranym and FireBee (so unlike the previous, "raw", builds you don't have to download all of them). These builds are prepackaged as 1-19-cur (at the time of writing) without any configuration files, so you can basically just overwrite your installation, if you prefer a seamless and minimal upgrade. Every archive contains only modules applicable to given CPU (i.e. no netusbee module in FireBee builds, no ethernat module in all but 060 build etc)

I'm missing the Falcon-stuff from the 040-build.

[*] Fully bootable ST/STE/Hatari, TT/Falcon/Milan/Hades/CT60, Aranym and FireBee builds.

I have not been paying attention to FreeMiNT development for years now I'm afraid. Does the kernel automatically load modules from the machine-specific sub-folders (falcon, ct60, milan etc) now?

P.S. Don't forget to boot with NVDI enabled (except the Aranym build).

Nova-VDI is also OK, same with MVDI (Milan). Also, XaAES seems to work fine with TOS VDI in monochrome. Is there any work being done to make XaAES work correctly with TOS VDI in general? It's a bit unfortunate that an opensource project requires a closed source (and copyrighted but not available for purchase) component like NVDI.

[mikro]

It is always better check than speculate

Oops, you got me ;)

Not quite it seems - while the hatari build does boot, it is unable to load mint.cnf, so there seems to be some issue with the old filesystem support after all.

[mikro]

Great work mikro :) It almost renders VanillaMiNT obsolete now, I can drop my old build-scripts and just fetch a build from bintray. I will probably change VanillaMiNT from a full distribution to an "add-on" to the official fully bootable build.

If you ever decide to let your great config tools make their way into freemint's tools folder, I'm sure nobody will object against that. ;)

I'm missing the Falcon-stuff from the 040-build.

Damn it, I'm always forgetting that the AB040 is also a Falcon machine. Will fix it, thanks.

I have not been paying attention to FreeMiNT development for years now I'm afraid. Does the kernel automatically load modules from the machine-specific sub-folders (falcon, ct60, milan etc) now?

Exactly.

Is there any work being done to make XaAES work correctly with TOS VDI in general? It's a bit unfortunate that an opensource project requires a closed source (and copyrighted but not available for purchase) component like NVDI.

There is a workaround available but it seems to be non-functional: https://github.com/freemint/freemint/is ... -424063098

[joska]

If you ever decide to let your great config tools make their way into freemint's tools folder, I'm sure nobody will object against that.

In that case the code will have to be compilable with gcc, which is something I don't want to spend time on. However, if somebody else wants to develop these tools further they are free to do whatever they like, including adding them to freemint.

[ThorstenOtto]

Not quite it seems - while the hatari build does boot, it is unable to load mint.cnf, so there seems to be some issue with the old filesystem support after all.

That might also be a problem of how the GEMDOS emulation in Hatari works. IIRC it caches the DTA pointer for example... that might not work very well when using mint, and the current process is switched without Hatari noticing. Generally, using anything from the old TOS in MiNT is only a workaround for functionality that isn't implemented in MiNT, but that does not apply to the FAT filesystem, where there is a new (and hopefully better) implementation.

The best solution would be if Hatari could implement the hostfs interface. That will also give access to long filenames for example.

[mikro]

That might also be a problem of how the GEMDOS emulation in Hatari works. IIRC it caches the DTA pointer for example... that might not work very well when using mint, and the current process is switched without Hatari noticing. Generally, using anything from the old TOS in MiNT is only a workaround for functionality that isn't implemented in MiNT, but that does not apply to the FAT filesystem, where there is a new (and hopefully better) implementation.

The best solution would be if Hatari could implement the hostfs interface. That will also give access to long filenames for example.

Damn. In that case it would make sense to provide Hatari disk images for every build rather than having a special Hatari kernel build just for (non-working) GEMDOS emulation.

Eero, what do you think?

[ThorstenOtto]

However, if somebody else wants to develop these tools further they are free to do whatever they like, including adding them to freemint.

I think porting them to gcc shouldn't be that hard. Are the source available somewhere?

[joska]

I posted the sources on the Firebee dev forum years ago. Can post them on my VanillaMiNT site as well, just give me some time. I'm renovating our kitchen now and have little or no time for play.

Yes, porting them to gcc would be easy. The tools are small and simple and would probably only need minor adjustments, mainly to the AES stuff. But as I don't use gcc myself but AHCC and PureC I don't want to worry about gcc compatibility, so any future changes/improvements by me will be based on the current code.

[TheNameOfTheGame]

I'd like to try this on my Hades060. Never used MiNT before. I downloaded the freemint-1-19-36c-02060-tt_falcon_clones archive and unzipped I have an AUTO and a MINT folder.

Do I just move these to my hard drive and boot? I notice in the AUTO folder is "mint-36c.prg". But in the "mint/1-19-36c/" folder there is a "mint060.prg". Does the AUTO folder program call the other file?