Decreasing compatiblitiy of OS4 a good thing?

I
As a question: I am not really sure about the issue of moving forward.
If OS4 becomes "differently compatible" in the future, why is it so problematic for some people?

The current version of OS4 won't suddenly stop working! If any incompatibility arises a second partition on the internal storage with AmigaOS 4.1 Final Edition Update 3 will "fix it".

Then there are all the "Misters" and "Misses" and Vampires and #?A(6|12)00#? out there, that can run AmigaOS 3.3. So what is the problem?
Our current "NG" hardware should be NG.
No need to cripple it just for the sake of wanting to use 68k software.

Maybe I am alone here, but I would like to use my X1000 and X5000 and the coming Mirari at full potential. With all the cores available on the CPU-die.
And I would really like to have a system that does not "GrimReap", partially freeze and then leaves me with no possibility to save my work because the mouse and keyboard stopped working.

Stability has come a good way, but we are not there yet. Especially when running 68k software.

I am not a developer, but a fairly modern Webbrowser seems really improbable to me when I read about all the hurdles on the way. The endianness, Unicode, memory protection, and I think it is a matter of time until we are at a wall again with 32bit vs 64bit.
About the memory there is this Extended Memory Object, yes, but it somehow feels as a clumsy patch to me.

I read so often that "we" would like to watch movies and watch YouTube (or whatever streaming platform) but how do we achieve this with one core on a (here some cheers for you all PPC-is-dead aficionados) 10-years-old-dead-PPC-Processor?
Using 6 years old Graphicscards?
They are starting to post 8k video on YouTube, 4k becoming quasi-standard.
And besides videos, there really is the need of raw-power to decode some websites today!

Either you all folks have hope and believe new Amiga-hardware will be released with a super duper mega processor with Mega-giga-performance on _one_ single one of its x-cores, or we should hope that the OS will make full use of our still powerful "dead PPC "double or quad-core processors.

@kas1e

Quote:

Yes, I remember, thank for the clarification.

Quote:

I indeed would like 64bit, unicode, proper multicore support and whatever magic to make the system stable, with the mouse and keyboard (so the USB-stack) working. More then a couple of times the keyboard/mouse stop working while I can see the clock ticking, but no way to do anything.
Or the GrimReaper showing up, and then it's better to not click it, but close everything and reboot. Because clicking on "kill app" will brings the system down anyway.

I concur with you with sandboxing 68k and make it easier for developers to develop, debug and port software.

Also like many here, I don't want a Linux "clone". I think the NG-kernel which is been worked on, is a good thing.

I am ok with breaking compatibility when it brings a better system and new software. I am only surprised that consensus seems to be that breaking compatibility would be general a good thing. I remember very good that people not wanted to use AROS because there is no 68k integration like Petunia and it not "feels" enough like Amiga.

In my view the break between classic and NG should have happened with day one and not inheriting many of the limitations of classic amiga. Now it is already late for it. And it is the question if the development resources are there.

@OlafS25

There ways to do this with out it feeling sluggish, or alien.

https://www.youtube.com/watch?v=DUgzXX2_aDQ

We can trick old programs to see different sets of libraries..
or we can use OS4 interface version system, so that new programs use newer API’s and older programs use wrappers. We don't need to remove 68K support its maybe not needed.

Just wondering how others use E-UAE.

I emulate an Amiga classic with AmigaOS3 on my OS4 system.

I use a very old version of E-UAE.

I run the emulation in fullscreen mode, so the "classic" Amiga Workbench appears to take over the entire screen. The Workbench screen opens with a RAM disk and Workbench disk. The Workbench disk contains drawers just like on a classic AmigaOS3 system.

I have three different configurations:
- an Amiga A2000HD running AmigaOS 3.1
- an Amiga A2000HD running AmigaOS 3.2.3
- an Amiga A1200 with UAEGfx running AmigaOS3.2.3

I set up the first one many years ago. It has alot of software from my original Amiga A2000HD computer.

The second one has AmigaOS 3.2.3 and some of my old favourites.

The third one has GlowIcons and a higher screen resolution but uses a huge amount of RAM on my host OS4 system.

So basically, I am running an AmigaOS3 Workbench on top of my OS4 system. I know how to mount adf files as floppy disks, but so far I have not required access to my printer or my network from inside the emulation.

---

Some of the comments above appear to suggest another way to use E-UAE.


---
redfox

@redfox

No, we talking about running AmigaOS4.1 on top of AmigaOS4.2, or some kind of VM / Sandboxing.. like docker.

Whats new in latest EUAE for AmigaOS4.1 has support for native memory copy, and bsdsocket emulation, far easier to select configurations.

