@BigD

Quote:

Do we even need OS4.x?

I don't think YOU need OS4!

Quote:

I can't remember if I've ever even used it?

That explains all the solid points in your arguments.

Quote:

OS3.2/3.9 surely was the pinnacle?

Sure, if you like to move icons around on Workbench all day.

Well, in my experience, the state of affairs is such that OS3.9 still has more to offer over 3.2. Maths don't lie. 3.9>3.2=true. UnArc. Genesis. Dock? Like 3.2 it still lacks good RTG support. Not even close to matching Windows 95 plug and play monitor in the latest 3.2. And now days, OS3.9 looks old. But only because OS4 looks better, has UnArc, the dock and a lot easier RTG setup. I do prefer OS3.9 on a real Amiga, as it's just not the same in UAE, even though it's better than flicking between video and HDMI.

@pixie

Quote:

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.

I didn't think of that. Just because the OS is open source doesn't mean the software always needs to be. I do have paid software software I run in Linux simply because there is a Linux build. But, MUI should compatible with AROS 68K. AROS non-68K or x86/64 is where it is needed. So no AROS port? Endian issues?

Quote:

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

Ah okay. After reading the info I got the impression it was made for an RPi. In that case endian macros are his friend if they translate to proper reverse load codes and the code to set endian should help.

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

Yssing Quote:

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.

I believe the reason why PPC failed and the viability of potential successor architectures requires examining advantages/disadvantages and performance metrics, one of the most important being code density. It was you who mentioned RISC-V as a potential alternative to ARM or x86-64. Code density is one of the few performance metrics where RV64IMC outperforms AArch64 and PPC. PPC was higher performance and less RISCy than most of the classic RISC architectures. It held onto an embedded niche in communications and automotive for years because it was higher performance than pre-AArch64 ARM could reach. PPC disappeared very quickly when AArch64 came out because AArch64 is similar but less RISCy (more CISC like) and improved in almost every way, including code density by maybe 15% to 20% (compared to PPC32 while PPC64 may have more of a difference). Code density is likely the largest and most important performance metric improvement of AArch64 over PPC. PPC had better code density than most early PPC architectures like Alpha, PA-RISC, MIPS, SPARC and ARM but not by much and the way it was encoded made it challenging to add a compressed encoding. The importance of code density was vastly underestimated by architects/developers as can be seen by the worst code density RISC architectures dying first and the less RISCy load/store architectures today being much more competitive in code density. RISCy architectures have to compete in the embedded market on the low end where code density is practically a necessity and high performance more desktop like CPU caches can be more than 75% of the area/transistors as I previously mentioned. The leading surviving RISCy architectures are AArch64. RISC-V and Thumb-2 which all have much improved code density compared to the more classic RISC like architectures. AArch64 replaces PPC, RISC-V replaces MIPS/SPARC, Thumb-2 replaces original ARM and SuperH. All of these RISC ISA replacements were code density upgrades.

There certainly are other factors than performance metrics. AArch64 is an improvement in ISA standardization with a large standard integer ISA, standard FPU and standard SIMD unit which improves performance and makes compiler support easier but the down side is the ISA is fat with thousands of instructions requiring larger and more expensive cores, a problem even the moderately standardized PPC (CPU+FPU but some support optional) had trying to scale down as exhibited by the A1222 bastardized CPU and some other embedded changes. Earlier ARM architectures were less standardized using optional ISA extensions a la carte. RISC-V is the least standardized and most customizable not only having a crazy amount of extensions but even leaving a sizeable amount of encoding space available for custom instructions potentially to accelerate even dedicated and unusual workloads. All the customization is cool in a way but not for compiler developers. It likely contributes significantly to the lack of maturity of RISC-V as mentioned in the article I posted earlier. The video has more info than the article which I have linked below at the place where RISC-V is talked about.

He started a computing REVOLUTION - then the shortage hit
https://youtu.be/-_aL9V0JsQQ?t=1115

