@ppcamiga1

There is Amiga skin for Linux, it makes not sense to replicate that.
I believe it only make sense if AmigaOS offer something different,

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

A skin does nothing to functionality. It’s a weird thing, but I totally agree with ppcamiga on this - an Amiga user interface (not a “skin”) reimplemented on top of Unix is where the OS should go (ot rather, should have gone, a quarter of a century ago.) Using a BSD would be less complicated commercially, than using Linux, and there is one BSD around with quite s few Amiga connections already…

Last edited by kolla on 24-Oct-2021 at 06:56 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@NutsAboutAmiga

Amiga is something different... expecially on "classic". You have different hardware and OS, all is relative simple to understand. That is very different from modern platforms you use today. To make it modern you have to change all that. I really do not see people being attracted by that. I already have something modern I use every day... no need for another platform ;)

@kolla

I think Michal more or less tries to implement such a concept already, only having limited time. Currently working on Emu68 mainly (as I understand it)

So perhaps "when it is done" ;) we can boot in such a new unix-based environment with some amiga-feeling. Or MorphOS team completes the X64 port of MorphOS.

Even on Aros you can already buy dedicated hardware...

https://www.aeros-os.org/rapidcartpro/index.php?product/page/102/AresOne+2018

As I remember Pascal did a clone between Linux and Aros adding lots of linux software. But as I understand it he did not sell many computers. The reality is nobody waits for "another obscure OS" or a new linux distribution. You would need to really find a niche to create interest. A linux skin certainly will not do that.

@OlafS25

Emu68 is not Linux, but rather a very thin standalone 'pico' operating system that could then host a real operating system on top of it, using 68K as a bytecode. This is why he needs also device drivers for say, rPi hardware.

@kolla

for once you speak sense, DragonflyBSD would be a good basis for a new Amiga if Matt could be persuaded to exercise his talents

Off topic but I started the thread so who cares. One possible way to make a nice Amiga-like future OS would be dragonfly BSD underneath a virtualisation layer that gave you an Amiga-like environment that let you run native code for critical sections (codecs etc.) just like how Android does it, together with a run time environment that basically gives each process it's own clone of the operating system state, such that it can do what it likes with that state without bringing down the system.

_________________

@Mobileconnect

you did not understand me it seems... he works on two projects, a merge of linux and aros he calls arix and emu68. Emu68 currently has priority

Last edited by OlafS25 on 24-Oct-2021 at 08:59 PM.

At least for me, Amiga is something based on a microkernel where things are lightweight and all is well optimized with hardware.

For sure I will not consider Amiga something based on linux, simply because it's whole another thing and we have altready much distros in all flavors.

Something based on Linux with an Amiga API (ARIX) could be interesting but, under the wood, we have still Linux with it's monolithic huge kernel and pedantic system.

Maybe Amiga should go to embedded market, becoming a full RTOS system, perfect for specific and critical tasks,

Single board systems or MiniITX/ATX hardware based on arm/risc-v/powerpc/fpga 68k faster like today smartphne's chips could be a viable way to concentrate devlopers on a single board and use a 100% it's full potential.
Just like in the past was done with a500/a1200 or today in modern consoles.

My2Cents.

Last edited by Fl@sh on 24-Oct-2021 at 08:38 PM.
Last edited by Fl@sh on 24-Oct-2021 at 08:28 PM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@OlafS25

Don’t confuse Amiga and AROS ;)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

thanks corrected ;)

Mobileconnect Quote:

No different from Mac OS 9 in that respect. As you and others observe, As DOS->NT and MacOS9->OSX requires a complete break with the past, with the past supported only through sandbox based emulation.

Ironically, later versions of the 68k Mac OS used CAS and even CAS2 instructions (there was a CAS2 bug in early revision 68040s which handicapped Mac OS but had no affect on the Amiga). CAS and CAS2 are important primitives for preemptive multitasking and SMP if used correctly and carefully. Enabling preemptive multitasking and SMP in the Mac OS would have been dangerous because programs assumed they were operating in an uninterruptible single tasking environment.

