@Hypex

Quote:

X86 must be a lot better at backwards compatibility. Plust they have the money and resources to retrofit modern features onto an ancient design.

Modern PC's "ancient design" obliterates Amiga 4000, Vampire V4, X1000, and X5000 designs.

ACPI HAL reference design is not ancient IBM AT HAL. ACPI HAL reference design has existed since Windows 98.

From https://uefi.org/faq-page
Q: What are the benefits to implementing the ACPI standard?

A: The benefits to using the ACPI standard include enhanced power management functionality and a robust interface for configuring motherboard devices. ACPI offers stability and backward-compatibility for legacy operating systems running on new hardware, without requiring major re-writes or re-builds of the software stack. This provides an open application platform that sits on top of standard compliant firmware. The hardware-discovery and hard-control, separated by the ACPI abstraction layer, allows OSes to condense test-case scenarios to a single image test. This reduces engineering expenses, as the AML (ACPI Machine Language) encoding embedded within the ACPI tables removes the need for the kernel image to contain individual drivers.


Why was the ACPI standard created?
A: The ACPI specification was created to define a standard model for controlling power state transitions and enabling new platform technologies to evolve independently in the operating system and hardware. Prior to the ACPI standard, custom vendor solutions for power management and system configuration inundated the market. Each proprietary solution required custom OS support, resulting in market fragmentation and influencing the demand for standardized firmware solutions.

Intel, Microsoft, Toshiba, HP and Phoenix set out to unify system power management through the ACPI standard. Over time, the ACPI standard replaced a collection of power management application-programming interfaces (APIs), such as Advanced Power Management (APM), as well as system configuration interfaces such like PNPBIOS APIs and the MultiProcessor Specification (MPS) for x86 architecture. More recently, bindings for ARM architecture and SoC devices were added in the ACPI v5.0 release.
---------------
ACPI is an abstruction layer. WIndows targets ACPI HAL. X86 motherboard vendors target the ACPI layer.


Quote:

But I think this is a PPC thing. Even Apples needed the specific rescue CD or it crashed. Poor codng there. PPC chips, by design or purposely, are not compatible with each other and there are too many versions in a small market. The supervisor codes all differ. A G3/G4 Linux kernel will crash on a PA6T and a Sam440. Even the 68K series wasn't transparently upward compatible but at least one AmigaOS version was optimised to for all CPUs and in the least ran on them all.

Like 68K based desktop computers, the PowerPC industry is stuck in the pre-ACPI balkanization era.

Intel and Microsoft enforced the ACPI standard for the X86 PC industry.


Quote:

It needed to be. It was the worse CPU they could pick. No standard FPU and only hybrid SPE taking up AltiVec space. In some ways it would be like an Amiga with a ColdFire CPU with a 68K that needed to be patched heavily to run on it and also program to be run patched. Except the A1222 CPU is at least binary compatible with most integer user code. Wait its just like the ColdFire idea!

I'm aware of Shapeshifter's patching MacOS 68K to it make work with 68060.

Atm, I'm trying to figure out the reason for MacOS 8.1 install CD's desktop freeze with Fusion 3.1 and 68060 (TF1260).

_________________
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)

@Hypex Quote:

Hypex wrote: X86 must be a lot better at backwards compatibility.

It IS, indeed. Whereas Motorola/Freescale and IBM didn't care at all about it for 68K and PowerPC.
Quote:

Plust they have the money and resources to retrofit modern features onto an ancient design.

Ah, yes: Motorola/Freescale and IBM were poor companies lacking capitals. I see it, yes I see it...

@Hammer

Quote:

Like 68K based desktop computers, the PowerPC industry is stuck in the pre-ACPI balkanization era.

I have PowerPC PA-SEMI chip, I have you change clock frequency from CFE, and switch core, and you have temperature sensors, all that. The graphic card we have standard PC graphic cards they also have same stuff, sensors, programable clock, and so on.

So for me it bit strange talk about as if ACPI as something is in the hardware, sure it need some hardware support, but ACPI is mostly OS/BIOS thing.

https://www.researchgate.net/profile/Luca-Benini/publication/283482717/figure/fig10/AS:669562102112259@1536647453098/ACPI-interface-and-PC-platform.pbm