It is mentioned that, "since RISC-V designed the chips (RP2040) themselves, could they someday move to RISC-V and save on ARM licensing fees?". Eben Upton (the CEO of RPi who started the computing revolution) was asked about RISC-V. There isn't much incentive for RPi to move to a less mature RISC-V as ARM is easy and what they want being a spiritual successor of Acorn/Archimedes which used ARM (watch the whole video for Eben's Acorn history). The minority stake of ARM in the RPi may make RISC-V less likely although dedicated deeply embedded RISC-V cores could appear in RPi hardware. Most of the RPi ARM cores support even the original ARM32 architecture so Acorn Archimedes RISC OS code can execute natively (minus any patching necessary for the 26-bit addressing hardware design mistake unlike 32-bit clean 68k hardware). The 68k Amiga legacy is different though. Jay Miner's choice of the 68000 and Amiga chipset design were huge mistakes that never should have happened. PC hardware should have been used instead which has been corrected with the NG Amiga hardware. The AmigaOS was a big mistake too as none of the NG AmigaOSs are competitive. Emulation is just an Amiga mistake decelerator. It's time to erase all the Amiga mistakes completely. Can we get some woke revisionism of the Amiga history to make it disappear completely or are Trevor and Ben doing a good enough job already?

Last edited by matthey on 20-Sep-2024 at 06:59 PM.
Last edited by matthey on 20-Sep-2024 at 06:54 PM.

@Yssing

Quote:

Yssing wrote: @WolfToTheMoon Yes it does look bleak. I do think that the real killer was all those legal battles.

The legal battles are recent, whereas PowerPCs are dead from much longer, and OS4... you know its status.

@kolla

Quote:

kolla wrote: @agami Quote: agami wrote: @WolfToTheMoon 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.

No, they can only develop OS4 and not 3.x or other software.

You've to take a look at the announcement which Hyperion did on 2009, just after the settle agreement, on its site.

After the start of the legal battle they have removed it, so it's not available anymore. Guess why...

However, a dump of it was reported by Cloanto in its documentation for the legal battle.

@Hypex

Quote:

Hypex wrote: @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.

Sorry, I don't know how to help you, because it doesn't happen to me, and plenty of people are reading my articles.
Quote:

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.

You don't need to register to DeepL: it works even without it. However, you can translate more words (up to 5000 characters) if you register.

That's the relevant difference.
Quote:

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.

You're good for doing QA then.
Quote:

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?

The two things aren't related each other.
Quote:

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.

That's just a different user experience. There are plenty of hidden/unknown variables that can justify those differences.

In fact, I've a completely different experience (always was good with Windows, and had problems with Linux).
Quote:

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.

These days, yes. But Windows wasn't born now.
Quote:

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.

It worked with big endian systems as well.
Quote:

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.

I don't see the problem here: there are some differences from the Windows for our PCs, but the core is more or less the same, as well as plenty of system and user libraries.

As I've said, NT was ported to very different architectures and with different endians. It has no problem with that, because it had a good design.
Quote:

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.

The relationship is about the endianess, but the scope is completely different.
Quote:

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.

Right, but this is all about serialization for persistent data structures.
Quote:

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

There are several things which aren't correct.

1) as I've said before, there's difference between considering the endianess at the OS level (data structures, APIs) and for the data persistency. Colours formats used by graphic cards are part of the data persistency, because you need to define a format for storing the ARGB values (which includes the 16-bit Hicolor formats); a graphic cards can support all formats and combinations, but that's up to the vendor.

2) even at the application level, the problems with browsers and the web, for example, are not related to the endianess and it should never be. You can talk about the JIT engines which are designed for little-endian systems, and that's ok (their choice), but the web and its standards, by themselves, are not bounded to little endian.

3) strings aren't better with big endian because you can "naturally" and efficiently search for some IDs: this (equality, inequality) can be done exactly in the same way with little endian systems. The real advantage of big endian systems is when you need ordered comparisons (less than, greater than, ...).

