@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Who says I have time for that?

But you have time to continually write on the same argument...

Last edited by cdimauro on 21-Dec-2015 at 08:52 PM.

@cdimauro

And you have the time to be say nothing is possible.
I wonder if you put your time to better use what might you have managed?

But then again you are the type who says nothing is possible, so you’re the type who won't even try.

Last edited by NutsAboutAmiga on 21-Dec-2015 at 08:58 PM.

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

@cdimauro

Quote:

and show me concretely how to do it.

What should do emulated enviroment in my idea:
1. Runs like full system emulation (eg. QEMU) in background
2. Comprise full legacy PowerPC OS ("guest") with 68k compatibility and drivers/wrappers for better integration with "host" OS (file sharing, clipboard, 3D, USB)
2. Be able to open like transparent backdrop over any screen, so "guest" windows appear to be part of said "host" screen (not a problem - eg. phoenixconsole uses this method for Linux applications in his AROS distribution and similar method is used in A-Eon´s ALICE).
3. Ability to share some basic settings (GUI, Screens, Font etc.) would be nice, but not mndatory

What should do native enviroment in my idea
1. OS recognises PowerPC or 68k application an runs it in emulated enviroment (this part is easy)

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro And you have the time to be say nothing is possible.

Of course, because I know how an Amiga o.s. works.

And I'm not the only one. You can ask what OS4/MorphOS/AROS core devs think about such argument.
Quote:

I wonder if you put your time to better use what might you have managed?

I better use my time for other, concrete, projects.
Quote:

But then again you are the type who says nothing is possible, so you’re the type who won't even try.

Because I don't need to spend so much time for such kind of impossible mission: it's intuitive that it cannot work, and any dev with enough experience and expertize can tell you the same thing.

Of course, provided that a 64-bit o.s. doesn't put any non-sense constraints to 64-bit apps (see my previous comments about it. E.g.: a 64-bit o.s. that cannot work even if there's 1TB of free memory).

@pavlor: AROS integration works similarly, albeit I haven't checked 3D, and USB.

Quote:

blizz1220 wrote: Just bought some Silverlit Tech 50 in joystick that does 8-bit games (sadly no C64 ot even NES) and new generation runs 16-bit games. Motherboard is about 1.5x2 cm wide and components seem like they can be made for peanuts.

I couldn't find any info on this product but I presume it is a gaming computer in a joystick. At 1.5x2 cm for the motherboard, I expect if it uses an ASIC instead of an FPGA at that size. An ASIC would limit the flexibility of simulating more hardware but lower the cost to produce a large quantity of units and reduce the motherboard size. I would want something more expandable than a computer in a joystick but the motherboard could be small enough for a large game controller. The Natami motherboard is 17x14 cm but it could be significantly smaller with SATA instead of IDE and moving the ethernet and maybe USB into the FPGA/SoC. The MiniMig is 12x12 cm, the FPGA Arcade is 14x10 cm and K.C. Lee's Mist clone is 10x10 cm but they lack modern expansion.

FPGA projects are proceeding on their own but they have no AmigaOS support. Jim Drew needed the P96 developer driver kit for the FPGA Arcade for example. AmigaOS 68k support would encourage development. The only way to gain substantial outside developer support is to have a large enough hardware base and PPC is not achieving this. AEON/Hyperion can either block (but not stop) the FPGA development or they can get on board and help with the AmigaOS and maybe even support the next generation of 68k FPGA/Amiga hardware.

Quote:

On the other hand if Apollo went ASIC wouldn't it kill any income Freescale (or whoever owns it now) has from selling spare 68k chips ? Could be problematic in that case ...

I don't expect it would be a problem. Customers who need and can afford the exact old chips for replacements will still go to Freescale/NXP. The 68k is dead to Freescale/NXP. ColdFire (and PPC) are still used in a few niche products but ARM is likely to replace them also. Gunnar asked Freescale if they had a problem with the Natami project 68k core and they replied that they did not.

Quote:

cdimauro wrote: That's normal: the Amiga o.s. lacks any kind of modern feature, and this requires execution time and more code.

Better tell A-EON/Hyperion that the AmigaOS lacks "any kind of modern features" after all their years of development :D.

Quote:

But the main problem here is that the Amiga o.s. uses a lot of assembly code. So it's already pretty efficient.