Last edited by NutsAboutAmiga on 02-Oct-2021 at 09:42 AM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 09:41 AM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 09:22 AM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 09:04 AM.

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

@Hypex

Quote:

After all, the X1000 was a remake of the Electra board. Which was exacty like the ACK board announced before it.

ACK was well known for false promises and vaporware (PowerVixxen accelerator anyone?). There was never an ACK board or any other announced hardware.

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Quote: Like 68K based desktop computers, the PowerPC industry is stuck in the pre-ACPI balkanization era. I have PowerPC PA-SEMI chip, I have you change clock frequency from CFE, and switch core, and you have temperature sensors, all that. The graphic card we have standard PC graphic cards they also have same stuff, sensors, programable clock, and so on. So for me it bit strange talk about as if ACPI as something is in the hardware, sure it need some hardware support, but ACPI is mostly OS/BIOS thing. https://www.researchgate.net/profile/Luca-Benini/publication/283482717/figure/fig10/AS:669562102112259@1536647453098/ACPI-interface-and-PC-platform.pbm

And due that same level of standardisation you can run same GFX cards on your PA-SEMI chip equiped X1000 than Moto chip X5000 right?.... Oh... You can't.

@Rose

Well yes, older cards, mostly work on all computers, but newer cards is the problem buy Apple computer and the next year its not supported, (all updates stops). its same for everyone. Buy 3G mobile phone, next day, telecom providers stop using 3G.
Try surf the internet with Amiga1200, NDK/SDK's is too old, and browsers are outdated.

Its not that I can’t use RX card, it that can’t see CFE while booting, if I did.

I’m not sure who is responsible for CFE, EexcSG team, Varisys, Hyperion, AEON, but it be great if it was updated for sure. The surprise update from ACube-System for there UBOOT on Sam440 and Sam460 was really applicated for sure.

Last edited by NutsAboutAmiga on 02-Oct-2021 at 06:39 PM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 12:07 PM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 12:01 PM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 12:00 PM.

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

@NutsAboutAmiga

Quote:

I’m not sure who is responsible for CFE, EexcSG team, Varisys, Hyperion, AEON, but it be great if it was updated for sure.

I'd rather see updates for the firmware of the Pegasos 2 and AmigaOne XE. The XE is only known to work with cards upto and including the 4000 series and noboday has had success with SI and RX cards. The Peg 2 won't even see anything the other side of a PCI to PCIe bridge. Both systems are fairly powerful in terms of OS4 hardware, especially the G4 models and the ability to use SI and RX cards would probably help A-EON shift a few hundred more copies of Enhancer.

@Rob

I think it be good idea to standardize the firmware, OpenFirmware, CFE and UBOOT, that’s two firmware's too many, my guess is its going make more difficult to have synergy.

And also it Genesi tatt made that hardware, someone can always send e-mail and ask if they wont do it, and what it will cost.

Genesi hardware Pegasus1 had lot in common with AmigaONE-XE/SE same chips, its almost strange that AmigaOS4 did run on Pegasus1.

Last edited by NutsAboutAmiga on 18-Oct-2021 at 08:14 PM.
Last edited by NutsAboutAmiga on 02-Oct-2021 at 06:35 PM.

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

@Rob

I wont mind paying for it, knowing its maybe not lot X1000 users,
yes it be cool to get updated firmware for PegII, it uses OpenFirmware.
and AmigaONE-XE is again an UBOOT machine, maybe ACube-Systsem can do it, but XE has always been flaky, and can get easily bricked if flashing goes wrong.

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

@NutsAboutAmiga

Ever thought why it's called OPENfirmware?

https://github.com/openbios/openfirmware

@Rose

The Pegasos 2 uses a proprietary derivative called SmartFirmware that's not open source.

_________________
This is just like television, only you can see much further.

Quote:

Hammer wrote: The problem with PowerPC is balkanization when there's an IBM Power 9 Raptor BlackBird (motherboard with PCIe version 4.0) bundle and AmigaOS 4.1 doesn't run on it.

Balkanization is the fragmentation of a larger region or state into smaller regions or states, which may be hostile or uncooperative with one another.

If we would have some kind of Balkanization on PowerPCs, we would have a lot of independent and competing companies, producing a wide range of cheap PowerPC boards.

We have none of this.

And the company owning the right to port AOS4, never supported most of them in the past.