the UAE for A600GS / A1200GS, has extensions to ARM host library, and many parts of the system runs on it take advantage of that.

JanusUAE for AROS, integrated AmigaOS3.x applications into the AROS desktop.

@LiveForIt

Thank you. I really appreciate your explanation.


---
redfox

@all

Interesting discussion. My first reaction to this thread's title was "of course not!" However, I see that the discussion is much more nuanced.

Adding essential modern OS features will definitely need a backward-compatibility break. But, that doesn't mean that we can't maintain the ability to run old AmigaOS software via a sandbox of some sort.

I put some thought into how this could be done a while ago, and recorded it in my "Saving AmigaOS" series. I see some similar ideas being thrown around here. The "Saving AmigaOS" series is part of the Kea Campus Archive, which is available here.

Hans

The definition of "68K support" has meandered over the course of this thread, but it appears to come down to Exec's current design holding back SMP and introducing security and stability issues. I'm not currently much of an Amiga developer, so can't get much more technical than that. From what I recall of the Hyperion "legal papers" posted to another site, their mandate was originally a quick and dirty port to PowerPC. I think the original idea was that OS5 would be along shortly (within a decade?) and this would be good enough. But there was no SMP when all this was being worked out, and here we are 20 years later.

I don't know where @LiveForIt gets his information, but if this is the current state of Amiga SMP

Quote:

then yes, something has to change. Apparently the Extended Memory API for virtual memory is quite straightforward, but even that doesn't get used. Part of me wishes this could be put off until we've done everything once -- hello new sound API, new printer API, Unicode, NGFS for everyone, etc.! But again, here we are.

I'd love a fancy system using a real hypervisor (would like to try Linux NixOS sometime), but the quick and dirty solution this time does appear to be further integrating EUAE. I wonder if the interest in this thread mirrors A-EON's and Hyperion's priorities? OS 4.2 without real SMP would be a great disappointment.

And it has officially turned into amigaworld.net. Congratulations!

@tao

forget DE/AA OS5, it was Amiga Inc project, that is out of the picture..

Not a lot information has shared about sate of SMP in AmigaOS4.1..
so we left guessing...

The fundamental issue for SMP is that core do not see the same content, etch core has unique L1 cache.. when data is shared between the core, the L1 cache, most be synchronized.

https://www.youtube.com/watch?v=r_ZE1XVT8Ao
https://www.youtube.com/watch?v=7yrK_9PderQ

protocol-driven cache coherence, has a lot issues.
1. Lack of Scalability (The "Bus Traffic" Problem)

Snooping Protocol Limits: Common hardware protocols often rely on "snooping" (broadcasting) to inform other cores of changes. This works well for a few cores, but as the number of cores increases, the traffic on the interconnect bus becomes a massive bottleneck, slowing down all processors.

2. High Performance Overhead (Latency and Bandwidth)

Coherence Misses: In a multiprocessor system, if multiple cores constantly write to the same data (false sharing), the hardware must invalidate the cache lines in other cores. This leads to high cache miss rates, which are far more costly than simple memory latency.

3. Inflexibility and Inefficiency

the basic issue you can do protocol-driven cache, but it inefficient, because flushes caches too often, you want the OS to control this..

this comes down to ownership of the data, what core has accessed what data, you don't want the cache to be flushed when its not needed, but you do want to flush it, if you most do so. so keeping tack of what core, did what when. to what data..

"to what data" part is the issue in AmigaOS..

Its up to AmigaOS programs to snoop public lists, because there is lack of locking mechanisms, that specify what data, that is locked, we often have to use the most powerful tool to get ownership, by disabling multitasking, for short periods. Instead of proper lookup functions. Lets say I want to obtain a task or process structure by pid, without blocking the OS, and without risk of reading something that might be freed from memory, without notice. Maybe I want to obtain a msgport by name. There is function called FindPort but does not guarantee ownership or shared lock. The msgport can be deleted without notice. unless you prevent other task form running.

@LiveForItQuote:

Interesting video, thanks! I could follow and more or less understand up until AWS Lambda, then I was lost.

@OlafS25

Whenever a subject of this nature is brought up in any Amiga forum, I remember all of the doom-and-gloom in the Amiga magazines around 1989-1990 concerning Workbench 2.0 being incompatible with around 60% of the Amiga software at the time. When 2.0 came out, I upgraded. I eventually got a kickstart switcher to run old games. I found the upgrade worth it even though it introduced some incompatibility. If AmigaOS 4.3 or higher breaks compatibility with 68k, there will be workarounds. The new features will be worth the change in my opinion.