@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro as usually you start trolling instead of working di mauro you should hard work on mui clone on aros it is still not compatible with 30 years old amiga mui

I reveal you another secret: YOU are the only one here which put it as The goal to have.

I reveal you also another secret: AROS is open source, so anyone can get the source and contribute.

Now, I reveal you elementary logic: since YOU are the only one interested on the above, then YOU can pick AROS' sources and add what YOU like.

@Karlos

Quote:

Karlos wrote: @amigang I don't know what the issue is here. Almost every PPC AmigaOS application, tool, system component (library, driver, datatype, filesystem, etc) is written in C. You still have some potential structural dependence on 32-bit pointers and big endian data layouts but as it stands this could be ported to ARM pretty much as-is. It's still RISC, it's still Big Endian, it's still 32-bit. All the things that even the most lunatic PowerPC devotee insists are necessary. Then there's legacy 68K emulation. Well, we know how well ARM can manage that, so Petunia could be replaced with a new JIT. The only missing piece of the puzzle is legacy PPC binaries for the small number of applications that were written in the WarpOS/PowerUp era. How many of those do people actually depend on that don't have native replacements these days? The only other things it lacks are a sky high price tag, multi decade waiting lists for hardware and a ton of bugs that need working around when, or more usually if, the haedware appears.

In fact, it makes more sense to other way around: port the only PowerPC applications which are unique (e.g.: not available on 68k) to the Amiga 68k, and backport the relevant parts of OS4 or MorphOS to the same system, and leave everything else to the mature 68k emulation which is available everywhere.

It's obvious that the Amiga has much more software and support. And nowadays it can run super fast thanks to the JIT and hardware acceleration of the graphics, audio, disk, etc..

This is the "future" which makes more sense for the community.

@cdimauro

stop trolling start working
di mauro you should hard work on mui clone on aros
it is still not compatible with 30 years old amiga mui

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: It's not an easy task, as you can read from this article: On that note, your articles, they would once load up and ask about translation. For some reason they stopped last night. Cleared the cookies and it won't translate back! Google translate was useless. Translation was fine I'm sure but it kept sticking these pictures in my face about "Stop! Hotlniked". I tried DeepL, the site wasn't so obvious so installed the plugin, but it keeps sticking this symbol over things and blocking text. And then, on your site, it didn't even show up! If it only works with an account then I'm over it already.

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.
Quote:

Quote: However, the main problem for an OS should NOT be the endianess. To be more precise, if an OS relies on the endianess, then it's very badly written. Well, I'm going to bring up an example of that, for fun. So Windows, you've said before is a good design, and I know people that know people who've seen the source and have confirmed it's well written.

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.
Quote:

So my point was this. Windows depends on endianness! It depends on little endianness. Now it may be common endian these days so being popular won't hurt, making big endian look like the way of the dodo, but it does depend on it.

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

Just like a BMP or RIFF depends on it.

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.
Quote:

You would know about the ports of WindowsNT and articles by Raymond Chen. And now the ARM port.

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

Quote: OSes should be endianess agnostic! Well, Linux manages it, with a few specifics. Macros and other defines. But graphic drivers aren't!

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.

However, it's everything internal. And even when it's defined with the DDK, you should pay attention on how to write code which has to deal with the endianess of the system.

Anyway, it's still internal: nothing that should influence the OS "per sé" (by itself): applications don't need to handle the peripherals (and even when they need to do it, they have to follow the rules).
Quote:

Quote: P.S. All articles are in Italian, but you can easily translate them with DeepL (the most accurate) or Google Translate (if you like to keep the formatting). I'm cranky and impatient now. I tested them. They failed my easy test and I spent too much time now so I'm feeling old.

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

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro stop trolling start working di mauro you should hard work on mui clone on aros it is still not compatible with 30 years old amiga mui

PARROT MODE ON. Then:

I reveal you another secret: YOU are the only one here which put it as The goal to have.

I reveal you also another secret: AROS is open source, so anyone can get the source and contribute.

Now, I reveal you elementary logic: since YOU are the only one interested on the above, then YOU can pick AROS' sources and add what YOU like.

@amigakit

Quote:

amigakit wrote: @matthey Quote: With open source A600GS software, a cheaper and higher performance RPi 4 or RPi 5 could be used which may be good for the user but not for A600GS sales. Cheap ARM hardware lacks value for emulating 68k hardware but is available to everyone so it is down to the software to add value which is why it is protected by businesses trying to make a quick profit with minimal investment and risk. RGL does the same thing but they are more experienced at it and more of their value comes from licensed games. This is completely inaccurate. The value is in the original software development that we have completed and continue to implement. The A600GS makes use of SystemV46 which was written from the ground up over many years. AK-Dataypes and AmiBench with SystemV46 represent many thousands of development hours. All of this software is not open source. OctaMED 8, Personal Paint 7.4, Final Writer 7.1 represent many man hours of development time (none of which are open source). Our developers have written original components such as the Datatypes Library, Picture Datatype, AB-Dock, DOS commands. These all represent a substantial investment into Amiga development. The developers got paid for this work. Entities such as RGL invest next to nothing into our community developers.

Someone had to work on all the Amiga related stuff + system & frontend for the Mini consoles, and probably Amiga developers were involved. Paid developers, of course.

The difference with your A600GS is primarily on the ARM parts which were developed and the bundled software.

However, the Minis bundle software as well, which should be paid...

@Yssing

Quote:

Yssing wrote: @cdimauro Quote: ARM is better because it's focused on performance: something which RISC-V will never catch on, since it's "too RISCy". The only good thing about this architecture is that it's free from licenses. And that it has better code density in its 64 bit version, compared to ARM. I really doubt that, but who knows.

I know it because I've studied all such architectures, so I know their pros and cons.

As I've said, RISC-V is too "RISCy": it requires more instructions to do the same things which ARM64/AArch64 can do in one.

There's no way that a RISC-V can get better performance of an ARM chip, when all variables are the same (e.g.: the number of decoded & executed instructions per cycle, same amount of I&D catches, etc. etc.).
Quote:

RISC-V is cheap, farily highend boards are cheap.. way chaper than the cheapest amiga NG PPC solution. Not so sure, that what you need right now is lots and lots of speed, I do think that what we need is readily and cheap hardware. Just look at this board here: https://eu.mouser.com/ProductDetail/SiFive/HF105-001?qs=Imq1NPwxi75JBw6ulD0quQ%3D%3D

Yes, I know. But I was talking of something different: see above.

@amigakit

Quote:

A600GS is a ready made complete computer

Ah yes, not like it’s just an Orange Pi 3 zero that you have been SOFTMODDING before reselling it?

Been wanting to ask - now that you’re assembling and selling a product that has online capabilities and hence falls under the relevant classifications… what’s your stand on the PSTI act and similar? Maybe that’s why The THEA500 etc don’t have online capabilities, hm? Maybe they pay attention to regulations and have lawyers that suggest it isn’t worth the risk? Do YOU find it worth the risk?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@amigakit

Quote:

amigakit wrote: The A600GS could not rely on legally disputed projects such as OS3.2 for it's system software.

But Commodore's Amiga OS releases aren't touched but such disputes. In fact, the RGL's Minis are bundled with the Amiga OS 3.1.

So, you could have do the same.

However, AROS is a much better fit for what you want to achieve.
Quote:

RGL does not promote it as an Amiga, but do not object when others conflate or misrepesent it as an Amiga.

Actually, they do it:

https://retrogames.biz/products/thea500-mini/

A compact reimagining of the Amiga 500 home computer, featuring perfect emulation of not only the original A500 but also the Advanced Graphics Architecture (AGA) of the A1200.

They can use the Amiga word, because they have the license (like for the 3.1 software).

That's something which no one else can do, even using the 3.2 software.
Quote:

Lets be honest, this is a smash and grab for cash. Once RGL have extracted the money from our community it is onto the next retro "console" as they refer to the Amiga.

I agree, but they are selling... consoles, and those are not the only ones. They have no other scope than that.

@thinkchip

After a decade with x1000 (now sold) I have moved to AmiKit XE, G5 MorphOS and was a Vampire V4 user, so I feel ya.

However, I have tried AROS m68k and PPC on SAM460, as well as AEROS (Linux and AROS crossover) and while its legit clone and open source, I find OS 3.2, pimped OS 3.9 were more suitable and able out of box. Its very spartan in look and barebone in functions, even much can be added to m68k and x64 thanks to a lot of porters. Many OS4 fumctions and software can be mimiced or software exists for non commercial software, so I tended to prefer distros like ArosOne etc. since they do bundle it.

