@Yssing

Do we even need OS4.x? I can't remember if I've ever even used it? I remember the A-EON X1000 website teaser, does that count?

OS3.2/3.9 surely was the pinnacle? I don't really expect AmigaOS to become mainstream useful ever again! Most companies want us to use Phone OSes on our desktops like ChromeOS! Windows7 and OSX El Capitan were the pinnacle of their respective OS forks! All lowest common denominator, the user is stupid stuff now!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@agami

Quote:

I broached this very topic with him, and he assured me there is nothing legally prohibiting Hyperion from porting AmigaOS 4 to x86 or ARM.

That's cute, since his mantra in the days of X1000 and X5000 was we have to do PPC since we do not have a license for anything other than PPC. By that, I mean parts of the OS, that Hyperion does not outright own, but rather license from third parties.

But I don't think there's any life left in OS4 and neither does Hyperion, hence they have since ventured in the Classic/68K market.

_________________

@WolfToTheMoon

Yes it does look bleak. I do think that the real killer was all those legal battles.

_________________

@BigD

Well 3.2 could have been the next thing in amiga land. Do we need AOS4? that is a good question, in reality we don't need anything amiga, but it's nice to have.

_________________

@Yssing

It surely would be interesting having "composition engine" running on an hardware accelerated gfx driver of pistorm

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@agami

Quote:

agami wrote: @WolfToTheMoon Quote: WolfToTheMoon wrote: @agami On 2) Hermans mentioned several times their OS4 license only covers PPC - not that it would stop him, but at this time, I truly believe OS4 is done and it is dead as a project/platform. I broached this very topic with him, and he assured me there is nothing legally prohibiting Hyperion from porting AmigaOS 4 to x86 or ARM. What might be the issue, and I didn't raise it because it was outside of the scope of our conversation, is that they may only be allowed to use the "AmigaOS 4" label on the PPC version. Which means if they could overcome the major hurdle of not having any funding, they could port it to anything and hypothetically call it "AmigaOS V". Or completely back-port it to 68k+ and call it AmigaOS 3/4.

Thanks to last minute changes in the 2009 agreement that Hermans managed to sneak in, “OS4� is defined as _any_ version of AmigaOS developed by Hyperion, regardless of version or architecture. This is why ThoR and others have been stating that "legally", all variants of OS3 from Hyperion, from 3.1 “update� that was little more than changing copyrights and bumping version strings (mild simplification) through 3.1.4 and 3.2,.. in a “legal state", _are_ OS4. However, in the process they screwed up by marketing it as an update to 3.1 (and heck, it can bootstrap from 2.0) and not as "OS4" for 68k. Also, there’s the thing about “intent vs word� of an agreement - an "agreement" where the parties cannot agree on what’s been agreed upon, isn’t an agreement anymore, and is typically rendered void.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Yssing Quote:

In reality PPC/RISC-V/Arm/X86-64 does not matter at all, since we are currently stuck with aging and expensive PPC hardware.

PPC AmigaOS 4 never competed in the desktop market. The hardware was desktop like but they were niche hobby market systems. Mass production and short development cycles are required for desktop hardware. Competitive desktop features are required for the OS. Billions of dollars invested to become a desktop competitor are unlikely to result in more than single digit percent market share gains. Rather than spending millions of dollars on micro production desktop like hardware, it wouldn't take much more investment for mass produced hobby/retro/embedded hardware. This is what the RPi Foundation did with great success (~50,000,000 RPi vs ~5000 Amiga1). Quick to market and easy to use commodity ARM SoCs were used but there is no production cost advantage due to ARM royalties. A RISC-V or 68k SoC potentially has a production cost advantage as royalties may be avoidable. A few percent royalties may not sound like much but it results in a few percent lower margins for the SoC which is significant when talking about competitive low end hardware.

The Raspberry Pi Foundation has considered using RISC-V.

https://www.jeffgeerling.com/blog/2023/what-eben-upton-said-about-risc-v

The article above talks about the StarFive VisionFive 2 SBC using SiFive U74 cores. Even though the 8-stage in-order SiFive U74 cores and GPU outperform the RPi 3 8-stage in-order Cortex-A53 and GPU, developer support is still immature and there is a lack of RISC-V software. The RPi 3 still has the overall advantage even though the RISC-V hardware is better and the software improving. It takes time to develop and debug software on new hardware which would be the case with porting the AmigaOS to new hardware as well. The 68k AmigaOS is small, stable and standard on existing 68k hardware (Linux/BSD on 68k hardware is also easier than a new arch). We have relatively mature developer support and more software, especially hot retro games. Compatibility and existing software is a huge advantage. I believe it is better to bring competitive 68k hardware to the 68k AmigaOS. The 68k AmigaOS can be relatively easily upgraded with most of the AmigaOS 4 features while maintaining compatibility. The hardware and AmigaOS would need major upgrades to gain modern features but stability, software and compatibility are more important for small footprint very low cost hardware. It is not in ARM's best interest for standard hardware with a production cost advantage and smaller footprint to compete.