4) the data stream example is not clear and it's not possible to understand what's the exact scenario, to evaluate if its correct or not. Since I never had problems with streaming of bits, whatever is the endianess, I think that it's another incorrect example.

5) now here's the most important point. The article is confusing how a system with a certain endianess works, with how the data are visualized for human beings. Those are completely different things! In fact, little-endian systems aren't forced to represent the bits sequences starting from bit 0/LSB to the MSB, so from left to right: this choice is entirely up to the developer! I, for example, represent the data from the MSB (left side) down to the LSB (right side) even for data in little-endian format.

6) endianess is about byte ordering, and also bit ordering. A system can have different choices for both. It's not granted that a big endian system is for both bytes and bits, just to be clear. Having a big-endian bit ordering means that the first bit should be the MSB. However, first = bit number 0, which is not the MSB on the big endian systems which I know (which use a bastard endianess: big for bytes and little for bits). Little-endian system are usually coherent: they are little-endian for both bytes and bits; I personally don't know about little-endian systems which have big-endian bit ordering.

That should be more or less everything, but probably I forgot something (I recall some jokes against the little endian system, but I'm not able to find it now).
Quote:

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

Again, this is the about the persistency of data. The registry is saved on the disk, and has its format. However Windows gives you the possibility to define the endianess for storing some specific data.
Quote:

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

That's part of the C++ standard: it has nothing to do with Windows.
Quote:

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?

Google is very well known of unfinished products.

@pavlor

Quote:

pavlor wrote: @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.

And I've clarified how it was in reality.
Quote:

Quote: You can use (Win)UAE for full compatibility, even with games. It is obvious you never used NG Amiga hardware.

Correct.
Quote:

I have both Pegasos 2 G4 and (now) powerful laptop for Amiga emulation (QEMU and WinUAE). The experience simply is not the same.

I've no problem with that, but my sentence wasn't related to this: it was saying something different.
Quote:

Quote: All articles are in Italian Italian spam on an EN Amiga forum?

In the last years I provide translated versions of my articles (next coming soon), but the old ones are still in Italian, sorry.

@ppcamiga1

Quote:

arm is not compatible with classic amiga like ppc

I actually do agree with you.
The only genuine ISA for OS4 is PPC.
OS4 should never switch to a different ISA.

@cdimauro

Quote:

And I've clarified how it was in reality.

Well, glad I live in another reality.

Quote:

I've no problem with that, but my sentence wasn't related to this: it was saying something different.

When you at least try NG hardware (eg. PowerMac with MorphOS), you may learn the difference between a real hardware and emulation. I'm sure it would expand your understanding of a significant part of the remaining Amiga community.

Quote:

In the last years I provide translated versions of my articles (next coming soon), but the old ones are still in Italian, sorry.

No need to sorry at all, I aplaud anyone doing some work for Amiga (even in your... way). I only find amusing your urge to heavily promote your Italian articles right here.

@V8

Quote:

OS4 should never switch to a different ISA.

I would really like to see you writting this post... and laughting on your chair.

@V8

Quote:

V8 wrote: @ppcamiga1 Quote: arm is not compatible with classic amiga like ppc I actually do agree with you. The only genuine ISA for OS4 is PPC. OS4 should never switch to a different ISA.

Evil...


@pavlor

Quote:

pavlor wrote: @cdimauro Quote: And I've clarified how it was in reality. Well, glad I live in another reality.

It's the same, but you were stuck a bit more ahead of the dead (in every sense) line.
Quote:

Quote: I've no problem with that, but my sentence wasn't related to this: it was saying something different. When you at least try NG hardware (eg. PowerMac with MorphOS), you may learn the difference between a real hardware and emulation. I'm sure it would expand your understanding of a significant part of the remaining Amiga community.

Again, that's a completely different thing, and I've nothing to say about that.

Here's your previous sentence:

For most Amiga users, compatibility certainly an important feature (if not most important). We could use other OSs with some skin otherwise (remember Commodore OS Vision?).

and here my answer:

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

The focus is compatibility. With what? To me it's obvious: Amiga (68k, of course) applications.

That's exactly the reason why OS4 is strictly bounded to a 32-bit big-endian architecture. Same for MorphOS, despite the claims to go to x86 (which never materialized).

It that wasn't important, then the OS could have been ported to any other architecture.

Now, being clarified the context, my answer was "just" giving the simplest and most effective solution to the compatibility problem.

I hope that now everything is... settled.
Quote:

Quote: [quote]In the last years I provide translated versions of my articles (next coming soon), but the old ones are still in Italian, sorry. No need to sorry at all, I aplaud anyone doing some work for Amiga (even in your... way). I only find amusing your urge to heavily promote your Italian articles right here.

I need no promotion: those are very old articles, and my site has no advertise, so I don't get a single penny out of any view.

I only write for pure passion, and nothing else.

The reason why I've linked my articles is simply because they perfectly match to the precise parts.

@V

There must be a dose of sarcasm here :)