Mobileconnect Quote:

My point is how can we make current gen AmigaOS more robust, in the absence of a next generation successor to Amiga (of which Haiku is probably the closest one will ever get).

Amiga programs are in a little better situation as they assume they can be interrupted except when in a forbid or disable state. This is adequate for uniprocessor preemptive multitasking but programs executing on other cores follow different rules. The cores themselves are often similar and follow the same rules but relative to each other fewer assumptions can be made than for a task which has switched with multitasking on the same core. All tasks on the same core have a sequential order, memory writes are immediately available to reads and locally atomic (uninterruptible) instructions accessing memory are adequate for keeping other tasks on the same core from altering memory at the same time. Perfectly working Amiga programs which make these assumptions will likely fail with SMP and this affects robustness. For example, library open functions on the 68k use code like the following.

addq.w #1,lib_OpenCnt(a6) // atomic locally on the core but not globally

An interrupt for a task switch is delayed until after the read-modify-write instruction completes so it is safe for multitasking on the same core. For multicore, this should be changed to use a CAS instruction or with PPC load and reserve with store conditional (lwarx and stwcx) but these only work with naturally aligned 32 bit loads and stores and the datatype is 16 bits. PPC programmers may try to use sync, eieio/mbar or msync instructions around the load and store but this is inadequate as other cores can access the same data and memory updates which this triggers may not be visible to other cores immediately. The weak memory consistency model of PPC practically allows chaos between the cores with few ordering or timing guarantees and which violate the guarantees which apply to preemptive multitasking on the same core. The weak memory consistency model allows cores to execute code at full speed independently and to have memory that is far away and may have large delays for some memory accesses (PPC is derived from POWER where NUMA is useful). PPC code which is not compatible with SMP using a weak memory consistency model will have to be found, fixed and tested which will likely take much longer than enabling SMP. Turning off SMP when a Forbid() or Disable() is encountered may be easier for the PPC developer as tricky code is likely to be encountered in this state and wouldn't need to be fixed but SMP will never be efficient with this kludge which grows with the number of cores.

It is possible for hardware to have a different memory consistency model which more closely resembles that of uniprocessing preemptive multitasking and human reasoning. A sequential consistency model between cores has been used before. It was originally thought to reduce performance too much but new methods and processor designs have been found to reduce the performance loss.

Multiprocessors Should Support Simple Memory-Consistency Models
http://www.ai.mit.edu/projects/aries/papers/consistency/ieee_computer_31_8_aug1998_p28.pdf

I believe it would work best with more closely integrated cores so it should be UMA only (no NUMA) and probably limited to fewer max cores. This would be a nice configuration to support HSA with an eventual integrated 3D GPU like consoles are doing as well. The big limitation is how fast electricity can travel in order to keep all data consistent as lines need to reach all cores. Read and write consistency may be possible simply by cores sharing the same write buffer (which is used for much more than buffering writes these days including, level 0 like caching allowing reads and writes, write combining and write grouping to sequential addresses). I believe custom hardware could help reduce the kludge cost of Forbid() and Disable() as well even though these should be eliminated on newer AmigaOS software for SMP efficiency.

The above paper gives some code snippets of code which will fail with the PPC weak memory consistency model. The following link has more if searching for PowerPC as well as a huge amount of information about memory consistency models.

Memory Consistency Models for Shared-Memory Multiprocessors
https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-9.pdf

@NutsAboutAmiga

New Amiga will be unix based or it will stay "modern retro"

@ppcamiga1

I always think the future is in between actually.
and don’t think its one or the other, like so many things lately,
I’m sure everyone find there Amiga Kick.

I think give developers time to update their software, a lot software will be updated, already a lot is improved, and won’t think about using 32bit filesystem, or API does not support files above 4Gbytes, or partition above 4Gbytes, when better API is available, people will migrate to it.

Things like FindTask, and FindPort need to marked as obsolete, I’m sure there other stuff too.

Even if AmigaOS become a Unix skin, you can’t use the OLD API’s anyway, because then you be stuck in a single treaded.