https://newsroom.arm.com/news/raspberry-pi-investment
https://iottechnews.com/news/arm-invests-raspberry-pi-influence-iot-developers/

AArch64 is vulnerable because ARM bet when trading in excellent code density Thumb-2 for higher performance AArch64 that the embedded competition was crushed. RV64IMC has better code density than AArch64 but is weak in many performance metrics, especially too many instructions due to simple weak instructions and increased data memory traffic due to weak addressing modes. Thumb-2 had similar performance problems even though it was an improvement over SuperH. The 68k has the extreme code density of Thumb-2 but remains competitive with AArch64 in number of instructions executed and data memory traffic (68k is better at total mem traffic due to good code density). The 68k has better performance metrics than x86 which had good enough performance to knock PPC out of the desktop competition. The x86 advantage of compatibility and software is what really made the difference even though much of the software was old. Politics and propaganda seem to play as much of a role as the tech too.

Yssing Quote:

So if "they" could make a decision and go for an other CPU, then it would matter. I personally do not care to much about code density, I don't work in environments where that matters all that much. It's all academic and pointless, unfortunately, we are stuck with PPC and/or emulation. There was a time where I was all in on PPC, but situations change. I just wish there was a platform with much cheaper hardware. But alas.

Good code density is like having larger caches but with faster access times of smaller caches. Would you rather have faster and larger caches or smaller and slower caches? Do you realize that caches can be more than 75% of a modern high performance CPU by area/transistors?

WolfToTheMoon Quote:

That's cute, since his mantra in the days of X1000 and X5000 was we have to do PPC since we do not have a license for anything other than PPC. By that, I mean parts of the OS, that Hyperion does not outright own, but rather license from third parties.

The 2009 (settlement agreement) contract understanding when signed or the interpretation of the wording today is one of the crucial factors in the current cases. I believe the understanding when signed is more important as the paper contract extends to a verbally discussed contract which is just as valid. Proving the understanding when signed can be difficult though. I believe Bill McEwen testified that his understanding was the contract was limited to PPC. Ben Hermans may try to say otherwise which is why his public "mantra" is now evidence in the case. Perhaps the private e-mail between agami and Ben or agami's forum post could be used as evidence.

WolfToTheMoon Quote:

But I don't think there's any life left in OS4 and neither does Hyperion, hence they have since ventured in the Classic/68K market.

PPC AmigaOS 4 is dead to everyone except Trevor living in his own fantasy Neverland. AmigaOS 4 should be ported back to the 68k AmigaOS and/or forward to be more competitive and modern with compatibility lost.

kolla Quote:

Thanks to last minute changes in the 2009 agreement that Hermans managed to sneak in, “OS4� is defined as _any_ version of AmigaOS developed by Hyperion, regardless of version or architecture. This is why ThoR and others have been stating that "legally", all variants of OS3 from Hyperion, from 3.1 “update� that was little more than changing copyrights and bumping version strings (mild simplification) through 3.1.4 and 3.2,.. in a “legal state", _are_ OS4. However, in the process they screwed up by marketing it as an update to 3.1 (and heck, it can bootstrap from 2.0) and not as "OS4" for 68k. Also, there’s the thing about “intent vs word� of an agreement - an "agreement" where the parties cannot agree on what’s been agreed upon, isn’t an agreement anymore, and is typically rendered void.

Did Ben really sneak in changes? Were there earlier drafts of the 2009 agreement?

My interpretation as written of the 2009 contract is that 1.b allows AmigaOS 4 to be ported to any architecture including the 68k and even allows the version change as development toward AmigaOS 4. However, 1.c grants Amiga IP use for "AmigaOS 4" only so the use of "AmigaOS" and the boing ball logo are lost. It is reasonable to assume that "AmigaOS 4" may apply to AmigaOS 4.x but it is quite the stretch to say it applies to AmigaOS 3.x.

My interpretation partially aligns with and partially differs from what agami said Ben told him in an e-mail.

agami Quote:

I broached this very topic with him, and he assured me there is nothing legally prohibiting Hyperion from porting AmigaOS 4 to x86 or ARM. What might be the issue, and I didn't raise it because it was outside of the scope of our conversation, is that they may only be allowed to use the "AmigaOS 4" label on the PPC version. Which means if they could overcome the major hurdle of not having any funding, they could port it to anything and hypothetically call it "AmigaOS V". Or completely back-port it to 68k+ and call it AmigaOS 3/4.

In my interpretation, they can port "AmigaOS 4" practically anywhere but they can't call it "AmigaOS" anymore. Enter HyperionOS or more like A-EonOS at this point. Amiga Corporation is most likely to win all the chips though.

Last edited by matthey on 19-Sep-2024 at 06:15 PM.
Last edited by matthey on 19-Sep-2024 at 06:02 PM.

@cdimauro

Quote:

To me it looks that you are having some problems: everything is working fine on different PCs, smartphones, and in Incognito (private) mode as well. And the site requires no registration.

I found and removed more cookies. Reload. No change, no translation. Maybe I need to turn off the browser then turn it on again. It's Firefox, maybe it has a new bug, that only just showed up. Tried Chome(ium) and it immediately asks about cookies and translation. Reload and it does again with it stuck in the browser.

BTW, I was unclear on the end, I meant DeepL for an account. If it doesn't need an account it's unclear as a window pops up asking me to log in. I've become critical of UIs giving a bad UX now days. I'm an experiencing expert, bad experiences makes me an expert on what is wrong with it.

Quote:

I can confirm the same: time ago I had the chance to take a look at a few leaked sources, and the code was very well written.

If that's the case, then it makes me wonder, why do I find it buggy on boot? I mean, most of the time I boot Windows on my laptop, I have trouble. It usually takes too long to boot, as when the desktop should be ready it starts thinking. But mostly, my problem is with the file explorer. as I open up a folder and the thinking starts again. I almost always get trouble by simply trying to look into a folder. If I don't catch it first in task manager Windows will eventually tell me the explorer is not responding. It's not that I want to hate Windows but it always seems to give me trouble for no apparent reason. Going from Windows 10 to 11 didn't improve this for me. I don't get these issues with Linux Mint.

Quote:

Nope. Windows NT was available for big endian systems a well. The last: PowerPCs! With the XBox 360 console.

I meant Windows these days. I don't know if it was here or on Amigans but there was a list of Windows NT CPU ports, with all CPUs being little or biendian.

What other big endian systems? I've read a little about the XBox port but what I read is that it wasn't a full port. That it was cut down for a specific purpose.

Quote:

Ehm, no: this example is completely different, since it's a format for DATA. So, when you archive data, serializing them MIGHT require considering the endian as well, but this strictly depends on the format that you define.

That may be different but it is related. They are optimised for x86 and little endian in general. Just like ILBM and 8SVX was for Amiga and AIFF for Mac. The trend continues as a number of formats are LE serialised. As well as for BE.

Actually, here's an old article where I made up a list, where I researched endians.
https://blitterwolf.blogspot.com/2017/08/the-worlds-fastest-endian.html

Quote:

I've read all of his articles about all Windows ports: where is written that Windows (not only NT) RELIES on the endianess?

So I stated it depends on it. I've found a document that states it is designed to run on it. Semantics aside, it's not exactly depending on or relying upon, but it does say designed to here with REG_DWORD_LITTLE_ENDIAN.

https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types

Here it states native scalar types are little-endian for targets I was basing my point on:

https://learn.microsoft.com/en-us/cpp/standard-library/bit-enum?view=msvc-170

Quote:

Linux is just the kernel and it has to interface with the peripherals. There, you likely need to deal with the endianess, depending on the peripheral to be accessed/programmed.

Yes that's what the endian functions would help with. Though they are rather long, like cpu_to_le32, which looks tiring. No one working on the AMD Radeon drivers does that any more since they dropped big endian hardware support.

Quote:

See above: everything is working fine. You've to check with another computer or phone.

That just works around it being broken in my Firefox.

But, I do have a gripe for years, as no one has fixed this in decades. I thought it was every browser that had the bug but I think it's Google. This needs Google results to open in same tab. So, Google a word or string with a spelling mistake. Click the suggested correction. Click on a result. Go back. It's deleted the corrected link! The browser should track it but the page in between is deleted. Why does it delete it!? This has annoyed me for years! How can they not know of this obvious bug for decades?

@pixie

Didn't recall this one. I did read a bit converting endian. Makes me wonder why he didn't run the native code as big endian and avoid all that endianess?

@matthey

arm is not compatible with classic amiga like ppc
stop trolling start working on mui clone on aros

@Hypex