@NutsAboutAmiga

Quote:

XE has always been flaky, and can get easily bricked if flashing goes wrong.

The chip can also be easily removed and reprogrammed in an external device if something goes wrong.

@SHADES Quote:

SHADES wrote: Multi-core support is now required instead of a nice to have. (This has been the case for many years already, legacy can be sandboxed if there is no other option.)

I forgot this important point. Do you think that after ELEVEN years you'll get it?

https://amigaworld.net//modules/news/article.php?storyid=5781
The PA6T CPU paves the way for the introduction of SMP with AmigaOS4.x. Also check out the new multi-core CPUs being developed by Freescale, in particular the 64-bit dual core, 2.2 GHz P5020 and the 8-core, 1.5GHz P4080.

https://blog.hyperion-entertainment.com/the-state-of-opengl-on-amigaos/
Finally, multi-threading and multi-CPU support is an important factor. If you are aiming at making a system an integral part of the OS, then support for multithreaded operation is as much a requirement as support of multiple CPU’s.

https://blog.hyperion-entertainment.com/happy-easter/
Exec SG : kernel development has been forked off into an experimental and stable branch, to facilitate field testing of potentially drastically new features such as the scheduler, separate address spaces, 64 bit address space awareness etc.
The task scheduler was completely rewritten in C and now implements the long planned “pluggable” scheduler functionality : the scheduling algorithm can be changed on the fly, during runtime depending on factors like task’s preference and CPU load, different CPU cores using different scheduling algorithms. The re-write of the scheduler also allows for load balancing which is required for proper multicore support.

https://blog.hyperion-entertainment.com/amiwest-2013-amigaos-team/
Gallium3D Update
Software rendering completed
Working on the WinSys part of the implementation
Challenges encountered along the way:
Must be re-entrant, thread safe and multicore capable

X-Kernel Update
Task scheduler rewritten in C
Removed reliance on data structures (e.g. ExecBase task lists and ThisTask pointer)
Moving scheduler to run on auxiliary cores
All cores schedule tasks independently
Load balancing between cores

AmigaOS 4.2
Depends on Gallium3D release
May or may not depend on multicore support

https://blog.hyperion-entertainment.com/multicore-and-amiga-present-and-future/
Where are we now ?
The development of SMP support has been separated into several distinctive steps. The first step was to rewrite the scheduler in C for easier accessibility. In the very end, this step might be reversed again, rewriting the then SMP capable scheduler back into assembly language. The second, more fundamental step was to decouple the scheduler from its current data structures. As you might know, ExecBase contains a lot of list for task that are ready, or waiting for a signal.

This has now been achieved. The current development build uses a scheduler that no longer uses the original AmigaOS data structures, but a structure that is replicated for each core.

The next step is to have each core in the development system (currently, the X1000) to run the scheduler. Test code will then start tasks on the different cores and see how they behave. We have already experimented with this and the results look promising. The tests basically showed that the lockout mechanism for Forbid works as planned.

As a final step, the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS.




My previous comment (still relevant) on the topic:
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43188&forum=17&start=20&viewmode=flat&order=0
According to the "Where are we now ?", this is what should be still missing:

"the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS"

It means that you can introduce even the stupidest and simplest load balancer, and you have a working OS4 SMP system!

Do you believe that in 4 (FOUR) years they had no time to implement it, and finally give SMP to their customers (which are waiting from MORE THAN 4 years)?




BTW SMP (after some years converted to a generic "multicore support", because SMP is clearly impossible on the post-Amiga land without breaking backward-compatibility) wasn't the only promise which Hyperion did and never maintained (Gallium3D was the second most important thing).

Is here or somewhere else any people which is still convinced that OS4 is not really dead?

SMP support is just one of many OS4 things that weren't thought through at all before being promised. Just because PC world has adopted SMP, who says it's the only way? If you have second core, you could use it as slave coprocessor and there's lots of applications for that.

For example, you could run your Amiga chipset software emulation on it, if only you hadn't also made the (faulty) assumption that you would never be able to reverse engineer it well enough to reproduce it in software.