The AmigaOS is mostly written in C. The exceptions I know of are the exec.library and FFS.

Quote:

Rewriting it mostly in C would work well, however this will generate much fatter binaries. AROS/68K is a clear example: it requires 1MB (albeit there's some space left empty) offering more or less the same features, whereas the Amiga o.s. 3.1 occupy half... [quote]New features can be added where the AmigaOS is lacking to scale it up. Minimal changes have been necessary to allow the AmigaOS to be a fairly modern OS and it has been able to keep good compatibility so far. We will see if that holds when adding SMP and 64 bit addressing support.

The big problem is lack of compiler support for the 68k because there is a lack of hardware. Fortunately, the 68k is not as handicapped with poor code as the PPC. You know I have always looked at compiled code and advocated for ISA changes which simplified compiler backends. I have some ideas for compiler enhancements but I'm not very motivated without more and better hardware.

Quote:

64-bit means dropping compatibility, whereas SMP is hard to accomplish, but an FPGA can help (monitoring the infamous o.s. counters for tasks and interrupts). But there are still missing resource tracking, memory protection, and multiuser.

I agree that 64 bit pointers are the real compatibility killer. No more small footprint any more either. There are other ways to increase memory which should be investigated. SMP should be possible with hardware help but otherwise keeping compatibility is going to be difficult. I don't think resource tracking is difficult but there is limited advantage without memory protection. Partial memory protection can be easily added but full memory protection would likely reduce compatibility and performance. The Amiga multiuser support should be improved but will never be secure without breaking compatibility.

@matthey

Quote:

Better tell A-EON/Hyperion that the AmigaOS lacks "any kind of modern features" after all their years of development :D.

I don´t think they would care. Cdimauro is not their customer.

Quote:

Fortunately, the 68k is not as handicapped with poor code as the PPC.

Fortunately, the PPC is not as handicapped with poor performance as the 68k.

@pavlor

Quote:

Ability to share some basic settings (GUI, Screens, Font etc.) would be nice, but not mandatory

That is kind of where I am with my MorphOS wishlist.
It would be nice if the GUI of X64 MorphOS was designed to allow for the addition of PPC support (either via emulation or by a board).

@pavlor

Quote:

Fortunately, the PPC is not as handicapped with poor performance as the 68k.

Or the poor programming practices prevalent in the 68K environment.

Last edited by iggy on 21-Dec-2015 at 10:42 PM.

@matthey

Quote:

matthey wrote: Quote: cdimauro wrote: That's normal: the Amiga o.s. lacks any kind of modern feature, and this requires execution time and more code. Better tell A-EON/Hyperion that the AmigaOS lacks "any kind of modern features" after all their years of development :D.

Already did it.
Quote:

Quote: But the main problem here is that the Amiga o.s. uses a lot of assembly code. So it's already pretty efficient. The AmigaOS is mostly written in C. The exceptions I know of are the exec.library and FFS.

The console too. Are you sure that devices like trackdisk.device are written in C too?
Quote:

The big problem is lack of compiler support for the 68k because there is a lack of hardware. Fortunately, the 68k is not as handicapped with poor code as the PPC.

But it's quite handicapped if you consider that modern compilers don't handle pre/post-increment modes, but only the usual [Reg + displacement] or [Reg + Index * Scale + Displacement]. This way very sub-optimal code is generated for 68Ks.
Quote:

You know I have always looked at compiled code and advocated for ISA changes which simplified compiler backends. I have some ideas for compiler enhancements but I'm not very motivated without more and better hardware.

If Apollo goes in production, it might be a good motivation. But the real problem is that it's still a 68K processor for a microscopic niche.
Quote:

Quote: 64-bit means dropping compatibility, whereas SMP is hard to accomplish, but an FPGA can help (monitoring the infamous o.s. counters for tasks and interrupts). But there are still missing resource tracking, memory protection, and multiuser. I agree that 64 bit pointers are the real compatibility killer. No more small footprint any more either.

But we have plenty of memory. Only 32% of my 16GB are currently used, and the virtual memory is disabled.

The problem with 64 bits is that the pointer size doubles, and code is fatter (around 25% more on x64), however the performance penalty might be leveraged or even inverted (faster execution!) with a better implementation. This happens with x64, because it doubles the general purpose and SIMD registers (from 8 to 16 for both).

Does the 64-bit implementation of the Apollo core provides something similar? It's a big question mark, because there's absolutely no public information about that.
Quote:

There are other ways to increase memory which should be investigated.

Address space separation can help, but it only delays the problem, and it's incompatible with the Amiga o.s..

Bank switching is out of question (take a look at the last FPGA thread).
Quote:

SMP should be possible with hardware help but otherwise keeping compatibility is going to be difficult.

Personally I prefer a polite solution, which doesn't bound the 68K platform to FPGAs-only.

To be clear, it should work with multiple processors connected with a single bus, or with a NUMA configuration.

Using the FPGA to internally solve the Forbid & Disable issues is an horrible hack, and an o.s./platform shouldn't rely on it.
Quote:

I don't think resource tracking is difficult but there is limited advantage without memory protection.

Usually they come both together: if you solve the first, you can use the second. That's because you essentially kill one of the Amiga o.s. foundations: (very easily) sharing memory.

This is one of the biggest compatibility problem.
Quote:

Partial memory protection can be easily added but full memory protection would likely reduce compatibility and performance.

Exactly. You can think about protecting applications' code hunks, which is the easiest thing and less error-prone to do, but it's a very little enhancement over the existing system, with few benefits.

Full memory protection (and resource tracking) should be the real goal.
Quote:

The Amiga multiuser support should be improved but will never be secure without breaking compatibility.

Breaking compatibility is a necessity: see above. Multiuser is the last and easiest thing to implement, after the required effort to introduce all other things.

@matthey

So, what modern features does AmigaOS4.1FE have?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

pavlor wrote: Fortunately, the PPC is not as handicapped with poor performance as the 68k.

Unfortunately, the x86_64 is not as handicapped with poor performance as the PPC and 68k.

Quote:

iggy wrote: Or the poor programming practices prevalent in the 68K environment.

There isn't anything about the 68k that makes for poor programming practices. Older code is more likely to use poor programming practices. Being close to standard hardware is more efficient but gives up some flexibility and portability. For all the 68k assembler I have done, I use the OS instead of banging the hardware where I can and encourage using it. Too many layers of code and obfuscation can give poor performance. This can be a problem when code written for x86_64 processors is handed down to lower performance processors like PPC and ARM.

Quote:

Quote: cdimauro wrote: The AmigaOS is mostly written in C. The exceptions I know of are the exec.library and FFS. The console too. Are you sure that devices like trackdisk.device are written in C too?

The trackdisk.device and a few other small low level devices/libraries/resources may be in assembler but it is nothing major. IMO, these small libraries are generally easier to build, manage and read with 68k assembler. The trackdisk.device is useless now days so I didn't even consider it.

Quote:

If Apollo goes in production, it might be a good motivation. But the real problem is that it's still a 68K processor for a microscopic niche.

Yes, but I tried to change that. I tried to create standards (by a knowledgeable committee of peers instead of an individual) and get people outside and inside the Amiga market interested.

Quote:

The problem with 64 bits is that the pointer size doubles, and code is fatter (around 25% more on x64), however the performance penalty might be leveraged or even inverted (faster execution!) with a better implementation. This happens with x64, because it doubles the general purpose and SIMD registers (from 8 to 16 for both).

That was a particular case of X86 not having enough registers. The 68k and PPC have enough registers already. Some code for the x86 is still faster than the x86_64 because of more efficient cache usage. The 68k and PPC would have only a performance penalty for moving to 64 bit addressing.

Quote:

Does the 64-bit implementation of the Apollo core provides something similar? It's a big question mark, because there's absolutely no public information about that.

I don't believe 64 bit addressing is enabled. Only 64 bit data processing instructions are supposedly allowed by some instructions. At one time Gunnar mentioned that any sized register result could be forwarded without penalty which is needed to keep 64 bit from slowing down the pipeline (also improves performance with byte and word sized operations). I was involved in the Apollo Project and it felt like I was in a need to know environment. Gunnar will not answer questions he doesn't want to answer either.

Quote:

Address space separation can help, but it only delays the problem, and it's incompatible with the Amiga o.s.. Bank switching is out of question (take a look at the last FPGA thread).

I think partial address space separation is possible for future code with a new memory allocation flag. Allocations without the flag would be addressable from every task/process while allocations with the flag would be addressable only by that task and swapped out when other tasks are running. This would require an MMU and some hardware support but could give several GB of memory per task. Something like 32 bit versions of the 68k SFC and DFC registers could be used for this and changed on task switch.

Quote:

Personally I prefer a polite solution, which doesn't bound the 68K platform to FPGAs-only. Using the FPGA to internally solve the Forbid & Disable issues is an horrible hack, and an o.s./platform shouldn't rely on it.

Polite is preferred but compatibility has priority. As long as it is not a major kludge there is not a problem if owning the FPGA code and manufacturing your own SoC. It should be possible to turn it off when using other operating systems.

Low end Amigas do not have to have 64 bit addressing, SMP, memory protection, resource tracking or better multi-user support where they are expected for a high end computer. Good performance on low end hardware is just as important and the Amiga was semi-professional back in the day without most of these features. What is easy and an improvement should be added in a modular way though.

Quote:

kolla wrote: So, what modern features does AmigaOS4.1FE have?

It depends on what you consider modern. Of the big 5 features mentioned:

1) >4 GB of memory
2) SMP
3) memory protection
4) resource tracking
5) multi-user support