My grunch is not being ppc that much, but not utilizing hardware fully. Until math done strong single cpu board like g4 and 2gb and radeon 9200 was enough. Multicore, more modern boards with no proper OS support lead only to expenses and frustrations.

In such terms e.g if OS4 and MOS were optimized and fully using e.g. power9 boards, that would be acceptable.

@on skinned OS as alt

CommodoreUSA Vision linux distro is not only c64/os3 skinned linux, its skinned mint with little effort and no royalties

It seems leo survived and is trying to sell stocks of c64 barebone cases and overpriced pcs as well as presenting is as it is their own OS now 2.0

Its a bit sad retro feeling mania has its customers
See
https://www.commodoreos.net/CommodoreOS.aspx

https://linuxlap.com/distro/commodore-os-vision-2-0-a-retro-journey-into-the-future-2024/

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

@cdimauro

Quote:

No, they can only develop OS4 and not 3.x or other software.

Well, since Ben managed to screw up his 2009 deal by releasing “OS3 stuff� claiming that _any_ OS developed by Hyperion by definition is “OS4�, to which the other parties of the agreement did not agree, the 2009 agreement is under dispute and it’s up in the air whether Hyperion can even develop OS4 anymore. By releasing OS3 updates, Ben has stirred the pot and risk losing everything. Great decision!

Last edited by kolla on 21-Sep-2024 at 12:52 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@vox

Its possible the community has underestimate problem with L1 cache synchronization, in SMP operation, with prebuilt code, can have problems if not updated, handle cache synchronization. I’m afraid that a lot of code will need to be rebuilt, and that 680x0 support might need to drop. To move Forword with SMP.

Any public data, without a locking mechanism, will likely have a L1 cache coherency problem.

Considering AmigaOS share library model, and its public structures, there are a lot of cans of worms waiting to be opened.

Last edited by NutsAboutAmiga on 21-Sep-2024 at 12:35 PM.
Last edited by NutsAboutAmiga on 21-Sep-2024 at 12:32 PM.
Last edited by NutsAboutAmiga on 21-Sep-2024 at 12:29 PM.

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

@NutsAboutAmiga

Well, MacOS transitions usually handled by sandboxing compatibility box (running Classic mode on PPC, PPC software on Intel MacOS X, and now ok easier just CPU JIT emu on Intel to AMD).
I believe its solution to such Amiga problems.

Classic software should be one structure (and even CPU) emulated box that eats away quite resources when run, but leaving OS free to develop without old restrictions.

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

@vox

not possible on Amiga because Amiga Inc
has not rights to important parts of software like mui and reaction.
so it has to be as it was mixed 68k and ppc code.