Quote:

I would ask why MUI wasn't simply ported to AROS, but then I am reminded that AROS is open source and MUI is still shareware, and not all 90's Amiga software were open sourced.

But you could have it closed source still, there's no issue regarding AROS license, in some ways it already happens, only on AROS 68k though and with a various degrees of success and some clashes with Zune.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Hypex

Quote:

Makes me wonder why he didn't run the native code as big endian and avoid all that endianess?

Indeed, that's how Emu68 runs. The emulator currently runs on Apple silicon, it might have to do with it, I don't know if Apple Silicon can run in big endian mode like on ARM

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@matthey

Quote:

Good code density is like having larger caches but with faster access times of smaller caches. Would you rather have faster and larger caches or smaller and slower caches? Do you realize that caches can be more than 75% of a modern high performance CPU by area/transistors?

I fail to see why that debate matters for the current situation. All it serves right now is yet another academic debate that leads to nothing with our current situation.
I get why the onboard cache is important and all, all I am saying is, that this debate is really of no use currently.

_________________

@thinkchip

I mean, PowerPC is dead since two decades, when Apple pulled the plug.
We Amigans sticked to it basically for lazyness, legal shenanigans and because back then AROS wasn't in a usable state for the average user who had to decide between Amiga OS4 and Morphos.
I have my SAM440ep and it's a little fun system to be honest, but even that is beyond any sane price I'd pay today.
I won't invest anymore in the dead end called PPC, I believe all the money that has been burned to bring PPC hardware would have been better spent in adopting a modern architecture with a future (although I'm all for free-personal-choices so everyone is entitled to do whatever he prefers with his own money).
When this small, silent, cute machine will die I'll consider my PPC experience closed forever and switch to whatever will be available and viable at that time or go back to emulation.

Note: I'm not interested in A600GS, I'd love to see AOS4 on ARM but that's not Amiga on ARM the way I intend it.

Last edited by Nibunnoichi on 20-Sep-2024 at 09:00 AM.

_________________
Proud Amigan since 1987
Owner of various Commodore and a SAM440ep\OS4.1FE
See them on http://retro.furinkan.org/

Quote:

ppcamiga1 arm is not compatible with classic amiga like ppc

Tell it to the A500 mini, Amiberry, PiStorm, A600GS etc. They obviously didn't get your memo!

_________________
Doing stupid things for fun...

PowerPC for the win! 68k the runner up. x86 is meant for Windows and GNU/Linux.

_________________

@vox

Quote:

On x1000 I wasn`t able to test PPC AROS.

I have. Rather indirectly. So many years ago I installed AROS hosted on A1 Linux. I then transferred that to my A1, likely on the same HDD, from my old Ubuntu 9 install IIRC. I configured it to boot with an X1000 kernel and it loaded up fine. I then found AROS and tested it again. Booted up fine in the hosted VM and I must have opened 8 windows of demos in AROS.

I was doubly impressed. First with my 32-bit Linux booting on a 64-bit kernel without crashing. And then AROS running fine as hosted again on totally different hardware. Likely it worked well because X1000 Linux is configured as a 64 bit kernel running with a 32 bit user space. I never quite got why it was configured that way for a full 64 bit kernel but it was. But, on my x64 laptop, trying to run 32 bit apps resulted in an error which made PPC Linux look good.

@cdimauro

Quote:

No, it was already well before it.

Well, my mastery of the English language is weak, but I would put emphasis on "at least" in my original post.

Quote:

You can use (Win)UAE for full compatibility, even with games.

It is obvious you never used NG Amiga hardware. I have both Pegasos 2 G4 and (now) powerful laptop for Amiga emulation (QEMU and WinUAE). The experience simply is not the same.

Quote:

All articles are in Italian

Italian spam on an EN Amiga forum?

@matthey

Quote:

RV64IMC code likely uses about 15% more instructions on average than AArch64 code. RV64IMC is actually better than most classic RISC ISAs at this metric but AArch64 is exceptional at this metric. RV64IMC code density is better than AArch64 and the RISC-V SiFive U74 core is a very good design for a small in-order low cost core as ~$50 SBCs demonstrate (U74 design eliminates most load-to-use stalls making it good for emulation too).

I wonder how PPC code compares to RISC-V? Would have to be better than against CISC. RISC against RISC should even up the odds. But also V is a RISC redesign so known flaws in PPC could be avoided. I also wonder how MIPS compares as well.

Quote:

PIV and CV64 are good boards. A 68060@50MHz and older accelerator board with poor memory performance could be the problem. Clocking up the 68060 and increasing the memory performance have synergies that provide a large boost to performance.

That's likely it. I do have a 68060@50MHz on a CyberStorm. Which was a standard clock rate at the time.

Quote:

The 68k Amiga received 3D hardware too. The texture memory buffering of 3D cards eased the graphics bus bottleneck. The following video shows GLQuake timedemo demo1 512x384x16 with 26.8 fps.

It did but a 3d card was even less rare than a 50Mhz 68060 card at a reachable price.

Quote:

I used 512x384x16 also which was a good compromise between performance and aesthetics. This is a few more fps than I was getting with my 68060@75MHz CSMK3 in an Amiga 3000 but it looks about the same (I had W3D optimizations which gave a couple of fps). This is about twice the performance of software only RTG rendering at the same clock speed. A 68060@50MHz with low performance memory may have had trouble getting out of single digit fps. It's too bad Motorola did not clock up the deep for the time 8-stage 68060 but the performance threatened the shallow pipeline PPC CPUs which they struggled to clock up.

That's quite impressive. Mine was at 320x240 in Doom. May not be VGA size but 512x384x16 is shifting more than double my Doom mode. With more complex Quake engine closer to Mac size screen. The 100Mhz clock would certainly help.

I would have tested Quake on my A1200/030@40 back in the day from the CU cover CD. It was interesting but on a slower CPU with only planar would have performed poorly. I only really played it once I had tried out the PPC port on my A1/XE. IIRC that also software rendered but an 800Mhz PPC was enough to cover that. Something my A1200 lacked at the time.

Quote:

Yes. The difference in cost is not so major despite the huge core size difference. for example, an original RPi SoC may have cost $1, a RPi 3 SoC maybe $2, a RPi 4 SoC maybe $5 and a RPi 5 SoC maybe $10 even though the transistors used appear to have increased exponentially. I don't know the actual cost or price of the RPi SoCs but the numbers give an idea of the correlations. ARM doesn't give transistor counts for most of their processors anymore. They used to be a marketing tool showing how small the cores were but the new AArch64 cores are neither small or particularly cheap anymore which is why the old Cortex-A53 continues to be popular despite lackluster performance in general and poor performance for retro emulation use on the Amiga due to the large 3 cycle load-to-use penalty.

I've not really tested it myself. Haven't done much with my RPi or tested AmiBerry or anything. In fact I could be considered a lazy hobbyist. 3d printers turn up, I have some ideas, but never bought one. Then drones become the rage. Friends all buy into it but I don't bother about the latest in 3d remote vehicles. Now everything is all about AI. Friends get right into it, I don't really bother about all the chat with this GPT thing, though I did wonder for a time how a partition format can speak.

So, when I bought an RPi, just a 3A+, I bought it with the sole intention of using it as a CPU card for a PiStorm. The A1200 Vampire did interest me but with the price against a PiStorrm, even though it needed an extra SBC and software setup by hand, the PiStorm sealed the deal! I'm always doing some DIY of various kinds. And as reported earlier I have found the performance quite capable. Since then a friend has offloaded his older 3D printer. To which I recently tried printing out some 3d brackets for my A1200ss rear. That filament would get expensive. I'm glad I didn't get into droning after 3d printing!

Quote:

The RPi 4 may offer the best value for retro emulation as the OoO removes most load-to-use penalties while the cost for additional cooling is minimal. The RPi 5 cooling and hi amp power cable may exceed the cost of the SoC which isn't so cheap anymore. The low cost solution with good performance for the low end is an in-order CPU without load-to-use stalls like was common for CISC core designs although the RISC-V SiFive U74 core uses a similar design. The RISC-V ISA is weaker than the AArch64 ISA and the 68k ISA while the latter has a significant performance advantage accessing memory. It's not like ARM cores have an area/transistor cost advantage anymore.

I've found the RPi4 is becoming most common. I'm happy with the price/performance of an RPi3 and also set up one for a friend. But most Amiga people like to have the best setup and the RPi4 delivers better performance ad expected. It also cost more for the SBC. If an RPi3 is an excellent Doom runner, the RPi4 must surely be a Quake killer!

Last edited by Hypex on 20-Sep-2024 at 05:18 PM.

@Yssing

Quote:

But RISC-V boards are available now, with much much better specs than any ppc amiga and at a fraction of the price.

@agami

Quote:

Which means if they could overcome the major hurdle of not having any funding, they could port it to anything and hypothetically call it "AmigaOS V".

Now there's an idea. Port AmigaOS to RISC-V And call it AmigaOS V. The marketing speaks for itself. Better then my aging PowerARM idea.