Last edited by NutsAboutAmiga on 25-Oct-2021 at 03:44 PM.
Last edited by NutsAboutAmiga on 25-Oct-2021 at 03:38 PM.
Last edited by NutsAboutAmiga on 25-Oct-2021 at 03:31 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@ppcamiga1

There are two main parts to an operating system. The unseen part - kernel, DOS etc, and the seen part - user interface, user experience.

The unseen part of AmigaOS is a dead end - great for it's time but not useful in a 64bit, SMP world. But there are abstract attributes of the Amiga's approach that I think people would want to see carried forward - two specifically would be "raw performance" i.e. getting the most performance possible out of the given hardware, and simplicity - notably, parts of the system named for what they are and do, no 8.3 DLL names or too-short Unix command names. Together both of these could also be considered to create 'efficiency' like, maximum code reuse through shared libraries.

Then there is the UX part. That part should look, feel, smell, taste like an Amiga as much as possible. The way you interact with software shouldn't change much and should retain it's famous user friendliness, with incremental improvements not fundamental changes, like, no close button moving to the top right!

Ironically one could say both NextStep Mach kernel and BeOS successfully implemented what a next-gen of the Amiga OS unseen core could have been. Moreso than Linux or NT kernel ever did anyway.

_________________

@Mobileconnect

Just to touch on the message port issue. Since I just found the thread. The message port one isn't too common but I think this relates to an old OS example to put a message to port safely. In this case you don't have a port but a port name. So you need to locate the port and put a message before it is removed. This is a simple locking situation as a port needs to be locked in place if it is found.

https://wiki.amigaos.net/wiki/Exec_Messages_and_Ports

It's only needed for external ports like locating an ARexx port and doing it on the fly. It would be easy enough to add a flag for locking. So it it was removed it could be deferred. Of course then the system needs to know when it is unlocked. A dead port could be another flag.

As above the Forbid() is in place to stop the rug from being pulled out from under your feet. Pretty much all forbidden operations are like that. It stops it being removed as well as beng modified before the list is updated.

PutMsg() is very sensitive and must run inside a Forbid(). Major system function. It pretty much needs to lock the port from interference, attach a message, then releasse. Sounds simple. Guess the message port issue is a core issue after all.

Last edited by Hypex on 25-Oct-2021 at 05:04 PM.

@Hypex

Mobileconnect suggestion is keep zombies around, not dead, nor alive, some exists for time after death. I’m not sure I trust something like that to be safe.

Mark it as dirty instead of delating it at once, I think also result in ports have lots unhandled messages and other strange issues. (if not handled by open application.)

Last edited by NutsAboutAmiga on 25-Oct-2021 at 05:29 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@ everybody

it's how it's done in the real world (JVM, CLR, NT Kernel etc etc), so don't be afraid.

_________________

@Mobileconnect

The problem with unseen part Amiga Os is it is dead end.
Amiga Os never be fast and modern unless unseen part Amiga Os will be dropped.

@ppcamiga1

I think that's what I said isn't it

_________________

@Mobileconnect

JVM has garbage collector, it’s not the same, NT kernel / Windows has lot blue screens.

I think it be better to have dual boot

Option 1: “old” AmigaOS4.1++
Option 2: AEON System4.2 (quad/dual core)

And then just need sort the apps, that run on dual core vs single core.

Apps for AEON System4.2 (dual core) can be backward compatible with AmigaOS4.1, but not the other way around. then just have slowly move things over...

Maybe ELF loader can pop with a warning or something.

Last edited by NutsAboutAmiga on 25-Oct-2021 at 07:41 PM.
Last edited by NutsAboutAmiga on 25-Oct-2021 at 07:41 PM.
Last edited by NutsAboutAmiga on 25-Oct-2021 at 07:39 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@kolla

Quote:

It’s a weird thing, but I totally agree with ppcamiga on this

Yeah, so do I. It's not like AmigaDOS, AFFS, etc. where all that great anyway.

_________________
"Unix is supposed to fix that." -- Jay Miner