and thats why trolls like szulc, szonwejs, v8, mathay, cesare di mario, karlos, hammer etc
should hard work on aros on mui instead of trolling

@ppcamiga1

MUI has (c) by its author, but is also I believe open sourced as MUI4?
ReAction has been developed further within OS 3.2 and OS 4 (and thus new version freed)

OS 3.1 as basic baseline for sandboxing and emulation can be licensed by Cloanto?
At least OS 3.2 can be licensed from Hyperion

Zune and AROS Kickstart need aditional compatibility fixes.
AROS Kickstart itself was power2people bounty and first free Amiga like Kickstart file.

@Hypex

You are bigger x1000 guru then I was :D Bravo, you have made it!
I have just tried SAM460 compiled AROS and it did not work out of box.

I am glad new x1000 owner of my sold computer is indeed a developer. Gives hope more OS4
apps will use Altivec and be PA Semi optimised, and further OS4 sw working on x1000.

Last edited by vox on 21-Sep-2024 at 05:39 PM.
Last edited by vox on 21-Sep-2024 at 05:39 PM.
Last edited by vox on 21-Sep-2024 at 05:37 PM.

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

Hypex Quote:

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.

The PPC architecture has more performance potential than the RISC-V architecture. RISC-V is the evolution of MIPS/SPARC "classic RISC" with some improvements like code compression extension for better code density from inception, elimination of common RISC branch delay slot bad design decision, combined test/compare and branch instructions, etc. There were mistakes made though including lack of standardization with too many extensions resulting in challenging compiler support (AArch64 is the opposite with too much standard increasing core sizes), simple/weak instructions and addressing modes (PPC is stronger and AArch64 owns RISC-V in this category), false assumption that instruction fusion/folding could close the performance gap, poor big endian support (existing big endian code is common in some markets), too much encoding space reserved for future extensions and custom use reducing code density, etc. RISC-V is a better "classic RISC" improvement for the embedded market than desktop market.

Hypex Quote:

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!

The most "common" RPi depends on the market of which about half is embedded. The target is probably something like the following.

model | ARM CPU | market
RPi ARM1176JZF-S (embedded)
RPi 2 Cortex-A7 (antiquated by RPi 3)
RPi 3 Cortex-A53 (embedded)
RPi 4 Cortex-A72 (mixed)
RPi 5 Coretex-A76 (non-embedded)
RPi Zero ARM1176JZF-S (embedded)
RPi Zero W ARM1176JZF-S (non-embedded)
RPi Zero 2 W Cortex-A53 (mixed)
RPi Pico Cortex-M0+ (embedded)
RPi Pico 2 Cortex-M33 (embedded)
RPi 400 (non-embedded)

The ARM1176JZF-S CPU core design is an in-order scalar design with limited parallelism. This is a low power core with Thumb-2 ISA allowing a small footprint.

The Cortex-A7 is a 32-bit in-order superscalar CPU core design which was replaced by the 64-bit in-order superscalar Cortex-A53. The Cortex-A7 only has a single cycle load-to-use penalty compared to the Cortex-A53 3 cycle load-to-use penalty but the Cortex-A53 has much improved superscalar multi-issue capabilities and larger caches. The Cortex-A7 low load-to-use penalty and much smaller core size could have been a better choice for the RPi embedded low power core instead of older ARM1176JZF-S and for 68k emulation but ARM has strongly pushed their newer 64-bit cores and there is more similarity between the Cortex-A7 and Cortex-A53. This would also be the category where the in-order superscalar 68060 would be with larger caches and other upgrades but I believe performance is possible approaching the RPi 4 Cortex-A72 with the benefit of zero cycle load-to-use stalls, better code density (fewer cache misses) and perfect for 68k code performance.

The Cortex-A72 is an older ARM superscalar OoO core while the Cortex-A76 is a 3 generation newer successor that can't replace it due to more power and heat, even with a move from a 28nm to 16nm chip fab process. A huge active transistor increase is likely the reason for the power and heat increase of both of these cores but OoO does wonders for the load-to-use penalties.