I believe it has partial support for 1, 3 and 5 not that I would buy it for these reasons. AmigaOS 4 systems are currently out of my budget range regardless of these features.

Last edited by matthey on 22-Dec-2015 at 02:17 AM.

@matthey

Quote:

matthey wrote: Quote: cdimauro wrote: The console too. Are you sure that devices like trackdisk.device are written in C too? The trackdisk.device and a few other small low level devices/libraries/resources may be in assembler but it is nothing major. IMO, these small libraries are generally easier to build, manage and read with 68k assembler. The trackdisk.device is useless now days so I didn't even consider it.

Sure, but it was just to say that I don't think that only a few things were written in assembly. Our historian "in pectore" sustains that the first OS4 version was running with only Exec ported to PowerPC (mostly C code, and some PowerPC assembly to handle the usual stuff: interrupts & task switching, signals. I suppose), and the rest was running with 68K code.

So it might be that the 68K code wasn't limited to small part of the o.s..
Quote:

Quote: If Apollo goes in production, it might be a good motivation. But the real problem is that it's still a 68K processor for a microscopic niche. Yes, but I tried to change that. I tried to create standards (by a knowledgeable committee of peers instead of an individual) and get people outside and inside the Amiga market interested.

That's not possible, because the 68K is a far west world by now: everybody can do, and do, whatever he wants.
Quote:

Quote: The problem with 64 bits is that the pointer size doubles, and code is fatter (around 25% more on x64), however the performance penalty might be leveraged or even inverted (faster execution!) with a better implementation. This happens with x64, because it doubles the general purpose and SIMD registers (from 8 to 16 for both). That was a particular case of X86 not having enough registers. The 68k and PPC have enough registers already.

Not enough for the 68K, since it runs out of address registers (for pointers / memory addressing).

x64 has solved the problem, because all registers can be used as data/index or address/base registers, indifferently. You can better organize them, as it's needed.

ARM got also a big improvement when switching to the ARMv8/ARM64 architecture, because of the 16 registers that were added plus a special handling for the spare address bits that are used to mark pointers with useful metadata. You can take a look at some benchmark which AnandTech made, on the same iPhone, with the same code compiled for 32 and 64 bits.
Quote:

Some code for the x86 is still faster than the x86_64 because of more efficient cache usage.

That should be a rarity, because what I've seen 'til now is a performance improvement, with the worst case represented by essentially the same speed.

Do you have any example of code like that?
Quote:

The 68k and PPC would have only a performance penalty for moving to 64 bit addressing.

For PowerPC it's correct, and the same applies to the 68K if it stays the same (see above).
Quote:

Quote: Does the 64-bit implementation of the Apollo core provides something similar? It's a big question mark, because there's absolutely no public information about that. I don't believe 64 bit addressing is enabled. Only 64 bit data processing instructions are supposedly allowed by some instructions. At one time Gunnar mentioned that any sized register result could be forwarded without penalty which is needed to keep 64 bit from slowing down the pipeline (also improves performance with byte and word sized operations). I was involved in the Apollo Project and it felt like I was in a need to know environment. Gunnar will not answer questions he doesn't want to answer either.

Well, announcing a feature and giving zero information is exactly like not having the feature implemented.