People naging AROS is not the future tend to forget it has been used in MorphOS and A600GS to complement missing functions, so on fast x86/x64 its fine. On pimped m68k like Vampire is much much slower then OS 3.2/OS 3.9. Usable but way slower. On SAM460 barely usable compared to OS4. On x1000 I wasn`t able to test PPC AROS.

_________________
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

@ppcamiga1

Yes I agree OS4 era has brought some elements of OS and software forward, but failed to make it viable desktop, as promised, thanks to Hyperion and AEON Libre Office 3 eternal port.

Its good for Linux, even SAM460 and more x1000/x5000.

It will be left to be, lingering in dying and niche hardware base, overpriced and what is left of OS4 community support.

@karlos

Agreed. Main value of OS4 and its software library is portablity.

Trend has started with more and more SW having m68k versions beside MOS and OS4 and OS 3.2 and beyond including backported OS4 parts as new m68k baseline.

Last edited by vox on 18-Sep-2024 at 08:30 AM.

_________________
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

@pixie

Quote:

How cool would it be if it also used Ambient, but Michal Schulz doesn't finish Zune.. .

That would be cool. So from what I read it's 89% there. 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.

@matthey

Quote:

Doom seems to cap around 35 fps which a 68060 Amiga can reach (even at 320x240x8 in the following video where original Doom was 320x200x8).

That's interesting. It must be a more modern setup than mine is. I never got past 22 FPS on RTG with with PicassoIV or CyberVision64. Native wasn't much slower.

Quote:

Quake is a better benchmark for CPU, GPU and memory performance. With old silicon and Amiga bottlenecks, the 68060 Amiga is much more impressive than the ARM emulation.

Quake is also higher demanding, at a time when software 3d was going to hardware 3d, so a strange port to the Amiga when most machines lacked RTG yet alone hardware 3d.

Quote:

The ARM hardware is cheap but poor performance. ARM OoO hardware like the RPi 4 and RPi 5 are much better for emulation but they are huge cores.

By comparison the Cortex-A57 is a huge core.

@Yssing

Quote:

I really doubt that, but who knows. RISC-V is cheap, farily highend boards are cheap.. way chaper than the cheapest amiga NG PPC solution.

What I wonder is how a RISC-V CPU and board was manufactured like that for that price and no one could do the same for PPC for decades. Especially after PPC was opened. Well that was about 5 years ago so perhaps too late and nobody cared by then. Even less now.

amigakit Quote:

Apart from the fact that the A600GS is a ready made complete computer with licenced software- not just a bare board that you are comparing to:

RPi cases are only about $5 USD while Amiga cases are several times this even though I suspect many use the "Amiga" trademark without a license. A 64GiB MicroSD Card is maybe $5-$10 USD. The A600GS offers plenty of memory and storage but is it necessary because of the inefficient emulation and 64-bit Linux tax?

device | CPU | device memory | Amiga memory | storage
A600GS Cortex-A53@1.5GHz 2GiB 512MiB 64GiB
A600GS+ Cortex-A53@1.5GHz 4GiB 1GiB 128GiB

Real 68k Amiga hardware required a fraction of these cost increasing specs. The hardware doesn't blow away a 68060@100MHz or AC68080@100MHz in CPU performance either. The value is not in the hardware but the software and convenience of a pre-configured system which is also software.

amigakit Quote:

You may have missed that we are progressively converting functions to run natively in ARM code bypassing the 68K bottleneck. This is initially available in our ARM Graphics Library but will be expanded to other system libraries. AmiBench performance will steadily improve. Any 68K developer can take advantage of this for their own applications or games.

There is no 68k bottleneck! There is only an emulation bottleneck! You chose to use the in-order Cortex-A53 CPU which requires good instruction scheduling to get anywhere near the maximum performance and this does not happen with simple emulation conversion of 68k to AArch64 code. How many times do I have to explain this? Do you not have any tech people available or are you using the same ones from A-Eon that recommended the A1222 CPU?

amigakit Quote:

"Inactive" maybe putting it generously. The developers have long left the Amiga and will not be back. RGL does not promote it as an Amiga, but do not object when others conflate or misrepesent it as an Amiga. Lets be honest, this is a smash and grab for cash. Once RGL have extracted the money from our community it is onto the next retro "console" as they refer to the Amiga.

Smash and grab is unfair as it implies doing harm with the smash. One and done would be closer but RGL is bringing out successor products and providing support. They are licensing Amiga products with money going to professional developers and the Amiga IP owner Amiga Corporation. While they may seem inactive in the Amiga market at the moment, I believe RGL products are more likely to cause a major change in this situation than the A600GS. You have a financial interest in most of the A600GS software so you are mostly investing in your own development. I already asked for a financial disclosure. You do own A-Eon stock don't you?

@matthey

Quote:

There is no 68k bottleneck! There is only an emulation bottleneck!

If only there was a way to use an emu68esque type of emulation. Bloodline had a baremetal emulator

https://youtu.be/ECL4RqmYBwk

https://github.com/h5n1xp/Omega

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

@Hypex

Yes it is a really good question. Might be because the bet is on something else, honestly I do not know.
But RISC-V boards are available now, with much much better specs than any ppc amiga and at a fraction of the price.

_________________

Lou Quote:

It's almost 2025 and someone just realized PowerPC has been dead for at least a decade? Next someone will realize that the A in A600GS stands for the cpu-war winner: ARM! ...something I've been asking for since maybe 8 years ago... Who would have thunk it?

ARM only won the embedded market war.

market | dominant architecture
embedded ARM
desktop/laptop x86-64
server x86-64

ARM did not win the embedded war with their original ISA or the one they are using currently. They won it with the Thumb/Thumb-2 ISAs which are some of the best code density ISAs and is no surprise for embedded use where it is very important. The Thumb ISA was created after the Hitachi SuperH ISA was licensed by ARM. Hitachi was a 2nd source CPU producer for the Motorola 68000. SuperH has several similarities to the 68000 including assembly language, addressing modes, microcode (unusual for RISC at that time) and good code density (also unusual for RISC at that time). The leading embedded 32-bit architectures were 68k, SuperH, Thumb-2 and now likely AArch64. ARM performed a switch from Thumb-2 to AArch64 by selling the 64-bit upgrade and improved performance but cores are larger, code density is not nearly at the level of Thumb-2 and 64-bit OSs use roughly 30% more memory. There just isn't much competition left for ARM in the embedded market to challenge them. AArch64 is doing better than PPC/Power ever did in the desktop and server markets but there have been far more failed attempts in these markets than successful ones. The gaming desktop market is absolutely dominated by x86-64 Windows largely due to a standard system and huge 3D game library. Even with the performance upgrade from Thumb, AArch64 is not blowing away x86-64 in performance or efficiency metrics. The demise of x86-64 is greatly exaggerated. There is too much compatibility improving bloat and baggage to scale down to the embedded market but compatibility is a proven winner in the desktop market.

Yssing Quote:

I really doubt that, but who knows.

cdimauro Quote:

I know it because I've studied all such architectures, so I know their pros and cons. As I've said, RISC-V is too "RISCy": it requires more instructions to do the same things which ARM64/AArch64 can do in one. There's no way that a RISC-V can get better performance of an ARM chip, when all variables are the same (e.g.: the number of decoded & executed instructions per cycle, same amount of I&D catches, etc. etc.).

I agree with cdimauro. RISC-V loses performance due to being too simple like classic RISC. This increases the number of instructions to execute which means the CPU clock rate must increase to keep up with the competition with everything else being similar. Wider issue to compensate is very expensive and the competition can do the same while retaining the advantage. 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). RISC-V has possibilities for low cost low power hardware but the ISA gives a performance handicap which may become a problem when trying to scale it up. There are already RISC-V CISC like extensions to address the performance deficit much of which is due to the few addressing modes where AArch64 is more CISC like. Adding extensions like this for performance after the ISA is created is less than optimum and turns into a non-standard mess with less optimal compiler support.

Hypex Quote:

That's interesting. It must be a more modern setup than mine is. I never got past 22 FPS on RTG with PicassoIV or CyberVision64. Native wasn't much slower.

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.

Hypex Quote:

Quake is also higher demanding, at a time when software 3d was going to hardware 3d, so a strange port to the Amiga when most machines lacked RTG yet alone hardware 3d.

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.

GLQuake/Blitzquake, 68060@100Mhz, Voodoo3 512x384x16bit Demo1 (1200,Warp3D)
https://www.youtube.com/watch?v=ncJqnxx98Zw

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.

Hypex Quote:

By comparison the Cortex-A57 is a huge core.

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.

core | transistors
68060 2,500,000
ARM11 9,000,000 (original RPi and RPi Zero)
Cortex-A53 15,000,000 (RPi 3)
Cortex-A57 90,000,000 (predecessor OoO core to the RPi 4 Cortex-A72)

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.

Last edited by matthey on 18-Sep-2024 at 10:21 PM.

@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.

_________________
All the way, with 68k

@matthey

There is a lot of good information in your post.
In reality PPC/RISC-V/Arm/X86-64 does not matter at all, since we are currently stuck with aging and expensive PPC hardware.
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.

_________________