Or in the same way that Thomas' MMU libraries can be used to allow a single application to create it's own private virtual memory, rather than assuming it needs to be a system provided global service, you could also have an API that let's you spin up discrete critical sections of code that need to be high performance and also somehow benefit from running asynchronously, which again, is not really so common a feature that all apps need - but could be useful say for games for their enemy AI logic - and run those, and only those, on the second core, the OS could even run some of it's asynchronous system services such as the input handler on the second core so that you never get input lockups because the main core is busy.

By the way this is how the PS3 used it's EIGHT cores. It didn't try to make each core capable of running any thread/process, as a developer for PS3, you decided which pieces ran on which cores, so that you could keep things that were separate, separate and not have to worry about shared memory access, semaphores, race conditions etc etc.

_________________

Quote:

Mobileconnect wrote: SMP support is just one of many OS4 things that weren't thought through at all before being promised. Just because PC world has adopted SMP, who says it's the only way? If you have second core,...

The biggest PC performance improvement in the last 10 years, where not archived by the improvement of clock frequencies, they where made by the implementation of more and more CPU cores.

SMP is the best way spreading all the processes and tasks over all the existing CPU cores.

Quote:

For example, you could run your Amiga chipset software emulation ...

Chipset emulation is a bad idea, no one using a PC under Windows or Linux would think about the emulation of dead pre 1990 hardware. The technology is going forth, not backwards.

Quote:

By the way this is how the PS3 used it's EIGHT cores.

Not being fully SMP capable is one of the reasons why this chip failed in the open market.

I'm currently using a super cheap AMD 64 PC with 8 cores running Linux with SMP, the tasks for networking, audio, grafik are all spread over the different cores without any boundaries to a certain type of core.

Last edited by OneTimer1 on 03-Oct-2021 at 01:25 PM.

@OneTimer1

Quote:

Chipset emulation is a bad idea, no one using a PC under Windows or Linux would think about the emulation of dead pre 1990 hardware.

I don't get the desire for chipset emulation or a plugin card either. Most the software you'll want the chipset for isn't system friendly and WHDLoad won't work just like it doesn't work on OS4 PowerUP cards.

@Mobileconnect Quote:

Mobileconnect wrote: SMP support is just one of many OS4 things that weren't thought through at all before being promised.

And do you who is responsible for this lack of thought? People which, on paper, should know how the Amiga o.s. works much better than anyone else...
Quote:

Just because PC world has adopted SMP, who says it's the only way?

Not me: I know/know very well that there are different ways to use multiple cores, and I've already written, still on this forum years ago, which ones they are, and what problems / limits they have.

But if someone promised the SMP, then it should exactly know what does it mean: SMP was repeated several times by OS4 developers (especially the technical lead), and it was also clearly repeated on the last link which reported the work on OS4 was practically done.
Quote:

If you have second core, you could use it as slave coprocessor and there's lots of applications for that.

Sure but, as OneTimer1 already reported, it's not the best way to use the additional cores, and it requires additional effort for the developers that they have use it.

There should be a reason why SMP is so wide-spread, don't you think?
Quote:

For example, you could run your Amiga chipset software emulation on it, if only you hadn't also made the (faulty) assumption that you would never be able to reverse engineer it well enough to reproduce it in software.

You don't need to reverse engineer it, because someone has posted the schematics (and Toni Wilen is already working on implementing them on the new WinUAE version).

This clarified, why do you want to offload the Amiga chipset emulation to another core? To free the other core(s) for making other tasks, right?

Ideally yes, but do you have even a rough idea of how an entire Amiga works, and consequently of the enormous challenges which this task requires to pass? Ask Toni Wilen, which knows it very well...
Quote:

Or in the same way that Thomas' MMU libraries can be used to allow a single application to create it's own private virtual memory, rather than assuming it needs to be a system provided global service,

Virtual memory didn't worked well on Amiga: you should know it, and you should also know the reasons.
Quote:

you could also have an API that let's you spin up discrete critical sections of code that need to be high performance and also somehow benefit from running asynchronously, which again, is not really so common a feature that all apps need - but could be useful say for games for their enemy AI logic - and run those, and only those, on the second core,