Anyway, if the (data, I suppose) registers were expanded to 64-bit, it requires a proper kernel to handle them.
Quote:

Quote: Address space separation can help, but it only delays the problem, and it's incompatible with the Amiga o.s.. Bank switching is out of question (take a look at the last FPGA thread). I think partial address space separation is possible for future code with a new memory allocation flag. Allocations without the flag would be addressable from every task/process while allocations with the flag would be addressable only by that task and swapped out when other tasks are running.

For most 68K applications you only have binaries, so you cannot change them.

In reality there's already the MEMF_PUBLIC flag which would have been used for this purpose, but unfortunately it was abused by coders, which have almost always set it.
Quote:

This would require an MMU and some hardware support but could give several GB of memory per task.

The limit is still 2GB for the whole address space, and old (binary-only) applications will use a part of it, so there cannot be several GBs of memory per task.
Quote:

Something like 32 bit versions of the 68k SFC and DFC registers could be used for this and changed on task switch.

SFC and DFC are used for specific purposes. How do you think to extended their usage? For me it sounds like a bank switching technique.
Quote:

Quote: Personally I prefer a polite solution, which doesn't bound the 68K platform to FPGAs-only. Using the FPGA to internally solve the Forbid & Disable issues is an horrible hack, and an o.s./platform shouldn't rely on it. Polite is preferred but compatibility has priority. As long as it is not a major kludge there is not a problem if owning the FPGA code and manufacturing your own SoC. It should be possible to turn it off when using other operating systems.

Naturally, but this way you're just setting your 68K "fork" as the only allowed processor. There's no committee: it's only your version. This will increase the 68K far west which I talked about.
Quote:

Low end Amigas do not have to have 64 bit addressing, SMP, memory protection, resource tracking or better multi-user support where they are expected for a high end computer. Good performance on low end hardware is just as important and the Amiga was semi-professional back in the day without most of these features.

I think that, at end, it depends only on what you want to do with your system, because people may want the same stuff for low-end systems. In fact, for anything but the Amiga market, even very low-end systems have them...
Quote:

What is easy and an improvement should be added in a modular way though.

Patching the o.s., I suppose. But you don't have the code for the Amiga o.s..

P.S. Sorry, but I have no time to check for errors on the text.

@cdimauro

Quote:

the first OS4 version was running with only Exec ported to PowerPC (mostly C code, and some PowerPC assembly to handle the usual stuff: interrupts & task switching, signals. I suppose), and the rest was running with 68K code.

Note port did take 3 years. Developement started in 2001 with 68k components, ExecSG ran on AmigaOne at the latest in late 2002. We don´t know exact 68k code share in initial 4.0 pre-release (April 2004), but PowerPC versions of substantial parts (Picasso96, MUI) were released with the next update (October 2004).

@matthey

Yes , I only found some reference on German sites.

It was made in 2006-2009 (maybe) so I couldn't but wonder
if ASIC clone of A1200 motherboard would be possible
today and why isn't anyone kickstarting something like that.

It would be small and all integrated but you can always offer
pins for expansions and ports (like Amiga owners aren't used
to getting rare cables and adapters) and I think it would last
a long time since there is only one or two chips there.

It''s sad Amiga never was big in East otherwise something like that
would be made already looking at current ebay prices.

@pavlor

Is it? you always intentionally leave out emulation

and even if... I still say 15x (15x code base, 15x user base)

15 wins

@OlafS25

Quote:

Is it? you always intentionally leave out emulation

Well, I don´t think anything without MMU is best way for future.

@pavlor

but without software and users there is no future either

And NG lacks unique software that justify using it

@OlafS25

Quote:

but without software and users there is no future either

Right, I simply don´t see myriad of 68k customers willing to do something else than playing classic games.

Quote:

And NG lacks unique software that justify using it

What unique software you have for 68k? There is no logical justification for use of any Amiga-related platform, we like Amiga that is all.

@pavlor

what else should they play? Newer games were not ported to 68k because of lack of both ram and horsepower. And UAE was not supported for some strange reasons.

@pavlor

Hehe, well, your contributions to this thread has been to counter verifyable facts and logic with fairy tales and personal "want-to-be's", so why change your way now, eh?

You are trying to see things that simply isn't there, and those things you might happen to really see, doesn't matter today ayway.

