Just my 2 penny worth..

[Stephen Usher <Stephen.Usher@earth.ox.ac.uk>]

Wow! The MiNT mailing list hasn't been this active ever, from what I can
remember, and that after about 3 years of hardly anything on it at all.

Anyway, enough of the pleasantries..

Now, I'm going to make a suggestion which may make some of you shudder and
others woop for joy.

It seems time that MiNT replaced the whole of TOS and all the various
auto-folder programs which "fix" things old TOS just didn't get right.

It's time for MiNT to become a fully fledged TOS compatible OS.

As I can see it, the things everyone wants, ie. full TOS compatibility,
proper multi-tasking, virtual memory with memory protection etc., can only
be reconciled if all vestiges of the old TOS are banished and replaced by a
well thought out replacement. This would include replacing all the hard disk
driver programs with a built-in set of hardware drivers, allowing
non-blocking I/O for the first time and a proper interface for future
programs to use.

Virtual memory, memory protection etc. could be provided by giving each
process a virtual ST. To protect the rest of the system from harm and to
allow these programs to be paged in and out at will, the addresses of the
hardware peripherals would be set to point to an emulated peripheral
interface set to be read-only, so that when a program attempts to access the
peripheral by writing to a register it would cause and exception, which the
kernel would trap, interpret the action being taken and then "do the right
thing." This would allow the programs to think that they were doing all the
work, but the kernel would actually be doing all the peripheral control, so
preventing the problems of trying to DMA etc. to a virtual address.. the
kernel would do all the DMA'ing to physical addresses and then mapping those
into the running process' memory space, then setting the virtual peripheral
to give the process the impression that IT had done the work.

This would only work, of course, on a 68020 + PMMU and above.

Replacing the AHDI's of this world with internal hard disk drivers would
allow MiNT to get over the bottleneck and restrictions of these external and
variable quality drivers. Let's face it.. how many times has ICD changed
their hard disk utilities and broken minixfs.xfs?

MiNT, itself, should contain a minimal set of drivers and filesystems,
enough to get up and running on any system, ie. floppy, ASCI, SCSI and IDE
interfaces plus TOSFS and MINIXFS. After all, we all would like to be able
to boot into a secure environment, don't we? So why not be able to boot from
a Minixfs?

"And what about the AES and GEM etc.?" I hear you ask.. well, that IS a
problem. You could map the screen memory etc. into the processes memory map
and allow them to control the hardware directly. You could also trap calls
to GEM, translate addresses on the fly, or map pages as global on the fly.
This should allow the processes to run without them even knowing that
they're not the only process running.. hence allowing any old GEM program to
run, even those who want to take over the whole machine.. but they will only
take over their own little virtual machine.

All these are kludges. It's the only way to satisfy old programs. However,
they are far better than the kludges which allow our cousins on Wintel
platforms to run DOS programs under Windows'95/8.

Once the above IS in place, however, it allows us to do something more
radical..

(1) Forget about the old DOS drive labelling as the primary way of accessing
	disks. Instead allocate sub-trees of a UNIX-like mountable
	filesystem as virtual drive letters. Special cases for this would be
	the floppy disks and removable media. These can be taken care of
	with a little thought.

    What's the advantage?
	Well, firstly you're not stuck with the size of a "drive" being the
	size of a physical disk or partition. Secondly, if you want to swap
	data from one physical drive to another you don't have to change all
	your paths, merely mount the new drive in the old one's place.

    In a word.. flexibility.

(2) A new exec format and exec scheme.
	How's about replacing the current old CPM-like exec format with a
	more modern one, such as ELF? And, dare I suggest, dynamic stack
	allocation? All these and more can be built once you have a proper
	virtual memory system. And if you're going this far, why not make
	the system call interface fully POSIX compliant as well?

	In fact, why not give the system a complete UNIX-a-Like programming
	interface with libraries to interface to all the TOS/GEM facilities
	you love and hate so that you can compile and run all your old
	source?

	And if you're going that far, you may as well do a Linux/68k system
	call emulation so that you can merely copy the binary from a Linux
	system onto MiNT and run it?

Now, before you start shouting "But I don't want a Linux/UNIX system on my
Atari!" I'd like to point out that I'm not proposing that.. what I am
proposing is a new-age TOS system which is binary compatible with Linux.

Its primary job will be to run TOS/GEM programs, even misbehaving ones, in a
stable and protected way, but giving all the extra advantages that source
and binary compatibility with the rest of the Open Source world gives you.

Now, there will be another group of you moaning that this is all very well,
but it won't work on a lowly 520ST.. and you'd be right.. a lot of this
won't. However, a cut-down version of at least some of this would.

Integrating the disk hardware device drivers into the kernel would help the
68000 people as much as it would the rest of the community. Sure, you
wouldn't be able to run in a protected environment and couldn't take
advantage of the new features of the new exec format, but you knew that
already.

Anyway, not having all the code for memory management in the kernel should
make it smaller and quicker.. just what you want on a small, slow machine.
Also, not having to load lots of TSRs or disk drivers should save some
memory too.

The majority of the code for the 68000 and virtual memory versions would be
common, however, it would mean a huge restructuring of MiNT in which a lot
of the internal kernel interfaces would have to be abstracted to a higher
level, so that the two versions could be separated cleanly. Also, someone's
going to have to write some boot code which will allow the new MiNT to be
loaded via a boot-sector program of some kind.

This would be a very big job, but seeing the sudden enthusiasm on this list,
there may be just enough to tackle it.

Your job, if you wish to take it, is to implement the new MiNT. This message
will self destruct in 5 seconds. Good Luck Jim^H^H^HMiNT-list

Steve

--
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (01865) 282110 (UK) or +44 1865 282110 (International).