Sure, and you can do it using an AMP design. The Amiga o.s. was/is already an (heterogeneous) AMP o.s./platform. But this requires more effort and a clever coding by developers (and you don't have many of them left on the Amiga scene).
Quote:

the OS could even run some of it's asynchronous system services such as the input handler on the second core so that you never get input lockups because the main core is busy.

Sure again, but who'll take the burden to rewrite the Amiga o.s. (or at least some parts of it) in a AMP-aware platform? Are the benefits enough to justify this effort (and keeping in mind the actually most of the PowerPC AmigaOne systems are single core, so it should continue to work seamlessly on them)?
Quote:

By the way this is how the PS3 used it's EIGHT cores. It didn't try to make each core capable of running any thread/process, as a developer for PS3, you decided which pieces ran on which cores, so that you could keep things that were separate, separate and not have to worry about shared memory access, semaphores, race conditions etc etc.

OneTimer1 already replied, but I just want to add: and this is the reason why Sony moved to a SMP system for its subsequent consoles. The burden on both the o.s. and the applications was too high.

@cdimauro

Quote:

cdimauro wrote: @Mobileconnect Quote: Mobileconnect wrote: SMP support is just one of many OS4 things that weren't thought through at all before being promised. And do you who is responsible for this lack of thought? People which, on paper, should know how the Amiga o.s. works much better than anyone else...

There wasn't a lack of thought. They knew the flaws of Amiga OS and the original plan always involved breaking compatibility at some point. Bolting AMP onto the existing OS seems to have been a later plan that differed to the original and probably came about due to lack of resources to restructure the OS entirely.

Quote:

FWIW, I am not saying that AmigaOS 4.0 is a dead end design. However, everybody with half a brain cell will agree that to evolve the current design, you need to do something about the way certain things are handled right now. Apple did the same thing. They invented the Classic environment for binary compatibility, Carbon for source code compatibility, and Cocoa for the new stuff. This is very similar to what we want to do: - A virtual environment to run classic OS 4 binaries in. - A compatibility library that will allow you to compile OS 4 source code to the new system, trying to stay as compatible as possible and to go with as little changes as possible, with possibilities to narrow down incompatibilities (like with Carbon where you could "close" system structures and use new accessor functions). - A new API for the "native" stuff.

Source.

Quote:

As I said, I am not talking about a sandbox. I am talking about a virtual environment, basically the same thing like Mach running BSD4.3 and OSF/1 at the same time. And FWIW, I stated this intent in the first document I ever wrote on AmigaOS, somewhere in 1999/2000.

Source.

@Rob Quote:

Rob wrote: @cdimauro There wasn't a lack of thought. They knew the flaws of Amiga OS and the original plan always involved breaking compatibility at some point. Bolting AMP onto the existing OS seems to have been a later plan that differed to the original and probably came about due to lack of resources to restructure the OS entirely.

Quote:

Rogue wrote: FWIW, I am not saying that AmigaOS 4.0 is a dead end design. However, everybody with half a brain cell will agree that to evolve the current design, you need to do something about the way certain things are handled right now. Apple did the same thing. They invented the Classic environment for binary compatibility, Carbon for source code compatibility, and Cocoa for the new stuff. This is very similar to what we want to do: - A virtual environment to run classic OS 4 binaries in. - A compatibility library that will allow you to compile OS 4 source code to the new system, trying to stay as compatible as possible and to go with as little changes as possible, with possibilities to narrow down incompatibilities (like with Carbon where you could "close" system structures and use new accessor functions). - A new API for the "native" stuff. Source.

Quote:

Rogue wrote: As I said, I am not talking about a sandbox. I am talking about a virtual environment, basically the same thing like Mach running BSD4.3 and OSF/1 at the same time. And FWIW, I stated this intent in the first document I ever wrote on AmigaOS, somewhere in 1999/2000. Source.

OK Rob, but those were just the discussions which we saw from years and years.

In the meanwhile the OS4 development continued as usual, keeping everything as it is, and this without mentioning any virtual environment neither a sandbox to make the next step to a new o.s. (it would be a new o.s.. No doubt about it).

All Hyperion's announcements were about new features (most of them never done, of course), but no mention at all that those changes would have implied breaking of backward compatibility with 68K and/or PowerPC. Nothing at all about that.

The reason is very simple, and we all know that: you had to throw away A LOT of stuff, and rewrite it (both at the o.s. and applications level). And nobody had the resources to take on this very big challenge.

So, they continued to make announcements which basically gave false hopes to they fans. And continuing to cow-milking them.

Illusions. Just illusions.