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.9.4, 5.5.0, 6.5.0, 7.5.0, 8.3.0 and 9.2.0) and binutils (2.30).
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 will automatically
create a directory
crossdev, in which you will find the
buildcrossenv.sh 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
For a bit more details, see the
README file in the
I have tested this scripted procedure on FreeBSD 11.3 and 12.0, 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.9.4,
5.5.0, 6.5.0, 7.5.0, 8.3.0 and 9.2.0) and binutils 2.30.
I have added an implementation of
mstrip, so that Minix-ST
executables can be stripped during cross builds.
The newer versions of GCC need a workaround when linking C++ due to multiple
definition errors in the C++ library and I suspect that it will be a lot of
work to fix that.
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 only moderate interest shown in this project, I have decided to put it on the back burner for now. If you need anything specific however, please feel free to contact me.
Back to home
Copyright © 2014-2020 Hans Ottevanger. All rights reserved.