@OneTimer1

Quote:

OneTimer1 wrote: @Hammer Quote: Hammer wrote: The 5121e did not (does not) support cache-coherency, making the 5121e impractical for a consumer device that required the use of multiple applications simultaneously. Back in those days, the 5121e seemed to be a perfect MCU for an RasPi like device, just like an Efika on speed but Freescale failed with the PPC, has since been bought by NXP and only supports ARM today.

PowerPC e300 core is okay for its small size, but the trainwreck is with the platform and made the situation worse with integrated SoC's design issues.

PowerPC e6500 with 4 cores would cost me $583.63 AUD retail without sales tax. https://www.digikey.com.au/en/products/detail/nxp-usa-inc./T2080NSN8TTB/7648239
It's useless without a cost-competitive motherboard platform.

PowerPC e6500 wasn't built with low-cost small boards like Raspberry Pi 5.

The current-gen X86-64 CPU's 583.63 AUD price range is https://au.pcpartpicker.com/products/cpu/#sort=price&X=49582,522117&F=96,99,98,101,102

For general desktop use cases, PowerPC/POWER CPUs have platform weaknesses.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

cdimauro Quote:

That's really too much. You've to find a rich benefactor (former Amiga/Atari happy user) to sustain this project.

Amiga Corporation was funded with $7 million USD by a few individual investors circa 1982. A 2012 Kickstarter raised $8.5 million USD for the microconsole Ouya and Ouya Inc. received at least $15 million USD in investments including from NVIDIA and Alibaba. Adjust these investments for inflation to put modern investments in perspective. I'll skip the pic of Dr. Evil asking for one million dollars in ransom. How much money do you think has been spent on THEA500 Mini, A600GS and PPC AmigaOS 4 hardware and development for hardware that is noncompetitive outside of the Amiga retro market?

cdimauro Quote:

That's a no-go, you know: Gunnar is the sole one which decides on that project.

Jens and Thomas let Gunnar play. He is doing most of the work and there is no serious interest to professionally develop the 68k Amiga from Amiga related businesses so why not? Jens and Thomas are more professional and reasonable than Gunnar. Jens developed the N68050 CPU core and Thomas SAGA for the Natami project so they have a say and may make other choices if there was a serious project. The Natami project should have been adopted by Amiga related businesses and PPC AmigaNOne terminated back when it was active. The Natami project was generating huge interest with no advertising while PPC AmigaNOne interest was anemic and already on the decline. THEA500 Mini has verified the huge retro 68k Amiga market but all we get is noncompetitive hardware while PPC AmigaNOne hardware production drops into the hundreds of units.

cdimauro Quote:

To me SMP and 64-bit aren't the major problems with the AmigaOS: it's everything else (which I've reported on my last article). We know that it's very lightweight, super-responsive, and consumes less resources (but pay attention: that's because the graphic/audio assets of the time were also very limited and uses much less space compared to nowadays. And we didn't have very complicated but user-friendly software using technologies like HTML/CSS/JS), but let's say that you put in on a Set-Top-Box (so, competing with Android TV, Fire TV, WebOS, HarmonyOS, etc.): do you think that it works out well on this market? I don't, and for the reason that I've explained: it crashes with a breath. And you cannot sell this stuff to the general customers. You can't even sell it to other customers on different markets for exactly the same reasons. Is there any market where do you think that it can be used? I mean: large enough (in the millions ballpark) to justify an investment.

The AmigaOS was reliable enough to be used for the Video Toaster, kiosks and at least one medical device. These were often embedded devices sold with non-Amiga branding. The AmigaOS was successfully used for the desktop and consoles. There was no MMU, no zero page protection and no code protection for the majority of Amiga hardware. This could improve along with other hardware changes that improve Amiga compatibility. Certainly desktop expectations are higher today and I would not suggest advertising AmigaOS hardware for desktop use anymore than RPi hardware is advertised for the desktop but the reality is that some users will use it for this purpose and it should be adequate for this use. For retro computing/gaming, hobbyist and embedded use, full memory protection is unnecessary. While the use of a MMU for embedded systems is on the rise, many embedded systems still do not use a MMU. The RP2040 SoC Cortex-M0+ cores only have a limited MPU as there is no option for a MMU for any Cortes-M cores. A Cortex-A core is required for a MMU while Thumb2 has disappearing from new Cortex-A cores leaving a big gap between small 32 bit Thumb Cortex-M cores and large AArch64 Cortex-A cores.

cdimauro Quote:

That's like cheating: you're not fixing the problem but just moving it a little bit ahead the problem. First of all, it's not that efficient (see below). Second, and most important, this works as long as you can have a single SoC with everything inside. It doesn't work if you have multiple chips, because synchronizing them will become a nightmare to implement.

Getting SMP working with existing 68k Amiga software compatibility would be amazing. Despite criticism of disabling multitasking and interrupts, the unusual at the time preemptive multitasking gives a chance to make it possible. I don't see a problem with hardware help as long as it is simple and optional. Multi-CPU SMP is dead on everything remotely affordable. HSA makes a similar assumption that the whole system is integrated on the same SoC and provides benefits from this. Weak memory models, like PPC uses, were designed for multi-CPU SMP where a stronger memory model is easier to use and may allow better compatibility with minimal performance loss for single chip multi-core SMP.

cdimauro Quote:

While blocking all other cores to run the critical section on just one isn't even a much higher cost?

My point was that supporting SMP has a cost however it is implemented. Weak memory models require adding expensive sync/fence type of instructions, semaphores/mutexes add overhead and there can be competition overhead for resources. Flushing/syncing all other used cores for a Forbid() is more expensive when shared memory structures are not being accessed by other cores but this likely means they are accessing private memory which doesn't need to be flushed. That is why I have suggested a way to execute private memory without flushing and during the Forbid() to reduce overhead. Legacy code would not be able to take full advantage as memory would default to shared for compatibility but performance could be improved by simply changing memory allocation flags.

cdimauro Quote:

Well, they are all on the same position: too limited. Removing the backward compatibile is a need, nowadays. The legacy can run on a sanbox. Otherwise there cannot be any possibility for the future.

I'm not opposed to a NG AmigaOS that breaks backward compatibility but I don't think it will sell nearly as much hardware as a compatible AmigaOS pushed as far as possible while maintaining compatibility. With a large enough hardware base, it may be possible to transition to a true NG AmigaOS while allowing the old compatible AmigaOS to work on the same hardware. I can't see this ever happening as another OS on RPi hardware.

cdimauro Quote:

I was thinking more at some microkernels: https://en.wikipedia.org/wiki/Microkernel For example: https://en.wikipedia.org/wiki/Minix_3 https://en.wikipedia.org/wiki/QNX https://en.wikipedia.org/wiki/Redox_(operating_system) So, taking one of them as the foundation for new Amiga-ispired OS.

I did mention FreeRTOS which uses a microkernel for the RPi. Notice that your example OSs are not listed for the RPi either even though they may be compatible. There often isn't a standard OS with these embedded OSs as they are often customized and are difficult to install. Somewhat similar to these embedded OSs, the 68k AmigaOS provides a more standardized system but the tradeoff is more hardware dependence. Some of the embedded OSs have more features and support a similarly small footprint but few are available on standard hardware ready to go with software available for download without recompiling. We should look closer at the advantages of what we have before we do a transplant. The 68k AmigaOS has warts and beauty at the same time. It is different and may requires unique solutions.

@matthey

Quote:

matthey wrote: cdimauro Quote: That's really too much. You've to find a rich benefactor (former Amiga/Atari happy user) to sustain this project. Amiga Corporation was funded with $7 million USD by a few individual investors circa 1982. A 2012 Kickstarter raised $8.5 million USD for the microconsole Ouya and Ouya Inc. received at least $15 million USD in investments including from NVIDIA and Alibaba. Adjust these investments for inflation to put modern investments in perspective. I'll skip the pic of Dr. Evil asking for one million dollars in ransom.

OK, makes sense. How do you plan to proceed then?
Quote:

How much money do you think has been spent on THEA500 Mini, A600GS and PPC AmigaOS 4 hardware and development for hardware that is noncompetitive outside of the Amiga retro market?

The same ballpark as above (a bunch of millions)?
Quote:

cdimauro Quote: That's a no-go, you know: Gunnar is the sole one which decides on that project. Jens and Thomas let Gunnar play. He is doing most of the work and there is no serious interest to professionally develop the 68k Amiga from Amiga related businesses so why not? Jens and Thomas are more professional and reasonable than Gunnar. Jens developed the N68050 CPU core and Thomas SAGA for the Natami project so they have a say and may make other choices if there was a serious project. The Natami project should have been adopted by Amiga related businesses and PPC AmigaNOne terminated back when it was active. The Natami project was generating huge interest with no advertising while PPC AmigaNOne interest was anemic and already on the decline. THEA500 Mini has verified the huge retro 68k Amiga market but all we get is noncompetitive hardware while PPC AmigaNOne hardware production drops into the hundreds of units.

OK, but this doesn't change the situation. At the end, both Jens and Thomas joined the Apollo team, and Gunnar is still leading and deciding how to go on with the project.
Quote:

cdimauro Quote: To me SMP and 64-bit aren't the major problems with the AmigaOS: it's everything else (which I've reported on my last article). We know that it's very lightweight, super-responsive, and consumes less resources (but pay attention: that's because the graphic/audio assets of the time were also very limited and uses much less space compared to nowadays. And we didn't have very complicated but user-friendly software using technologies like HTML/CSS/JS), but let's say that you put in on a Set-Top-Box (so, competing with Android TV, Fire TV, WebOS, HarmonyOS, etc.): do you think that it works out well on this market? I don't, and for the reason that I've explained: it crashes with a breath. And you cannot sell this stuff to the general customers. You can't even sell it to other customers on different markets for exactly the same reasons. Is there any market where do you think that it can be used? I mean: large enough (in the millions ballpark) to justify an investment. The AmigaOS was reliable enough to be used for the Video Toaster, kiosks and at least one medical device.

Even NASA has used it. They took a risk. A big risk, in the last case.

However in those cases you just basically have a single application which is running, and if it's not stable enough and crashes... you're on your own anyway, having memory protection or not.
Quote:

These were often embedded devices sold with non-Amiga branding. The AmigaOS was successfully used for the desktop and consoles. There was no MMU, no zero page protection and no code protection for the majority of Amiga hardware. This could improve along with other hardware changes that improve Amiga compatibility.

Other times and single applications running (same as above). Nowadays it's a bit different.
Quote:

Certainly desktop expectations are higher today and I would not suggest advertising AmigaOS hardware for desktop use anymore than RPi hardware is advertised for the desktop but the reality is that some users will use it for this purpose and it should be adequate for this use.

The problem is that "desktop" software became way more complex and bigger since the Amiga time, so there's a very high risk that bugged applications causes instability problems.

That's why the desktop market is a no-go for platforms like the Amiga OS and its "successors".
Quote:

For retro computing/gaming, hobbyist and embedded use, full memory protection is unnecessary. While the use of a MMU for embedded systems is on the rise, many embedded systems still do not use a MMU.

Same as above: as long as you've just a single applications which is running, it MIGHT be acceptable.

My concern is about retro computing / gaming: usually you use a frontend which allows to play with several different systems. Each system can be quite complex to emulate, hence more subject to bugs and instabilities of the system, which ruins the user experience.
Quote:

The RP2040 SoC Cortex-M0+ cores only have a limited MPU as there is no option for a MMU for any Cortes-M cores. A Cortex-A core is required for a MMU while Thumb2 has disappearing from new Cortex-A cores leaving a big gap between small 32 bit Thumb Cortex-M cores and large AArch64 Cortex-A cores.

Indeed. ARM has (very strangely!) left a big door opened with its AArch64 without the top code density of Thumb.

There's a big opportunity here that cannot ignore, especially taking into account that 64-bit systems are the future.
Quote:

cdimauro Quote: That's like cheating: you're not fixing the problem but just moving it a little bit ahead the problem. First of all, it's not that efficient (see below). Second, and most important, this works as long as you can have a single SoC with everything inside. It doesn't work if you have multiple chips, because synchronizing them will become a nightmare to implement. Getting SMP working with existing 68k Amiga software compatibility would be amazing. Despite criticism of disabling multitasking and interrupts, the unusual at the time preemptive multitasking gives a chance to make it possible. I don't see a problem with hardware help as long as it is simple and optional. Multi-CPU SMP is dead on everything remotely affordable. HSA makes a similar assumption that the whole system is integrated on the same SoC and provides benefits from this. Weak memory models, like PPC uses, were designed for multi-CPU SMP where a stronger memory model is easier to use and may allow better compatibility with minimal performance loss for single chip multi-core SMP.

Yes, but it's not general: you always remain bounded to a single monolithic SoC.

The future is represented by chips split with several "tiles" where cores, caches, and accelerators are distributed and connected together, appearing like a single system. That's a big need because the more advanced fabric processes have yield problems and dividing the chips in smaller parts reduced the parts which broken and should be thrown away.

But adding extra logic to sync different cores only because Amiga OS was badly designed isn't a price that might be worth to be paid. Especially with all other big limits of the platform.
Quote:

cdimauro Quote: While blocking all other cores to run the critical section on just one isn't even a much higher cost? My point was that supporting SMP has a cost however it is implemented. Weak memory models require adding expensive sync/fence type of instructions, semaphores/mutexes add overhead and there can be competition overhead for resources. Flushing/syncing all other used cores for a Forbid() is more expensive when shared memory structures are not being accessed by other cores but this likely means they are accessing private memory which doesn't need to be flushed. That is why I have suggested a way to execute private memory without flushing and during the Forbid() to reduce overhead. Legacy code would not be able to take full advantage as memory would default to shared for compatibility but performance could be improved by simply changing memory allocation flags.

The problem with the legacy code is that you don't know how it uses the allocated memory.
If memory was allocated as "public" (which was very common), then you know that you can't "touch" it.
But even if it was allocated as "private", you still don't know how it was really being used.

The same happens with the application's hunk: you don't know if an application could write on its code hunks. Hence, you can't protect as read-only its pages.

All of this unless you've a database of legacy applications which were profiled and you know they behave and use their memory.

The hack that you proposed can work (with all performance problems), in theory, but it should be seen how "on the field".
Quote:

cdimauro Quote: Well, they are all on the same position: too limited. Removing the backward compatibile is a need, nowadays. The legacy can run on a sanbox. Otherwise there cannot be any possibility for the future. I'm not opposed to a NG AmigaOS that breaks backward compatibility but I don't think it will sell nearly as much hardware as a compatible AmigaOS pushed as far as possible while maintaining compatibility. With a large enough hardware base, it may be possible to transition to a true NG AmigaOS while allowing the old compatible AmigaOS to work on the same hardware. I can't see this ever happening as another OS on RPi hardware.

It might be possible, but then why crippling the future platform? It's better to split & isolate the old, legacy platform from the new one.

They can run together, but the legacy one is isolated on its sandbox and communicate with the new one like AROS does with JanosUAE.
Quote:

cdimauro Quote: I was thinking more at some microkernels: https://en.wikipedia.org/wiki/Microkernel For example: https://en.wikipedia.org/wiki/Minix_3 https://en.wikipedia.org/wiki/QNX https://en.wikipedia.org/wiki/Redox_(operating_system) So, taking one of them as the foundation for new Amiga-ispired OS. I did mention FreeRTOS which uses a microkernel for the RPi. Notice that your example OSs are not listed for the RPi either even though they may be compatible. There often isn't a standard OS with these embedded OSs as they are often customized and are difficult to install. Somewhat similar to these embedded OSs, the 68k AmigaOS provides a more standardized system but the tradeoff is more hardware dependence. Some of the embedded OSs have more features and support a similarly small footprint but few are available on standard hardware ready to go with software available for download without recompiling. We should look closer at the advantages of what we have before we do a transplant. The 68k AmigaOS has warts and beauty at the same time. It is different and may requires unique solutions.

In fact, it has a lot of things that could be borrowed. The important thing is to eliminate all the bad things and replace them with something which Amiga OS-inspired, but working well and with a good design.

@matthey

Quote:

It doesn't help that NG AmigaOS businesses have ignored and practically blocked 68k AmigaOS FPGA development that has a better chance to be NG than PPC PC hardware.

This is BS. I like my vampire but it is still many times slower than any ppc.

Quote:

matthey wrote: Linux is resource hungry so the developers bump requirements. This is an opportunity for a minimalist 32 bit AmigaOS.

This might have been true 20 years ago, AmigaOS may have been a good OS for a PDA, but today you can use Linux on cheap and small devices like the RasPI.

And if you have a power hungry application it doesn't matter if the OS 'steals' 3% or only 2% of overall performance. In the end modern OSes like Linux can compensate this easily with driver support for GPUs, WiFi, LAN , Bluetooth, USB, ...

@ppcamiga1

Or Pistorm

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

@pixie

He's traumatised by that. I think the PiStorm must've touched him in his no-no place.

_________________
Doing stupid things for fun...

cdimauro Quote:

OK, makes sense. How do you plan to proceed then?

It's still too hard to proceed. Uncertainty is an investment killer. More cooperation, planning and investment by Amiga businesses is required than current Amiga related projects but a competitive hardware project should be within financial reach.

cdimauro Quote:

OK, but this doesn't change the situation. At the end, both Jens and Thomas joined the Apollo team, and Gunnar is still leading and deciding how to go on with the project.

Gunnar has agreements and conditions to use SAGA and the N68050 core. Gunnar announced SAGA would be open sourced and Jens wanted to open source the N68050 core when I was part of the AC team. Gunnar is allowed to play but Thomas and Jens could have some influence and control if there was a real opportunity.

cdimauro Quote:

Even NASA has used it. They took a risk. A big risk, in the last case. However in those cases you just basically have a single application which is running, and if it's not stable enough and crashes... you're on your own anyway, having memory protection or not.

Fast booting, hardware power on after a power failure, being able to disable requestors, realtime.library and watchdog timers were embedded features that could be used for the Amiga. Without MMU usage, the AmigaOS was real time enough for many embedded applications. Also, C= produced affordable enough hardware to be used for embedded systems which is not true today.

cdimauro Quote:

Other times and single applications running (same as above). Nowadays it's a bit different.

Video Toaster owners often used multitasking without affecting switcher and video sync timing. Only a 68030@25MHz with 10MiB of memory was recommended.

cdimauro Quote:

The problem is that "desktop" software became way more complex and bigger since the Amiga time, so there's a very high risk that bugged applications causes instability problems. That's why the desktop market is a no-go for platforms like the Amiga OS and its "successors".

Stability is more challenging with faster processors, more cores and more resources. Still, people will use cheap hardware for lightweight desktop use like happens with RPi hardware. The 68k AmigaOS in WinUAE is stable enough for lightweight use. The same is likely true of PPC AmigaOS 4.

cdimauro Quote:

Yes, but it's not general: you always remain bounded to a single monolithic SoC. The future is represented by chips split with several "tiles" where cores, caches, and accelerators are distributed and connected together, appearing like a single system. That's a big need because the more advanced fabric processes have yield problems and dividing the chips in smaller parts reduced the parts which broken and should be thrown away. But adding extra logic to sync different cores only because Amiga OS was badly designed isn't a price that might be worth to be paid. Especially with all other big limits of the platform.

Cache coherency requires extra logic and lines with or without HSA. It looks worthwhile to integrate everything on chip for a SoC and keep everything cache coherent. There are limits for a single chip but they are pretty high. More than 16 CPU cores is barely worthwhile for a system so I don't have a problem being limited to that. Powerful integrated GPUs could outgrow a single chip SoC but these would be very powerful GPUs and the most powerful GPUs are not currently being integrated. Chip die shrinks will allow more transistors for high end SoCs even though they may be slowing.

Cache coherency is used to sync cores and units. There are commonly already connections between cores for coherency as well as other reasons. A few extra lines and transistors are not a big deal if they provide enough benefit. Getting SMP working while maintaining compatibility would be a large benefit. The lines may be useful for multi-core debugging purposes too.

cdimauro Quote:

It might be possible, but then why crippling the future platform? It's better to split & isolate the old, legacy platform from the new one. They can run together, but the legacy one is isolated on its sandbox and communicate with the new one like AROS does with JanosUAE.

I believe the legacy 68k AmigaOS would still be useful with a true NG AmigaOS available, especially on low end hardware. Low end affordable hardware with the legacy 68k AmigaOS is more likely to make the Amiga relevant than expensive high end hardware with a NG AmigaOS. It's difficult to be competitive on high end hardware and a competitive NG AmigaOS would be expensive to develop.

OneTimer1 Quote:

This might have been true 20 years ago, AmigaOS may have been a good OS for a PDA, but today you can use Linux on cheap and small devices like the RasPI. And if you have a power hungry application it doesn't matter if the OS 'steals' 3% or only 2% of overall performance. In the end modern OSes like Linux can compensate this easily with driver support for GPUs, WiFi, LAN , Bluetooth, USB, ...

While the AmigaOS is less competitive for high end embedded use today, the embedded market is much larger than 20 years ago with future growth expected to be strong. Small footprint lower end embedded systems where standard Linux distros do not perform well is a good place for the 68k AmigaOS, provided there is affordable 68k Amiga hardware available. A return to standard 68k Amiga hardware would solve the Amiga lack of "driver support" problem.

Last edited by matthey on 23-Feb-2024 at 11:37 PM.

@matthey

Quote:

matthey wrote: ... standard Linux distros do not perform well is a good place for the 68k AmigaOS, provided there is affordable 68k Amiga hardware available. A return to standard 68k Amiga hardware would solve the Amiga lack of "driver support" problem.

No, not at all.

68k AmigaOS has a lot of disadvantages

1. 68k AmigaOS is not modular.
2. 68k AmigaOS is partially in Assembler
3. There are no modern SoCs, that are AmigaOS 68k compatible
4. 68k AmigaOS has no integrated TCP/IP stack
5. 68k AmigaOs has an insecure shared memory model
6. 68k AmigaOS is a legal train wreck

If you don't believe you can take a look to the ESP32 platform, those SoCs are running circles around 68ks and they have unbelievable software support in comparison to 68k AmigaOS.

https://en.wikipedia.org/wiki/ESP32#Programming

Last edited by OneTimer1 on 24-Feb-2024 at 12:49 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: OK, but this doesn't change the situation. At the end, both Jens and Thomas joined the Apollo team, and Gunnar is still leading and deciding how to go on with the project. Gunnar has agreements and conditions to use SAGA and the N68050 core. Gunnar announced SAGA would be open sourced and Jens wanted to open source the N68050 core when I was part of the AC team. Gunnar is allowed to play but Thomas and Jens could have some influence and control if there was a real opportunity.

So, there's no real opportunity 'til now. And you can't expect any source code opening, after so long: it's clear evidente that they want to keep closed their goose that laid the golden eggs.

However, you were also in touch with Jens: you can contact him to see if there's some space for a different project.
Quote:

cdimauro Quote: The problem is that "desktop" software became way more complex and bigger since the Amiga time, so there's a very high risk that bugged applications causes instability problems. That's why the desktop market is a no-go for platforms like the Amiga OS and its "successors". Stability is more challenging with faster processors, more cores and more resources. Still, people will use cheap hardware for lightweight desktop use like happens with RPi hardware.

If RPi systems are Linux-based, then we're talking about several tents millions of lines of code which were used to build them. Even if "lightweight" compared to the major Linus distros, those are very big projects (overall, I mean) compared to the Amiga OS (and "successors").
Quote:

The 68k AmigaOS in WinUAE is stable enough for lightweight use.

The applications are simple and almost always the same: you can't expect surprises here (and plenty of bugs were fixed by passionate Amiga coders).
Quote:

The same is likely true of PPC AmigaOS 4.

It's a bit more, but not that much.

The only relevant thing is that they got more modern browsers, which nowadays are in the several millions of lines of code. So, very complicated stuff which can lead to system instabilities (e.g. memory leaks might force a system reboot after some time).
Quote:

cdimauro Quote: Yes, but it's not general: you always remain bounded to a single monolithic SoC. The future is represented by chips split with several "tiles" where cores, caches, and accelerators are distributed and connected together, appearing like a single system. That's a big need because the more advanced fabric processes have yield problems and dividing the chips in smaller parts reduced the parts which broken and should be thrown away. But adding extra logic to sync different cores only because Amiga OS was badly designed isn't a price that might be worth to be paid. Especially with all other big limits of the platform. Cache coherency requires extra logic and lines with or without HSA. It looks worthwhile to integrate everything on chip for a SoC and keep everything cache coherent. There are limits for a single chip but they are pretty high. More than 16 CPU cores is barely worthwhile for a system so I don't have a problem being limited to that. Powerful integrated GPUs could outgrow a single chip SoC but these would be very powerful GPUs and the most powerful GPUs are not currently being integrated. Chip die shrinks will allow more transistors for high end SoCs even though they may be slowing. Cache coherency is used to sync cores and units. There are commonly already connections between cores for coherency as well as other reasons. A few extra lines and transistors are not a big deal if they provide enough benefit. Getting SMP working while maintaining compatibility would be a large benefit. The lines may be useful for multi-core debugging purposes too.

So, you want to stay with a single SoC. No multi-chips for the future.

That could be a good compromise.
Quote:

cdimauro Quote: It might be possible, but then why crippling the future platform? It's better to split & isolate the old, legacy platform from the new one. They can run together, but the legacy one is isolated on its sandbox and communicate with the new one like AROS does with JanosUAE. I believe the legacy 68k AmigaOS would still be useful with a true NG AmigaOS available, especially on low end hardware. Low end affordable hardware with the legacy 68k AmigaOS is more likely to make the Amiga relevant than expensive high end hardware with a NG AmigaOS. It's difficult to be competitive on high end hardware and a competitive NG AmigaOS would be expensive to develop.

But I don't see the problem here. The legacy stuff can run and take advantage of the better hardware in some ways (e.g.: more processing power), while everything else is running on the new Amiga platform and taking advantage of the whole new platform.

It's "only" about setting the legacy stuff in the stone and... go ahead with the new project.

@OneTimer1

Quote:

OneTimer1 wrote: @matthey Quote: matthey wrote: ... standard Linux distros do not perform well is a good place for the 68k AmigaOS, provided there is affordable 68k Amiga hardware available. A return to standard 68k Amiga hardware would solve the Amiga lack of "driver support" problem. No, not at all. 68k AmigaOS has a lot of disadvantages 1. 68k AmigaOS is not modular.

Why? It had libraries (and devices) since day one.
Quote:

2. 68k AmigaOS is partially in Assembler

There's AROS which is entirely written in C, some many parts can be copied from it.
Quote:

4. 68k AmigaOS has no integrated TCP/IP stack

It can be added. It was already available by third-party in the Amiga time.

Now, you can borrow it from AROS.
Quote:

6. 68k AmigaOS is a legal train wreck

Then use AROS, which has 100% 3.1 API compatibility.
Quote:

If you don't believe you can take a look to the ESP32 platform, those SoCs are running circles around 68ks and they have unbelievable software support in comparison to 68k AmigaOS. https://en.wikipedia.org/wiki/ESP32#Programming

Of course: it's well alive. The Amiga platform substantially died with Commodore.

@cdimauro

Quote:

1. 68k AmigaOS is not modular.

Quote:

Why? It had libraries (and devices) since day one.

Cesare is right.
AmigaOS is very modular

@Gunnar

Quote:

Gunnar wrote: AmigaOS is very modular

OK, so name me an industrial user who does use a 68k AmigaOS as an IoT device, it should only need bluetooth some I/Os and run on a 68k SoC with it's built in 64k of RAM.

In reality we are using MIPS/RiscV system with RTOS (used in some Arduinos) as WiFi interfaces for Amigas ... running them on AmigaOS? No!

RTOS is free and it is exactly what I would call modular.

Last edited by OneTimer1 on 24-Feb-2024 at 11:47 PM.
Last edited by OneTimer1 on 24-Feb-2024 at 10:29 PM.
Last edited by OneTimer1 on 24-Feb-2024 at 10:29 PM.

@OneTimer1

Quote:

OneTimer1 wrote: @Gunnar Quote: Gunnar wrote: AmigaOS is very modular OK, so name me an industrial user who does use a 68k AmigaOS as an IoT device,

That's a Red Herring. You're changing the topic here.

You made a PRECISE statement and you got the PRECISE reply on it.

If you don't like my reply I've no problem: I didn't like your, because it was clearly reporting a false statement.
Quote:

it should only need bluetooth some I/Os

What's the problem? Provide the proper .device and that's it.

The AmigaOS had plenty of drivers developed for several devices that had nothing to do with the original hardware.
Quote:

and run on a 68k SoC with it's built in 64k of RAM.

What's the problem? Provide the SoC and the Amiga OS will run even with just 64kB of RAM.
Quote:

In reality we are using MIPS/RiscV system with RTOS (used in some Arduinos) as WiFi interfaces for Amigas ... running them on AmigaOS? No! RTOS is free and it is exactly what I would call modular.

Again, Red Herring. You're trying again to change the topic.

It seems that logic isn't your friend, eh?

@cdimauro

Quote:

cdimauro wrote: Again, Red Herring. You're trying again to change the topic.

The topic is "32-bit PPC on FPGA" but people stopped writing about it, after it was explained why a slow PPC is a bad idea.

cdimauro Quote:

So, there's no real opportunity 'til now. And you can't expect any source code opening, after so long: it's clear evidente that they want to keep closed their goose that laid the golden eggs. However, you were also in touch with Jens: you can contact him to see if there's some space for a different project.

The Natami project led by Thomas Hirsch was very open and transparent with a clear goal to revive the 68k Amiga.

http://obligement.free.fr/articles_traduction/itwmichalakakos_en.php Quote:

Thomas Hirsch, the creator, wanted to revive the Amiga long ago. He worked for many years rebuilding the OCS and AGA chipsets. Gunnar von Boehn and Peter Kaltstein were working on their daily jobs in the same department of a hardware development lab as Thomas. They teamed up with Thomas to help him to get the NatAmi out, and were very motivated by seeing the 1st prototype in action at an Amiga-meeting in 2008. Soon after, more people joined the team. The original prototype was designed like an A4000 using 50MHz memory. But starting in 2008, Thomas has been redesigning the Amiga DMA engines to make full use of modern memory. This means that memory bandwidth is greatly enhanced.

Jens had a similar philosophy as Thomas and tried to open the N68050 CPU core created for the Natami project. Is there any question where the closed hardware secretive cult philosophy came from?

The Natami project was too hard lacking a high performance 68k CPU core and being blocked by AmigaNOne IP squatters. While AmigaNOne hardware was selling in the low thousands, the open and transparent Natami project generated huge interest without advertising. The Natami "MX Bringup Thread" had 761,487 views at one point and likely went significantly higher.

Natami "MX Bringup Thread" Quote:

First true enhancement For the first time on the MX board it is getting exciting, even for me. Till now I was "only" adapting the LX design to the new board. OK, by doing that I made quite huge progress in stability and usability. The board can now even be operated stand-alone. But this were just all the many mandatory things needed for the completeness of the system itself. But now... I was able (and had the time) to improve, or rather extend ECS. As you (hopefully) know, OCS had a hard wired frame generator. Because of that there were two different Agnus chips, one for NTSC and one for PAL. With ECS this issue was resolved in a quite superior manner. They did not only implement a NTSC/PAL switch but also added a complete set set of frame generation registers. From that on there was no limitation to the screen size anymore. Even the A2024 resolutions (1024x1024) were possible. This was a lot more than a common PC could offer that time (in 1988). With the ECS frame generator it was even possible to display some VGA screen modes as 640x480. But there was still one limitation. The pixel clock was limited to fixed 28MHz. For the A2024 this was no problem, the refresh rate was set to 10Hz and the monitor itself had a built in frame buffer to display the image content at a much higher frequency. VGA and Multisync monitors had no internal memory. So this technique could not be used and resolutions that high as the A2024 were not possible to display on them. And even the 800x600 resolution needed to be in interlace because of the in comparison low pixel frequency. AGA did increase the color depth and the overall number of colors available, but left the pixel clock unchangeable. The pixel clock on the Natami is not generated by an external oscillator. It is synthesized by a programmable PLL (Phase Locked Loop). Its frequency can be changed at run time. I now implemented an interface which allows the PLL being accessed through DFF registers. With that I am able to set up a basic screen resolution of 1280x1024 in 60Hz for a functionality test. Not system friendly, just a part of a memory field and mouse pointer. But it actually works. I have known it from the beginning that it is possible and will work, but seeing that the Natami can now match the native resolution of my test TFT is something different! I`ll send a design update to Annika as soon as I can. And the second good news is that with the new resolution I was able to confirm that the digital portion of DVI is also working. Chipset Features (new) Frame generation .......... ECS and variable pixel clock -> UCS SyncZorro Interface ....... preliminary version Copper .................... fully implemented, with buffered data fetch Video DMA ................. fully implemented 256 color registers ....... fully implemented AGA HAM8 .................. fully implemented Sprites ................... 16bit linebuffer blitter ................... basic implementation. Block and fill mode only, line to come Video priority ............ half implemented Scandoubler ............... fully implemented Interrupts ................ fully implemented Paula DMA control ......... fully implemented Audio out ................. fully implemented Disk DMA .................. 880k and 1760k, read only Serial Port Paula UART .... fully implemented Slow peripheral I/O ....... fully implemented (Joy/Mouse/Keyb/PRT/DSK/SER) PC mouse and kbd support .. o CIAs ...................... fully implemented Board Features VGA out (DVI-A) ........... working (new) DVI out (DVI-D) ........... working PCI ....................... transfer only, arbiter and config missing IDE ....................... PIO mode 0 working Compact Flash connector ... o NEC USB PCI ............... o RTL 8110 LAN .............. o Battery-backed up clock.... working 15k Video out (module) .... o 15k Video in (module) ..... o Audio in .................. o

The more open and transparent Natami project felt to me like it generated more excitement than the AC/Vamp project. I posted the Natami "MX Bringup Thread" views to various Amiga forums claiming this was an indication of a large 68k Amiga retro market but it was largely discounted. It wasn't until later that THEA500 Mini success backed up my claims and suggested that there may be a large enough market for mass production and creating competitive affordable hardware. I would have also liked to see a professionally developed "revived" retro 68k Amiga but some things are too hard in Amiga Neverland.

OneTimer1 Quote:

OK, so name me an industrial user who does use a 68k AmigaOS as an IoT device, it should only need bluetooth some I/Os and run on a 68k SoC with it's built in 64k of RAM.

Nobody uses the 68k AmigaOS for embedded use anymore as there is no competitive affordable 68k Amiga hardware. We have PPC AmigaNOne nonproliferation of the AmigaOS in a tiny declining market due to Amiga IP squatters for decades instead.

OneTimer1 Quote:

In reality we are using MIPS/RiscV system with RTOS (used in some Arduinos) as WiFi interfaces for Amigas ... running them on AmigaOS? No! RTOS is free and it is exactly what I would call modular.

MIPS/RISC-V and not ARM, ARM, ARM? RTOS is free but some developers prefer the AmigaOS.

https://forums.freertos.org/t/task-blocking-on-various-types-of-primitives/12394 Quote:

I suppose that WaitForMultipleObjects() would fit the bill. Another quite-visible example would be the way the Amiga OS handled blocking; a single primitive called ‘Signals’ (bitwise, much like Task Notification) was the root of most of the higher level blocking primitives. If I wanted to wait on a socket, a Message Port (think Message Queue), and a bitmap of Signals, I’d get the signal # for the socket, get the signal # for the Message Port, OR it with the bitmap of the Signals I already wanted, and wait on the set. When woke, I could determine which ones woke the thread and could process them. Credit to a fellow named Carl Sassenrath for that. Simply, there’s a shared primitive. I was hoping for anything like the NT model (which isn’t RT friendly, but it’s also open-ended), or the Signal model above (which actually is RT friendly). Thanks again to all for the replies; I’ll go see if I can either push Message Queues on top of Task Notifications (shared primitive path) or see if I can just use Semaphores instead of Task Notifications (path of least resistance).

Many young developers probably don't know what they are missing and maybe a few older ones have forgotten.

@matthey

as we all know ainc after hp agreement has right to made amiga in joystick
but failded to do that
so stop your bs about Amiga IP squatters

@matthey

We Amiga users use ppc Amiga because it it better Amiga than these made by Commodore after Amiga 500

@matthey

Quote:

Amiga Corporation was funded with $7 million USD by a few individual investors circa 1982. A 2012 Kickstarter raised $8.5 million USD for the microconsole Ouya and Ouya Inc. received at least $15 million USD in investments including from NVIDIA and Alibaba. Adjust these investments for inflation to put modern investments in perspective. I'll skip the pic of Dr. Evil asking for one million dollars in ransom. How much money do you think has been spent on THEA500 Mini, A600GS and PPC AmigaOS 4 hardware and development for hardware that is noncompetitive outside of the Amiga retro market?

NVIDIA funding Ouya is based on NVIDIA's self-interest e.g. GeForce Now and Andriod-based Shield TV.

https://techcrunch.com/2013/05/09/ouya-closes-15-million-in-funding-led-by-kleiner-perkins-boasts-12000-game-developer-sign-ups/

OUYA announced that they have closed a $15 million round led by Kleiner Perkins, and with participation from the Mayfield Fund, NVIDIA, Shasta Ventures and Occam Partners.

OUYA is a company that launched back in 2012 on Kickstarter under the guiding hands of Julie Uhrman, a video game industry veteran who believes that gaming should be affordable and enjoyable for everyone. She and the team developed a $99 Android gaming console, which hooks into the TV and comes with automatic access to free-to-try games. It launched on the crowdfunding site to much fanfare, scoring $8.6 million in funding, which ends up being around 9x more than OUYA asked.

Along with the $15 million round, which brings OUYA’s total amount of funding to $23.5 million, the company will also be bringing KPCB General Partner Bing Gordon on to the board of directors.

$99 Android games console is the focal point.

Project status: failed.
-----

Another Kickstarter such as Framework Computer has found better success. https://en.wikipedia.org/wiki/Framework_Computer

In the first half of 2021, the company was funded with a $9 million seed round.

In January 2022, the company raised an additional $18 million of financing in a series A round, led by Spark Capital.

Framework's total funding is $27 million. "Rights to repair" for laptops are its focal point.
Framework is attempting to bring desktop PC modularity to PC laptops.

Project status: growth phase.

Last edited by Hammer on 26-Feb-2024 at 04:22 AM.
Last edited by Hammer on 26-Feb-2024 at 04:22 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

Cache coherency requires extra logic and lines with or without HSA. It looks worthwhile to integrate everything on chip for a SoC and keep everything cache coherent. There are limits for a single chip but they are pretty high. More than 16 CPU cores is barely worthwhile for a system so I don't have a problem being limited to that. Powerful integrated GPUs could outgrow a single chip SoC but these would be very powerful GPUs and the most powerful GPUs are not currently being integrated. Chip die shrinks will allow more transistors for high end SoCs even though they may be slowing. Cache coherency is used to sync cores and units. There are commonly already connections between cores for coherency as well as other reasons. A few extra lines and transistors are not a big deal if they provide enough benefit. Getting SMP working while maintaining compatibility would be a large benefit. The lines may be useful for multi-core debugging purposes too.

NVIDIA's RTX GpGPU has custom RISC-V CPU, hence it's technically an APU. This custom RISC-V CPU is hidden from public view.

NVIDIA is focusing on ARM Holdings's Neoverse CPUs. https://nvidianews.nvidia.com/news/softbank-telecom-data-centers-grace-hopper

Nvidia tried and failed to buy Arm for $40 billion in 2020, but it just reported a stake worth $147.3 million
https://fortune.com/2024/02/14/nvidia-reports-stake-in-arm-ai-semiconductor-chips/

Nvidia included the information in a 13F form filed with the US Securities and Exchange Commission on Wednesday, giving a glimpse at the closely watched company’s investment strategy. It has a history with Arm, which Nvidia attempted to acquire for $40 billion in 2020. That deal ultimately crumbled under regulatory pressure, and Nvidia walked away in February 2022. Arm was up 2.9% on Thursday as trading got underway in New York

Nvidia included the information in a 13F form filed with the US Securities and Exchange Commission on Wednesday, giving a glimpse at the closely watched company’s investment strategy. It has a history with Arm, which Nvidia attempted to acquire for $40 billion in 2020. That deal ultimately crumbled under regulatory pressure, and Nvidia walked away in February 2022. Arm was up 2.9% on Thursday as trading got underway in New York.


https://www.cgdirector.com/cinebench-2024-scores/
For Cinebench 2024 GPU raytracing benchmarks,
Nvidia RTX 4090 Mobile scored 25939. This SKU has AD103 ASIC which is RTX 4080 desktop.
Nvidia RTX 4080 Mobile scored 17780. This SKU has AD104 ASIC which is RTX 4070 desktop.
NVIDIA GeForce RTX 4060 Ti (34 SM) scored 15,482.
AMD Radeon RX 7900 XTX(96 CU) scored 15,107
Nvidia RTX 3080 (68 SM) scored 14,138
AMD Radeon RX 7900 XT (84 CU) scored 13,860
Apple's M3 Max's integrated (40 cores) GPU scored: 12,980

During CES 2024, AMD's discrete GPU business has NO Y2024 laptop design win.

The strongest GPU with SoC is Apple's M3 Max's 40 cores GPU. AMD fukc'ed up.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)