Well, here we go...

Quote:

pavlor wrote: @TRIPOS Quote: Well, that's what they call it, so... Yes Cloanto sells its AmigaOS files under "Workbench" trademark

Dude, it's not "its AmigaOS files", a big error from you there, it's "Workbench" and nothing else! For products available today "AmigaOS" is ONLY describing Hyperion's OS4! The original OS for 68k Amigas is still sold as new, it's being marketed under the "Workbench" trademark. Please don't try to blurry the waters or sneak in parasite marketing in any direction. It's not the same product.

Quote:

but at same time uses amiga-os identificator (Structure and Names of Emulation and System Files)

What? Why are you bringing up the directory structure etc, what does that has to do with anything? Of course it follows the original directory structure, it is the original OS for real Amiga computers after all!


Quote:

and recognises AmigaOS 4 as another version of the same OS it sells (Name of the Amiga Operating System

...and I quote from that page: "One of the many unique points of the Amiga Forever project is its consistent use of the name "Workbench" for the operating system, which as such has become a Cloanto "trademark". Neither "Amiga OS" (with a space between "Amiga" and "OS") nor "AmigaOS" (without spaces) are used in Amiga Forever for this purpose. Cloanto's use of the "Workbench" name for the operating system also helps avoid confusion with projects like AmigaOS 4.0"

Workbench!

NOT!

AmigaOS!

To help avoid confusion with other projects, like AmigaOS 4!

Avoid!

Confusion!

I.E. NOT the same thing, must be kept separated by name for clarity! Again: Avoid! Confusion! Workbench! NOT "AmigaOS"!

AmigaOS 4 did not replace the original OS (Workbench). And to "Real Amiga HW Enthusiasts" (or "Retro" enthusiasts) it was never an "upgrade path". The Workbench OS for real Amiga computers (and Amiga emulators) is still being sold as new and even updated. This has happened for years, in parallell to OS4 development and sales. Therefore, AmigaOS 4 can at best be described as a fork of the real Workbench system, i.e. NOT "another version of the same OS" as you falsely described it.

Again: Avoid! Confusion! Workbench! NOT "AmigaOS"!


Quote:

Distribution of CBM/Amiga ROM and OS Files etc.).

The highlight from that page is no doubt the "Q: Can I include ROM and operating system files in my web site or app?"

Regarding Cloanto's recent rather liberal stance on respecting Copyright laws (for ROM's none the less (the PowerUP ROM they seem to have bundled in Amiga Forever without license)), this surely made more people than me chuckle a bit...



Anyway, you keep referring to random web pages with rather pointless and academic discussions of names from a historical perspective.

Absolutely pointless! Please stop wasting precious bytes on the Internet for this!

All that matters today is today!

And today we have four OS options (in various versions), for different HW platforms and different needs and wants.

First we have:

1) Workbench, which is the undisputed original, for real Amiga's, it's owned and marketed by Cloanto, using the "Workbench" name. It's available in these versions:

Workbench 1.0
Workbench 1.1
Workbench 1.2
Workbench 1.3 (Also sold separately of the emulation package, for real Amigas, with minor updates)
Workbench 2.0
Workbench 2.04
Workbench 2.05
Workbench 2.1 (Also sold separately of the emulation package, for real Amigas, with minor updates)
Workbench 3.0
Workbench 3.1 (Also sold separately of the emulation package, also in physical media, for real Amigas, with a few significant updates)
Workbench 3.X (The latest and most developed, AFAIK currently only available through the Amiga Forever 6 emulation package)


Then we also have the three "NG" branches:

2) AROS, for various platforms

3) MorphOS, for 83 PPC systems, and a few motherboards on top of that

4) AmigaOS 4, for AmigaOne and PowerUP systems, published by Hyperion, and this is the only one of all the above using the term "AmigaOS" for a product today!


Like this:



Note 1: Please focus on the "Today" square only, otherwise we will have a completely new, pointless discussion about various interpretations of the history.

Note 2: Granted, it should say "AmigaOS 4" and not just "OS4".

Note 3: See? One branch of the original OS for real Amigas (today: Workbench), published by the OS owner themselves, and besides that, three different re-implementations for various other H/W systems made by various third parties.

It's really not more complicated than this. It's simple!

Question is why you so fatally fail to grasp this...