Minix-ST 1.6.25 Cross-development

This page describes what you need to build a Minix-ST 1.6.25 cross-development environment on a Unix like OS, with a M68K cross-compiler featuring modern versions of GNU gcc (currently 4.8.5, 4.9.4, 5.4.0, 6.3.0 and 7.1.0) and binutils (2.28).

The toolkit is based on the original Minix-ST 1.6.25 source code, as distributed in the form of diffs relative to Minix 1.5.10 in the spring of 1993.

As a first step you need to download and unpack this tarball. This will automatically create a directory crossdev, in which you will find the script. Running this script downloads the required GNU distribution files and my modified Minix-ST 1.6.25 , if not already present in crossdev/distfiles. Subsequently it performs a complete installation of binutils, gcc and the Minix libraries in a directory that needs to be configured in the script (currently $HOME/crosstools). Be aware that the script will delete this directory first if it already exists and be advised not to run the script with superuser privileges and to check beforehand whether your backups are in working order.

Once you have built the cross-tools you can either source or execute the script devenv in the directory crossdev to set several environment variables and you are ready to go. You can use m68k-minix-atari-gcc to directly create Minix-ST 1.6.25 executables. You can generate a bootable OS floppy image by running make from the directory minix-1.6.25/usr/src.

For a bit more details, see the README file in the crossdev directory.

I have tested this scripted procedure on FreeBSD 11.x, on Mac OS X El Capitan and on Linux. I have seen evidence that the script has been adapted by others to run on Solaris, although I did not receive any feedback on that. Antonio Eleuteri adapted the script to run on Cygwin and kindly contributed his changes. Remember that you will need C and C++ compilers and the zlib library on your host platform. On FreeBSD, you will also need gmake, from either ports or packages.

This release also supports the Atari TT. The variant for that platform still has some issues and a lot of effort will be needed to get the OS and the development environment functioning as reliably as they do for the 1040 ST and the STonC simulator.

I have made a start with cleaning up the Minix source files, to reduce the number of warning messages during compilation of the library and the OS components.

Also, support is now provided for the newer releases of GCC (4.8.5, 4.9.4, 5.4.0, 6.3.0 and 7.1.0) and binutils 2.28. I have added an implementation of mstrip, so that Minix-ST executables can be stripped during cross builds. GCC 5.4.0, 6.3.0 and 7.1.0 are still quite new and only partially supported: C++ needs a workaround due to multiple definition errors when linking the C++ library and I suspect that it will be a lot of work to fix that. Fortran works again for these releases.

Finally, I have added versions of ash (the Almquist shell, as provided with Minix 2.x) and awk (the original one-true-awk, as still maintained by Brian Kernighan) to the tree, including working makefiles.

Please keep in mind the somewhat experimental status of this software, but do not hesitate to contact me if you have any questions or remarks, and please drop me an email if you actually try this software, whether successful or not. I am very eager to hear what host platform you use and on what type of Atari (or other M68K?) target you run (or intend to run) the resulting code.

For future releases I intend to work on cleaning up the makefiles and the build script and I still have to decide on the possible inclusion of my statistical profiler (i.e. the profil(2) system call and the prof(1) command.) Also, I am wondering if I should provide a ready-to-run binary version, probably something like the demo disk from the Minix 1.5 era. Please let me know your opinion about this.

In the not so near future I will need to switch from the ancient a.out executable format to ELF and it is probably possible to switch to full 32 bits mode without too much trouble, though it will break binary compatibility. I also have a software floating point library (written in C) that I want to integrate in my cross development environment. It is far more correct than the M68K assembly version provided with GCC (it passes the "Paranoia" test with "excellent" results) and is only about two times slower. It might also be a good idea to bring libc and libm more up-to-date with respect to the C11 standard.

Update September 2015: Due to shortage of time and lack of feedback I have decided to put this project on the back burner for now. If you need anything specific however, please feel free to contact me.


You can reach me via email as

Back to home

Copyright © 2014-2017 Hans Ottevanger. All rights reserved.