Is your comment in reference to a specific post?  I am certainly happy to get into more detail but I'm not sure the benefit if the topic isn't of interest.  The OP seemed to be trying to understand the future of the Amiga platform and put forward improving stability as something that should be considered.  It seemed to me like an interesting area of discussion but I can also appreciate that it may be more work it's worth if there's no real future in the platform.

In terms of specifics, I have a background in Electrical Engineering and software development.  I coded for many years in C/C++ but not ASM nor do I have a background in developing for FPGAs (I've done a some reading and understand the principles).  It is clear there are many people on this forum with outstanding knowledge and skill.

I guess I'm hoping to have a more detailed conversation on the MPU with the goal of understanding the options for enabling page management in support of improving AROS stability.  If that should be in a separate thread or not the way things are done here then no problem.  If it is more appropriate that I go away and figure something out and put forward a proposal I could do that as well but I guess I'd like to first at least know if it is a non-starter.

doing things in correct order is good.
it is just brainstorming. at least from my part that's what is was.

1) aros succeeding at being a viable aos clone/alternative in the traditional, original sense.

2) what next ? how things could get improved ? doesn't hurt to discuss this.
it's not because noone found a solution yet that this topic should be off-limits.

beside, having separate code branch is always possible, so there's no messing around.
aros-classic branch (aim at being as closest possible to original aos)
aros-experimental branch (aim at improving the limitations)

@Wells

thinking out of the box is good,
if a hardware solution can help, or just about anything else at all then why not ?
any ideas, any attempt should be welcomed.
as gunnar said ealier in this topic, people have tried to think about a solution for this for 30 years. so i guess that means there is interest for it.
i personnaly think they all failed because they wanted to add the new feature without modifying the existing. or another possibility could be because they wanted to do it "by the book" implementing memory protection as it is meant to be, as it is defined. but in reality, anything that could improve the situation would be good to have. being some sort of hybrid half mp,
being software or hardware, being something completely different, it's all good as long as the result is significantly improved stability.

then maybe the os need a transparent "middle man" taking care of memory allocations, like with the load balancer analogy, all memory writes should be sent to him and he decide where it's good to write. in the load balancer case, response time is important too, linux kernel dispatch requests very quickly to available cloned servers.

Thanks for the feedback.  I'm actually of the opinion that backwards compatibility is critically important.  There are many examples of hardware platforms that fail due to lack of market or software support so servicing the retro market for this platform is very important as the basis for continued work.

I do agree that it is worth taking another look at.  I personally would be willing to give up some performance for stability but only if it was relatively small since part of the elegance of AOS is it's light-weight and high performance profiles.  I also think many smart people have already looked into a purely software solution which is why the change of approach is required to make progress.

@Gunner

Is there any value in a new mode for the MPU to help with this?  I'm asking this without an understanding of the current structures in your MPU.  Could the MPU have a mode where the writable pages are defined in a page table by process but the entire memory space is accessible/readable.  This would allow processes to read anything but only write to areas that are allocated to the process as managed by the OS.  This would only help if processes only read data defined by other processes and didn't update it.  If that is not the case I humbly withdraw my suggestion.

i remember haynie even had an experimental prototype cpu card with two 68k on it. i remember there was talks about memory protection for future updates. it never came only because commodore died.

Currentely we still use Motorola tech, improving it (in a reasonible scale, since FPGA are not offering infinite room for all the ideas we would like implement).

Current state does not allow to modify the AmigaOS3.X in a manner that SMP could be implemented, so well, we can discuss hours, it is normal, the topic is passionnating, but current arch still offers a large spectrum to have many funs with it.

the amiga design you know so well was not meant to be the end of it.
there was updates planned. that is my whole point.

Thanks.  I do understand the difference in implementation between Unix and AmigaOS.  Back in the day I did X Windows development and even a bit of kernel hacking in FreeBSD.  I'm over 20 years out of date but still understand the high level concepts.

I don't want to make AOS/AROS like Unix and I'm not too interested in a hosted environment (ARIX/UAE/ABox/etc.).  My joy, as I'm sure with many here, is the elegance of the 68K based hardware combined with the original OS.  I just have a feeling we could do more with the OS in a complimentary way similar to what you've achieved with AMMX.

The context switch to the kernel in Unix is what allows for memory protection along with the hardware abstraction layer.  I'm not interested in that overhead.  However, some of the examples you sight could still be done with read-only context (mouse position, fire button, etc.).  Blitting to screen memory would be a write but also into an area of memory that could be public and less risky.

Perhaps I could start a separate thread to gather all of the standard mechanisms that require direct memory access and try to build a suggestion for providing a good approach.  The worst that could happen is that I confirm and document for everyone's benefit that it is not possible.  :)

@Mr Niding

Thanks for the follow up.  Wasn't sure if I needed to add more.  And thanks for the welcome.

@nsklaus

Thanks for the feedback.  I think perhaps your passion is coming through a little strong.  I don't think Gunner is lacking in imagination but perhaps has different priorities.  He's seen the problem many times - as we all know this is not a new idea - and wants to make sure we keep true to the Amiga philosophy.  I say thanks for keeping us honest!  Hopefully, our different opinions can make the ultimate solution better.