MiNT

MiNT adds / offers the following services to TOS:

• pre-emptive multitasking
• memory protection for processors with MMU
• virtual root file system with /proc, /dev, /pipe, /shm
• named pipes (/pipe/) and shared memory (/shm/)
• signals and simple messages
• threads (ATM stack fixed to 4KB)
• shared binaries
• loadable file-systems
• loadable devices

Gotchas

• Processes are allocated a fixed amount of stack, not `unlimited' like on unix. Programs have a `_stksize' variable in their headers which can be manipulated with an appropriate utility.
• MiNT uses TOS I/O routines, which aren't designed for multitasking. Especially reads and writes from/to disk slow other processes noticeably. There's a hack in MiNT kernel which lowers priority for programs which are polling but not receiving. Properly written (=MiNT/unix) programs of course use select().
• On 68000 processors, which don't have a (proper) MMU, neither virtual memory nor memory protection can be used. Current MiNT implementation also suspends multitasking while processor is in the supervisor mode so that above mentioned I/O routines will work correctly.
• Any program can enter supervisor mode and bypass kernel memory protection (which is mainly intended as an aid for programmers) therefore MiNT is not secure multiuser environment. For that I'd recommend either a BBS system or some non-TOS based operating system. If this behavior would be changed, it would break almost all existing code, even ones compiled with MiNTlibs (it uses 'cookiejar' for getting system information).
• A preliminary virtual memory support is added to MiNT v1.14. It can be used with 68030 but isn't yet very stable. One of the reasons is (besides some bugs) is that there's no protocol to tell which code (like new interrupt routines (remember, this is just a unix 'emulator'!)) cannot be swapped.

Things to beware with programming:

• MiNT library isn't thread-safe because when GNUlib was ported it was that neither. And because threads have currently fixed 4k stack (defined in the kernel sources) their usage is somewhat limited. You should also note that GEM is not re-entrant. In conclusion, you should thread only code that does all by itself...
• Correctly working GCC versions for Atari are: v2.3.3, v2.4.5, v2.5.8, v2.6.3, v2.7.2. Others may produce code that doesn't work, especially versions before 2.6.
• GCC needs huge amount of of memory. You should have at least 4MB of memory (even the cc1 binary is on latter versions well over 1MB in size) if you're compiling larger programs (function code size affects more than overall code size). With C++ code you will need quite a bit more memory.

MiNT extensions and utilities

Minix2-filesystem is essential for a programmer porting unix software. It implements long filenames (length selectable), soft and hard links, user/group/global permissions and more efficient disk usage than that of the native FAT filesystem.

Some other device / filesystem drivers are:

• dynamic ramdisk. Filenames are case insensitive and limited to 30 characters. Only soft links are implemented.
• audio device, works on all Ataris, with or without DMA. Unfortunately it's ioctl() calls are incompatible with Sun /dev/audio or Linux /dev/dsp devices.
• CD-filesystem (ISO-whatever).
• raw floppy device.

With MiNT + MiNTNet + minix-fs you can also run a monochrome X11R5 server. Some of the basic X software has been ported like fwvm and chimera. You need at least 4MB of ram, but 8MB is required if you're doing anything besides testing. There are no baserelative (for doing shared binary code) versions of the X libraries.

Other multitasking friendly windowing systems available are an old version of Bellcore MGR, W window system and various still incomplete freeware AES (upper level GEM part) replacements. Commercial N.AES is reported to be excellent MiNT friendly AES replacement (much faster and more robust than MultiTOS).

If one wants to run a complete unix style multiuser environment on his machine, he can install the KGMD (Knarf's German MiNT distribution) package. It includes binaries for all the normal unix stuff (file and text utils, manuals, inetd and servers, sendmail, GCC, Emacs, X etc.). Note: As a multiuser system it's quite unsecure! See MiNT and unix differences above...

Nowadays MiNT developers are almost non-existing. Most of the original MiNT hackers have acquired either 68k-Linux (if they have an Atari with 68030), x86-Linux or Free/NetBSD. Sven Karlsson who contributed the latest larger MiNT upgrade, virtual memory (result of testing it for fenix), is concentrating on his new 680x0 micro-kernel, Fenix. It sounds promising.

My Atari page has several links for MiNT (and Atari) binaries, source and information.

MiNT ports

VME-MiNT

Mac-MiNT

MacMiNT is implemented on a top of JET (Just Enough TOS) TOS emulator which implements just those parts of TOS (680x0 traps I think) that MiNT hooks into. Latest MacMiNT version is AFAIK 1.12 and there's also a private port of MiNTNet that maps MiNTNet calls to respective Mac ones. With MacMiNT one can run text-only Atari program binaries like GCC and Emacs on a Mac.

Nowadays NetBSD is also ported to Macs (and Linux is on the works for PowerPC based Macs), but it replaces the System completely whereas MacMiNT multitasks it's programs in a Finder window along with other Mac apps.

My MiNT utilities

• If you too are annoyed with the "Insert disk B into drive A" message when you'll access the MiNT virtual root the first time (MiNT checks for what filesystems disks/drives have), Toggle-B will solve your problem. The program has assembly source with it. 1K

• A port of Mutt Editor v3.5 for MiNT and minix-fs (and sockdev.xdd from the MiNTNet package in case you want to run other programs concurrently in a ME window). ME is a Craig Durland's small (1/4) Emacs like text editor with a builtin language which is a cross between C and Lisp. I have even done one program with it (my Clac in Mutt code, of course :)). (updated 1th August 1995, a baserelative version) 285K

• Jürgen Lock's Virtual Console v0.7 device should make your life with MiNT so much more pleasant. :) In case you don't have the suitable GCC setup for compiling it, I have compiled a monochrome vcons1d and a color vconsd daemons for you. The Vcons allows a separate 'virtual' terminal for every function key (F10 acts as the normal (graphical) console, others are text ones). With the new version you can change the font (mono spaced GDOS or a raw 8x16 one) used. 59K

  There are now sources for even newer version of vconsd. See my Atari page.

Eero Tamminen, puujalka@modeemi.cs.tut.fi