The Cortex-M0+ and Cortex-M33 are extreme low power in-order shallow pipeline CPU core designs for the RP2040 and new RP2350 custom designed ASIC SoCs.

https://en.wikipedia.org/wiki/RP2040
https://en.wikipedia.org/wiki/RP2350

The performance and memory is approximately doubled while two RISC-V open hardware Hazard3 cores are included for roughly the same price.

https://github.com/Wren6991/Hazard3

The Cortex-M33 cores are higher performance than the RISC-V Hazard3 cores but not by too much. It's a good marketing tactic to sell SoCs to RISC-V fans and developers. I couldn't find any info on the transistor count but it had to have at least doubled due to the SRAM increase but more likely multiplied by considerably more showing how cheap transistors are with economies of scale. One of the cool options is 2MiB stacked NOR (non-volatile and executable) flash memory on top of the chip to save space which is only a $0.20 USD increase. It is possible to add up to 32MiB of external flash/PSRAM memory as well so 68k Amiga emulation would be a lot easier using this still ~$1 USD SoC chip (some ARMv8-M support but only Thumb/Thumb-2 and no AArch64).

https://developer.arm.com/Processors/Cortex-M33

The basic non-stacked NOR chip has only been available since August and it already has almost as many customers lined up as A-Eon does for PPC AmigaNOne hardware.

https://en.wikipedia.org/wiki/RP2350#Overview Quote:

At announcement time, seventeen other manufacturers had products expected to be available within a month.

I wish the 68k Amiga was as cool as RPi and AmigaNOne hardware but that failure Jay Miner made too many mistakes and the 68k, Amiga chipset and AmigaOS are trash. Trevor, Ben and ppcamiga1 are heroes for showing us PPC is the way forward.

NutsAboutAmiga Quote:

Its possible the community has underestimate problem with L1 cache synchronization, in SMP operation, with prebuilt code, can have problems if not updated, handle cache synchronization. I’m afraid that a lot of code will need to be rebuilt, and that 680x0 support might need to drop. To move Forword with SMP. Any public data, without a locking mechanism, will likely have a L1 cache coherency problem. Considering AmigaOS share library model, and its public structures, there are a lot of cans of worms waiting to be opened.

The 68k cache coherency failures are stopping SMP just like the 68k bottlenecks are killing the Amiga performance. I would have thought the 68k would have made SMP easier due to stronger memory ordering and the problem has nothing to do with cache coherency.

M68060 User’s Manual Quote:

The MC68060 integer unit generates access requests to the instruction and data memory units to support integer and floating-point operations. Both the ea fetch and write-back stages of the integer unit pipeline perform accesses to the data memory unit. All read and write accesses are performed in strict program order. Compared with the MC68040, the MC68060 is always “serialized’. This feature makes it possible for automatic bus synchronization without requiring NOPs between instructions to guarantee serialization of reads and writes to I/O devices.

The 68060 performs all memory load and store accesses in strict program order without any fences or other synchronization mechanisms but PPC showed the way to better performance by rearranging loads and stores. The 8-stage 68060 couldn't clock high enough to compete with the shallow pipeline PPC CPUs and their new found memory access load/store rearranging techniques. The x86-64 architecture with a more 68k like strong memory ordering TSO doesn't have the performance of PPC and AROS x86-64 SMP is impossible. PPC is vastly superior compared to any architecture on the planet and even God himself uses PPC in heaven because of its perfection.

Last edited by matthey on 21-Sep-2024 at 08:36 PM.

@ppcamiga1

you are the biggest troll of all for sure

again what are your contributions?

and why do you always talk about MUI? Nobody is interested in it. It is used just for some old applications. More interesting would be a port of a amiga desktop like scalos and adapted themes so linux apps look and behave like amiga apps. I do not care about mui at all.

But there I have to wait for deadwood