As I said in a natami user discussion :

CLICK HERE 
NatAmi is an Amiga DMA architecture.

I think after 20 years -- for sure -- even in the USA : "quoique" ! the license is in the public domain.

So I said, The whole Amiga software and hardware is a user-oriented architecture not to say heavily DMA-oriented architecture or hardware acceleration for everything (as said Gunnar). For sure, this OS is responsive.

I recall just that now, with the Gigabit ethernet onto the NatAmi board and with a kind browser it will be a network oriented computer. If tasks in this multitasking OS are in "some way ; to think" protected.

For me it lacks MMU, but not the way you think, a kind of virtual machine (so uses of the MMU) and as a user will experience :

A "virtual machine" For each [Amiga] screen.

And, the is more to do than just adding a classical MMU or using features of a management memory unit, to think and conceived/engineer, that is the segmentation & logical feature.

Not, using the paging mechanism, which leads to trashing problem.

I'm just an software engineer and "self Amiga apprenti" like everyone here. But, saying you don't need some MMU feature like segmentation (not paging) is a non-sense on modern CPUs and modern architecture. Because, Enforcer is built-in AmigaOS4 [former Amiga developer knows this great program : Enforcer] !

Is tricking with the copper to load a new MMU configuration each time a screen is displayed possible ?
You can imagine easy multi-processing (don't care the kind) because they will be a task-queue for each virtual machine = for each screen. I think someting like this will be done for the AmigaOS4.2 ... on the X1000.

Now, we know how to improve the software that is the multitasking to have not only a user-oriented machine but a network&user-oriented machine. After this big improvement of the hardware :

The NatAmi... user, and, network oriented OS.

Best regards.
DgeeDee from FRANCE

I know I'm boring ..

But my propos, means NO virtual machine in the trend No Java virtual machine, no need to run software on virtual machine, indeed.

Just logical memory maps for each instance of the original AmigaOS on each core (a minimal use of MMU feature with NO PAGING , just segmentation I think).

This also means COMPATIBILITY ; you can launch two workbenchs on each instance of the AmigaOS (this is, already, done with emulation like UAE ; isn't it !)

And we know that we can launch two workbenchs on our great Amiga ;  due to built-in multithreading, but with my point of vue, we can protected one OS instance crashing from another (or the whole system won't stop if a bugs appear on the Browser ! Things which are very hard to prevent with network/downloading code).

Kind of this work has been done on MorphOS.

Instance swapping is also a user solution to load balancing. I know, I'm pretending !

And also
Great for browsing the Web.. as I just said with no needs to know for sandbox, because Amiga apps will run as usual.

A great user AND Simple Networking oriented AmigaOS.

The question was in the minds of C=A engineers, back from the 1990s, and the simpler it is the better it is !

Another fact is that, what we call "thrashing" (on MMU enabled system) is just graphics thrashing onto an Amiga screen ; that is pixel poking into the CHIP memory, only.. like usual.

But notice that on modern Amiga(new machine) thrashing means always the system bugs and reboot even with some feature of MMU enable !

Sound is also bad, strange graphics pixel always means reboots on modern system (even with 7.1 and even with R500 GPU).

Instead of just "ghost" [CHIP pixel trashing] on classical Amiga.

Some C=A engineer, said to me someday that "MMU" is the separation of CHIP and FAST memory on the Amiga.
That is true but a new Exec with a per core AmigaOS instance will be great too !!

This surely means real message passing API(kind of MPI) for those who what to do real SMPs.. end of the debate.

Simple multicore processing needs instances of the AmigaOS and this issues a new Exec with the marketing notion of "Virtual machine" !

And simple it is means just simple to do ; segmentation for each instance of the system Exec Object.. and multithreading like before.

Ready to code ...

Kind regards dGee-Dee Amiga enthousiast enables.

Few people liked the idea which doesn't matter all that much because it isn't going to happen anyway...

First @ MinusMax : Great but you know I'm so rough !

Secondly, I just know that hardware resource on the Amiga(OS) are files named :

'cia.resource'
'potgo.resource'
'disk.resource?'

It lacks some more 'xxxx.resource' which are lower level then Exec devices. But the concept is only valid with original Amiga SmallMachineDMA model architecture. And it is hard to use the pile :

hardware
--------
resource
Exec device
DOS device
--------
User Handler

In a french article (use the translate icon on the site) I said :
"
Je n'ai pas vérifié, mais seules les ressouces devraient pouvoir verrouiller certaines parties du système au niveau de leur API (Open/Close) ou conceptuellement avec un sémaphore mutex, uniquement binaire si la ressource n'est pas multiple sinon je conseille d'utiliser l'allocation multiple "en pool" de sémaphores binaires (de verrous) ; plutôt qu'un sémaphore multivalué au-delà de la plage 0/1-).
" J'ajoute que l'allocation des resources doit ce faire dans un contexte non-multitâche. Sinon interblocage "possible".

In english now :
"
I've not verify, but only resouces should lock parts of the system (not device directly or libraries) with Open/Close . _Conceptually_ a mutex semaphore or binary semaphore and a pool of binary semaphore only if "the resource got  multiple instance" ; the pool is prefered to multivalued semaphore [what we used to play on system computing course]
"
Furthermore I have to said, that allocating resource must be done when there is no multitasking or at "boot time" : when a new instance of the AmigaOS is launch (with a pool of binary semaphore introduce in OS 1.3 ;-)

The article can be found in the obligement french online magazine :
EXTERNAL LINK  (use translate at the upper-left corner for a pretty good english)

Gilles ed!dridi

Gilles DRIDI wrote:

I just know that hardware resource on the Amiga(OS) are files named : 'cia.resource' 'potgo.resource' 'disk.resource?' It lacks some more 'xxxx.resource' which are lower level then Exec devices. But the concept is only valid with original Amiga SmallMachineDMA model architecture. And it is hard to use the pile : hardware -------- resource Exec device DOS device -------- User Handler ... " I've not verify, but only resources should lock parts of the system (not device directly or libraries) with Open/Close . _Conceptually_ a mutex semaphore or binary semaphore and a pool of binary semaphore only if "the resource got multiple instance" ; the pool is prefered to multivalued semaphore [what we used to play on system computing course] " Furthermore I have to said, that allocating resource must be done when there is no multitasking or at "boot time" : when a new instance of the AmigaOS is launch (with a pool of binary semaphore introduce in OS 1.3 ;-)

Correct if necessary: what is proposed is a modified kickstart in order to run multiple instances of Workbench.

Somethings intrigues me:

This seems to imply that only applications that respect the OS will be eligible. True or false?

Several kickstart will be run simultaneously?

Thanks

To be honest Nixus i am with you on this up to the suspend to disk.
If this trend will stick about the flash drive media this would be a bad idea because it would be another write access of the finite one's.(SSD's CF card and other flash media)

If needed to be low level access could be intercepted.

I guess it wouldn't be impossible to protect the RAM space of the other instances in a soft-reboot of just the one instance that does low-level access, e.g. one might do a hardware reboot of the custom chip stuff and a software reboot of only the instance that did the low-level access.

Writes are finite but the real problem with flash are the limited erases per block.
However with a proper system design that isn't that much of a problem: add good ECC, detect when a block is going faulty (which is varying but more than the guaranteed # of erases) and switch the block from MLC to SLC mode.

Even if i use a regular HDD writes in a given period of time are finite.(Interface limitations, this even goes for SATA 600)

Besides that IIRC most current hardware hitting software did not go outside the first 16MB.
Besides that the natami's design would allow more space so future software hitting the hardware, ai i do not wanna think of it too much.

To be honest i was thinking of writing a tracker program for the natami.(something i currently have in my project fridge)
If the audio software interface isn't to my liking i will bang the hardware.

Why not write an audio software interface instead?

Ideas , Encouragement , Experiences ... Some of You might want to
get a Great Job done , make Experiences , bring back New Ideas ,
Encouragement , Expertise , Energy , and +1++ re-sources to e.g. :
The Natami Project ;)