Re: Just my 2 penny worth..

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

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

This is true, in part.. it also depends upon the hard disk driver to be able
to handle multiple requests before it has finished previous ones.

>> 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 "virtual machines" I'm talking about would look to the program like a
clean machine, however, they could have segments of memory shared with other
processes to allow interaction with GEM.

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

It's not QUITE that concept.. it's more a virtual memory space.. though to
stop the programs fiddling with things which could allow them to break other
programs and use full virtual addressing, the peripheral interfaces would
have to be "buffered."

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

Not really.. you can cater for this.. after all, the kernel will know that
the process is trying to do some DMA and hence could put all the pages into
contiguous STram and lock them there.. only allowing them to be paged out
again after a timeout period of inactivity, say a minute. During subsiquent
DMA operations on this memory, all the kernel will have to do is translate
the virtual address to the physical address and run the DMA sequence.

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

Nope.. GEM would be shared.

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

Processes which know about multitasking will be able to get out of the
restricted shell... and I'm sure there are ways in which the kernel could
"guess" what the process is trying to do and map memory between processes as
necessary.

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

I think they are.. there's little enough software for STs anyway without
depleting it further unnecessarily.

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

Maybe.. I'm not au fait with how Win'95 packages DOS programs.. but I'd want
to try to make it less crashable than their attempt.

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

Nope.. I mean a Unified filesystem more akin to the Unix one, where your
boot drive is the root and other filesystems are mounted on directories on
that drive.. the old A: B: C: D: drives would be virtual sub-trees of the
main filesystem, defined by a configuration file, which can be changed on
the fly.

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

I have.. but this goes far further.. betting away totally from the old CPM
way of doing things.

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

Not really.. remember, linux programs do everything via system calls.. so if
you emulate the system call interface and use the same executable format,
then you can run the programs. It's pretty simple.

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

See my previous posting.. it's amazing how little does have to change..
After all there's now a cut-down Linux running on 68000 machines.. all that
has to change is the memory management and the way you handle fork() etc.

You don't have virtual memory, memory protection or peripheral protection,
but you can have all the rest, except for linux executable compatibility.

>> 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!)

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