Re: Just my 2 penny worth..

[mintlist@mettav.demon.co.uk (jacquesa@zetnet.co.uk)]

Hi

> 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.

Its good news. :)

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

Makes me shudder... :)

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

See Sven's post about Fenix. IMO, you should wait for this.

> 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.

As Julian has been trying to point out, it is MiNT (and its dependence on
standard GEMDOS calls) which causes us not to have non-blocking I/O,
not the HD-driver interface.

> 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

It sounds to me like you are proposing that we write an OS that provides
ST virtual machines (including MiNT functionality on each machine?)

The concept of a "Virtual Machine" is well documented (a quick look
in my copy of Tanenbaum's "Modern Operating Systems" shows that an OS
based on this model existed in 1979). 

Nice in principal, but it would break a lot more than you would think...
For example, timings. You say in another post that the Virtual Machine's
ST-RAM will appear as if it is ST-RAM, even if swapped to disk... fine, I
can accept that it can be swapped in/out and the Virtual Machine will
not be aware of it, however you are NOT going to be able to do that fast
enough to keep sustained Sound-DMA going while performing any processing
that the software may have been doing.

> "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.

Sorry, I'm not quite sure what you mean, but if you follow the standard
Virtual Machine model, you would have a copy of GEM running in each virtual
machine. 

> This should allow the processes to run without them even knowing that
> they're not the only process running.. 

Which is bad.... Inter-process comunication is good. The nicest things
about a modern MiNT+GEM system is things like OLGA, AV Protocol, 
Drag'n'drop.

> All these are kludges. It's the only way to satisfy old programs. However,

Why? Are these old programs REALLY worth this much work? I dont think so.

> they are far better than the kludges which allow our cousins on Wintel
> platforms to run DOS programs under Windows'95/8.

They are? it sounds very like a "DOS Box" under windows 95 to me. I dont
know the details of how this works, but they all have their own display,
memory map etc.

> 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

erm... you mean like the MiNT "unified" file-system on drive U? Yes, drives
are labelled /c /d etc, but you can sln and put them anywhere... (see the
filesystem used by most people on this list, and you'll find standard[ish]
unix directory structures...

> (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

Maybe you have not recieved the thread on a new binary format...

>  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?

If you want that, then you really are looking for OSIS running on Linux/68k.
TOS/GEM binaries running under Linux/68k (actually, it'd be quite close
to a Virtual Machine... the main difference is that they dont try to
handle the hardware, which you want).

> 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.

It would have to be so radically different that it would be a different
program - not worth merging the sources of the two programs.

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

Not really... I think fenix is better (although I question whether it
is a one person job... but then, not many people have the knowledge to
help!)

Anthony
-- 
----------------------------------------+-------------------------------
Anthony Jacques           IRC: AnthonyJ | Bad Mood, GEM-DEU, FracTalk,
                          ICQ: 11287923 | STOS patching, Falcon Extn,
jacquesa@zetnet.co.uk                   | MiNT.CNF, Reschange, Tuna,
http://www.users.zetnet.co.uk/jacquesa/ | and more... which shall I do?
----------------------------------------+-------------------------------




--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|    The Tavern BBS Gateway 300-33600 V42Bis MNP 2-5 24 Hours       |
|                  **>   44-(0)181-364-8268   <**                   |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~