@vox

there will not be any support by aeon/amigakit for Hyperion related products now and in future except something drastic changes in ownership of Hyperion. That is obvious if you read the comments in A600GS related threads.

vox Quote:

At least in my experience with x1000 and SAM460, its often Hyperion / OS4 not fully supporting and utilizing the board. Linux on both boards shows its full potential. AmigaOS 4 drivers are often half baked or unoptimized, if existing at all and basically OS remains "in beta" for almost any AmigaOne system out there. Compared to Trevor there is no other AmigaOne hardware choice, due to narrow mindness likely.

There were licensed Amiga1 computers from Eyetech and Acube Systems before the Hyperion and Amiga Inc. 2009 agreement that gifted Hyperion an exclusive license for the branding. Amiga Inc. was under financial duress after Pentti Kouri's death and likely coerced into signing the agreement which was likely financially backed by Trevor. A-Eon was given a sub license later after Ben@Hyperion was caught forging and embezzling bank funds from a joint business venture involving Trevor. Maybe there could have been a competitive Amiga1 clone market like the Mac clone market before Apple shut it down but Amiga Inc. was shady and the market tiny. After all the shenanigans and with no market to speak of, there isn't any value in Amiga1 branding with an obviously broken business model for over 2 decades, lawsuits due to the shenanigans, noncompetitive desktop AmigaOS 4 and software and a tarnished name for too many reasons to name. We don't know if the A1222 failed to receive Amiga1 branding because of the lawsuits or because of embarrassment to put Amiga1 branding on such crappy hardware. Is it "narrow mindedness" to believe that shenanigans and screwing over business partners would lead to business success in a long dead market? Yes.

vox Quote:

Other approach would be like MorphOS - using Apple PPC hardware OR bold one - taking OS to level it could use e.g. Talos board and IBM POWER series. But that would need serious investment in OS first, making it SMP and 64 bit at least.

AmigaOS4 could have gained momentum by using PPC Mac hardware and PS3 hardware but it is much too late. Porting PPC AmigaOS4 to POWER would be one of the easier port options but AmigaOS4 compatibility would likely be lost when adding SMP and 64 bit support. The POWER9 concept of slimming down POWER CPUs making them more modular, scalable and cheaper allowed POWER CPUs to be usable for the high end desktop. Too bad IBM did not try this before PPC died or it may have been more successful. IBM returned to big fat expensive CPUs with POWER10 and more of a focus on little endian support to better compete for high end servers. There is no future for POWER on the desktop or for the Amiga. Higher priced hardware than current Amiga1 hardware would reduce sales and fail to expand the user base. The Amiga needs a larger user base to attract developers and the logical place to enlarge the user base is the 68k Amiga retro and hobby markets where mass produced hardware may even be possible judging by THEA500 Mini sales.

vox Quote:

I don`t blame Trevor - Varisys so much (except for high end prices) - software side bothers me more. And Trevor tied to work that out with more focus on software recently. X5000 MorphOS support was nice step forward, but generally Trevor does not much support AROS or OS3 - except when its commercial viable. That said, still waiting for Enhancer for oS 3.2 :D

Software is expensive when the development cost is not spread out to enough people. Subsidizing and spreading the cost out over software add-ons and upgrades is lame too. The problem has not been addressed which is a much too small of user base.

vox Quote:

In general, as seen in other thread we do have some hardware choices, be it Classic accells, FPGA boards, MOS compatible systems. Its bigger oS advancement and productivity modern software we mostly lack on to be at least competitive and viable choice outside retro.

The Amiga has too much low production niche market hardware dividing even the niche Amiga market. More competitive hardware with appeal outside of the Amiga market is needed to substantially grow the user base and improve the software situation.

OlafS25 Quote:

there will not be any support by aeon/amigakit for Hyperion related products now and in future except something drastic changes in ownership of Hyperion. That is obvious if you read the comments in A600GS related threads.

A drastic change in Hyperion ownership seems likely. I don't believe Ben trying to deflect attention by blaming the Hyperion bankruptcy on e-cigarettes used by the accountant is going to work. The newly leaked Amiga documents likely came from Hyperion due to the bankruptcy investigation and show illegal activity. In other words, the authorities are likely on to Ben and he is much less likely to be able to weasel out of the Hyperion bankruptcy this time. It could take a long time for Hyperion to be officially declared bankrupt and the assets sold off though. Hyperion is one roadblock that is likely to disappear and A-Eon potentially another as the foundation of the 2009 Hyperion and Amiga Inc. agreement is shaken. The legal dispute could be over with Amiga Corporation able to move forward with at least AmigaOS 3.1 to do whatever they want even before Hyperion assets are sold off.

@matthey

Quote:

matthey wrote: The POWER9 concept of slimming down POWER CPUs making them more modular, scalable and cheaper allowed POWER CPUs to be usable for the high end desktop. Too bad IBM did not try this before PPC died or it may have been more successful. IBM returned to big fat expensive CPUs with POWER10 and more of a focus on little endian support to better compete for high end servers.

You do know that they tried just that with the 970 aka G5 (based on POWER4) series?

And no nothing the could have done with POWER5/6/7/8/9 or 10 would have been any better today then the G5 was 20 years ago.

Actually the gap to the current x86 or ARM chips would be even bigger today.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Hammer Quote:

3DFX Voodoo 1 was released in 1996. Each of Voodoo 1's SST1 has 1 million transistors and is divided into two ASIC chips i.e. FBI and TMU. Clocked at 50 Mhz. Amiga Hombre's completion assumes the original Commodore International is still alive. If Commodore licenses 3DFX GPU IP, what is Commodore's value-added proposition when Commodore does not have a strong 1st party game studio? Just a middleman? "AmigaOS" by itself is not enough. Commodore's Amiga Vision is not strong enough to change the demand factor for the AmigaOS platform. Sony and Nintendo could survive licensing 3rd party GPU IP since they both have very strong 1st party game studios.

Sony was a newcomer to the console hardware and software business when they released the PS1 in 1994.

Quote:

Incensed by Nintendo's renouncement, Ohga and Kutaragi decided that Sony would develop their own console. Nintendo's contract-breaking was met with consternation in the Japanese business community, as they had broken an "unwritten law" of native companies not turning against each other in favour of foreign ones. Sony's American branch considered allying with Sega to produce a CD-ROM-based machine called the Sega Multimedia Entertainment System, but their board of directors in Tokyo vetoed the idea when American CEO Tom Kalinske presented them the proposal. Kalinske recalled them saying: "That's a stupid idea, Sony doesn't know how to make hardware. They don't know how to make software either. Why would we want to do this?" Sony halted their research, but decided to develop what it had developed with Nintendo and Sega into a console based on the SNES.

CBM was the more experienced player in the gaming market and could leverage a large game library of 2D Amiga and CD32 games until their 3D game market matured. The Amiga 2D chipset was small at ~200,000 transistors for AA+ and some of this would be required with 3D underneath. The PS1 had a mediocre launch and was slow to catch on because of lack of 3D software. By the end of 1994, 300,000 PS1 units were sold in Japan compared to 500,000 Sega Saturn units. Eventually, 3D game popularity surpassed 2D game popularity putting the Saturn at a disadvantage because they had too much 2D hardware and not enough 3D hardware. The same was true of 3DO hardware. Both the Saturn and 3DO mostly 2D chipsets were likely several times larger than the simple Amiga ~200,000 transistor chipset which was created when every transistor counted. The Saturn hardware used more processors and chips which were more difficult to integrate, especially where they were provided by 3rd parties. The Saturn had 2xSH-2, SH-1, 68EC000 (sound processor), Yamaha FH1 DSP and a Hitachi 4-bit MCU. The 3DO hardware was easier to integrate as primarily the ARM60 was used besides custom chipset which included a DSP inside the custom CLIO chip. Most of the 3DO chipset was integrated inside a single large "Anvil" chip but it was still mostly 2D and 2.5D hardware. The PS1 had a single CPU, 3D chipset and CD-ROM drive they produced themselves. The PS1 was $300 USD while the Saturn and 3DO were stuck at $400 USD lacking the ability to be cost reduced further. The CD32 could definitely go lower in price but could they do it with 3D added to the chipset and more CPU performance?

Hombre was low transistor count and should have provided somewhat similar performance to the PS1. The custom PA-RISC CPU was licensed and could be integrated into the chipset while it provided additional processing power. I believe it would have been wise to keep the 68k and Amiga chipset for compatibility as they were cheap to include, especially if the 68k could be licensed for integration. It's possible such CD32 successor could have been competitive if CBM was better at integrating and using newer more competitive chip processes. Even missing the narrow window of opportunity to use Hombre, the 3dfx chipset could have potentially offered another window of opportunity. The Hombre and PS1 chipsets were low quality integer only with disadvantages like distorted perspective when close to walls and wiggly object edges and lines that were fixed by using floating point for 3D. The Voodoo chipset used higher quality floating point 3D but required more expensive CPUs with FPUs in addition to the larger 3D chipset. This is why it was not considered until later. CBM would have had to pivot to 68k CPUs with FPUs and they were poor at adapting to new technology. Motorola was more than capable of producing higher performance FPUs than the 68040 and 68060 FPUs but there wasn't enough of a 3D gaming market on the 68k from just 68040 Macs even with the 1994 Marathon game release.

Hammer Quote:

Microsoft could survive on 3rd party PC clones when Microsoft has strong 1st party MS Office developer teams that feeds MS Windows's demand factor. Learn from IBM's OS/2 losing to Windows 3.0. It started from Windows 2.0 and Mac ports of Excel 2.1 in 1988 and Word 2.0 in 1989. "OS/2" by itself is nothing to many people. For me and many others, IBM OS/2 doesn't have native ports of Doom, enough said. Windows 95 has /DirectX/Doom 95 and WinQuake in Jan 1997. Apple has Claris (ClarisWorks 1.0 in 1991, AppleWorks 5.0 in 1997), Final Cut Pro (acquired Final Cut Pro development team in 1998), and Logic Pro (acquired Emagic in July 2002). Microsoft is rumored to be preparing a $16 billion offer to buy Valve Steam.

Microsoft is being allowed to own PC gaming. What happened to the U.S. Justice department? Oh yea, they are the injustice department now, Bill Gates is a lib and they only go after non-libs like Elon Musk.

Hammer Quote:

68060 dropped some 68K instructions and the trap emulates the missing instructions with slow performance.

Traps can be avoided with 68060 compiler support like VBCC uses. Quake required Pentium specific compiler support and code or it would have been dirt slow too. There is no way to make existing x86 FPU code fast due to the stack based ISA and very dependent code that it encourages. A newer 68k FPU with FPU instructions added back, pipelining and FPU register renaming could execute even 6888x code with good performance as some parallelism is possible with GP FPU registers.

Hammer Quote:

68060 is not a 100 percent 68000's instruction set. Motorola's record for backward compatibility is inferior to AMD's or Intel's.

Hyperion AmigaOS 3.x uses 16 bit 68000 compiled code on a 68060 so it can't be too bad. It is possible to execute 808x and early x86 code on x86(-64) CPUs if all the modes, segment registers and memory extensions are setup correctly but it is a daunting task that practically requires a sandbox.

Hammer Quote:

K8 still has a microcode path that is handled by a microcode engine which is a small processor on its own i.e. using a tiny embedded CPU to translate X86 instructions for the main CPU core. Microcode is also used for applying firmware patches with any CPU bugs post-sale instead of executing a product recall or telling software vendors to change their close source legacy software post-sale. For Amiga's 68060, the MMULibs software checks the revision of the chip when the computer boots and disables some problematic features. MMULibs is on the OS side instead of being transparent from the OS.

Microcode certainly has advantages but it isn't always updateable and CPU firmware updates are a possible vector for being hacked. Anybody can configure a 68060 as desired despite the 68060 not being supported anymore while firmware updates require active support. Part of the reason why there are firmware updates with these huge OoO CPUs is because they are complex with more vulnerabilities. Shall we take a look at Spectre vulnerabilities alone?

https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#History Quote:

In 2002 and 2003, Yukiyasu Tsunoo and colleagues from NEC showed how to attack MISTY and DES symmetric key ciphers, respectively. In 2005, Daniel Bernstein from the University of Illinois, Chicago reported an extraction of an OpenSSL AES key via a cache timing attack, and Colin Percival had a working attack on the OpenSSL RSA key using the Intel processor's cache. In 2013 Yuval Yarom and Katrina Falkner from the University of Adelaide showed how measuring the access time to data lets a nefarious application determine if the information was read from the cache or not. If it was read from the cache the access time would be very short, meaning the data read could contain the private key of encryption algorithms. This technique was used to successfully attack GnuPG, AES and other cryptographic implementations. In January 2017, Anders Fogh gave a presentation at the Ruhr University Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core. Spectre proper was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp, and Yuval Yarom. It was made public in conjunction with another vulnerability, Meltdown, on 3 January 2018, after the affected hardware vendors had already been made aware of the issue on 1 June 2017. The vulnerability was called Spectre because it was "based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time." On 28 January 2018, it was reported that Intel shared news of the Meltdown and Spectre security vulnerabilities with Chinese technology companies, before notifying the U.S. government of the flaws. On 29 January 2018, Microsoft was reported to have released a Windows update that disabled the problematic Intel Microcode fix—which had, in some cases, caused reboots, system instability, and data loss or corruption—issued earlier by Intel for the Spectre Variant 2 attack. Woody Leonhard of ComputerWorld expressed a concern about installing the new Microsoft patch. Since the disclosure of Spectre and Meltdown in January 2018, much research had been done on vulnerabilities related to speculative execution. On 3 May 2018, eight additional Spectre-class flaws provisionally named Spectre-NG by c't (a German computer magazine) were reported affecting Intel and possibly AMD and ARM processors. Intel reported that they were preparing new patches to mitigate these flaws. Affected are all Core i Series processors and Xeon derivates since Nehalem (2010) and Atom-based processors since 2013. Intel postponed their release of microcode updates to 10 July 2018. On 21 May 2018, Intel published information on the first two Spectre-NG class side-channel vulnerabilities CVE-2018-3640 (Rogue System Register Read, Variant 3a) and CVE-2018-3639 (Speculative Store Bypass, Variant 4), also referred to as Intel SA-00115 and HP PSR-2018-0074, respectively. According to Amazon Germany, Cyberus Technology, SYSGO, and Colin Percival (FreeBSD), Intel revealed details on the third Spectre-NG variant CVE-2018-3665 (Lazy FP State Restore, Intel SA-00145) on 13 June 2018. It is also known as Lazy FPU state leak (abbreviated "LazyFP") and "Spectre-NG 3". On 10 July 2018, Intel revealed details on another Spectre-NG class vulnerability called "Bounds Check Bypass Store" (BCBS), or "Spectre 1.1" (CVE-2018-3693), which was able to write as well as read out of bounds. Another variant named "Spectre 1.2" was mentioned as well. In late July 2018, researchers at the universities of Saarland and California revealed ret2spec (aka "Spectre v5") and SpectreRSB, new types of code execution vulnerabilities using the return stack buffer (RSB). At the end of July 2018, researchers at the Graz University of Technology revealed "NetSpectre", a new type of remote attack similar to Spectre V1, but which does not need attacker-controlled code to be run on the target device at all. On 8 October 2018, Intel was reported to have added hardware and firmware mitigations regarding Spectre and Meltdown vulnerabilities to its latest processors. In November 2018, five new variants of the attacks were revealed. Researchers attempted to compromise CPU protection mechanisms using code to exploit the CPU pattern history table, branch target buffer, return stack buffer, and branch history table. In August 2019, a related transient execution CPU vulnerability, Spectre SWAPGS (CVE-2019-1125), was reported. In July 2020 a team of researchers from TU Kaiserslautern, Germany published a new Spectre variant called "Spectre-STC" (single-threaded contention). This variant makes use of port contention in shared resources and can be applied even in single-threaded cores. In late April 2021, a related vulnerability was discovered that breaks through the security systems designed to mitigate Spectre through use of the micro-op cache. The vulnerability is known to affect Skylake and later processors from Intel and Zen-based processors from AMD. In February 2023, a team of researchers at North Carolina State University uncovered a new code execution vulnerability called Spectre-HD, also known as "Spectre SRV" or "Spectre v6". This vulnerability leverages speculative vectorization with selective replay (SRV) technique showing "Leakage from Higher Dimensional Speculation".

Now lets see which CPUs are "immune".

https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Immune_hardware Quote:

This list is incomplete; you can help by adding missing items. (January 2024) ARM: A55 A53 A32 A7 A5 x86: Intel Atom N270 / N280 i486 and older

All these immune CPUs are in-order like the 68060.

Hammer Quote:

K8's Fast Single and Fast Double decoders are the hardware decoders for most X86 instructions and they are geared for gaming the benchmarks and C++ compiler's cooperation. There's a reason for MS's and Intel's investments in the C++ compiler. Are you aware of the gap between CPU and external memory performance? Examples Athlon +1 Ghz against DDR-400 (400MT/s, 200Mhz, 64 bit). Athlon 600 Mhz against DDR-200 (200MT/s,100Mhz, 64 bit). Faster memory types have a larger latency even with SDRAM types e.g. DDR4 vs DDR5. The out-of-order hardware will be significantly large in the attempts to hide or migrate the gap between the CPU core and external memory.

I am aware that general purpose CPU cores can only function at full performance with all code and data in limited caches and that it is impossible even for OoO cores. In-order cores are limited to about half the performance of OoO cores but this is likely 3-4 DMIPS/MHz even though in-order RISC CPUs struggle to get there. The in-order CPU cores offer advantages like smaller and cheaper cores, lower power and heat, easier and cheaper to develop and fewer security vulnerabilities. Multiple cores are also possible. The saved transistor and power budget can go toward a better GPU. This is desirable for a small SBC using a SoC with integrated GPU as the GPU can provide more performance than the CPU in the same way that the old consoles were better off using the chipset for performance instead of the CPU.

Small footprint hardware has a cache advantage as a larger percentage of memory can be kept in caches. The 68k Amiga is very good at code sharing and there is room for improvement. A small enough footprint allows to do away with the SRAM caches and use SRAM memory but MCU small footprints limit general purpose use. The 68020+AGA+2MiB Amiga standard is a smaller footprint than some MCUs today though.

Kronos Quote:

You do know that they tried just that with the 970 aka G5 (based on POWER4) series? And no nothing the could have done with POWER5/6/7/8/9 or 10 would have been any better today then the G5 was 20 years ago. Actually the gap to the current x86 or ARM chips would be even bigger today.

I am aware of where IBM's G5 CPU came from. I believe the G5 design is closer to a desktop design than the impractical for desktop use POWER design at that time. I don't believe the POWER9 design was slimmed down as far as the G5 design but both ideas are similar and face similar difficulties.

Last edited by matthey on 25-May-2024 at 10:48 PM.

@OlafS25

There's an A-EON driven split for PowerPC "System V54" and 68K "System V46" (based on A-EON System V54 with AROS filling the missing parts). It's effectively A-EON-OS.


Hyperion has its own 68K AmigaOS 3.2.x/3.3.x and PowerPC AmigaOS 4.1 FE paths.

Last edited by Hammer on 26-May-2024 at 04:36 AM.

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

@matthey

Spectre is not a problem for single hosted systems. It's a problem for shared systems.

https://forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128
Quote:

Old sand Anything StrongARM SuperSPARC Transmeta Crusoe 67 - Archtitecture 1, Architecture 2 Transmeta Efficeon 47 Old X86 All old 8/16bit x86 and clones WinChip 97 VIA C3 91 386 and clones 486 and clones Pentium 1 (Non Pro) and clones based on the P5 architecture. UltraSPARC III and III CU PPC 750 (G3) PPC 7400 (Variants of G4) New Sand ARM Cortex-A5 AMD PSP ARM Cortex-A7 MPCore (RasPi 2) ARM Cortex-A53 MPCore - - - in-order dual issue, with a branch predictor, according to ARM is not affected Includes Raspberry Pi 3 and many Android Phones. Example: Snapdragon 625 etc. [Early Intel Atoms including S/D/N Series] ((https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Bonnell_microarchitecture 265) Diamondville Pineview Cedar View VIA C7 - but does have a basic branch prediction scheme Intel Itanium 493 aka IA64 260 (This architecture is amazing and bizarre altogether) RISC-V, RISC-V Rocket Stuff that’s got interesting features to disrupt/disable Spectre AMD Zen with SME/SEV (Secure Memory Encryption/Secure Encrypted Virtualization) This would garble any retrieved memory in Virtualization scenarios.

Spectre exploits memory areas not being cleaned after use.

Last edited by Hammer on 26-May-2024 at 10:14 AM.
Last edited by Hammer on 26-May-2024 at 10:11 AM.

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

@matthey

Quote:

Sony was a newcomer to the console hardware and software business when they released the PS1 in 1994.

False. Ken Kutaragi was a designer for SNES's sound DSP.

For PS1's 3rd developer relations, Sony was active in 1993. Sony purchased Psygnosis in 1993.

https://en.wikipedia.org/wiki/List_of_acquisitions_by_Sony
Acquisitions by Sony for game consoles

19 September 1989, Materials Research
22 February 1990, AMD chip plant
21 May 1993, Psygnosis

Sony learns a hard lesson from Beta vs VHS wars. Content is king.

Last edited by Hammer on 26-May-2024 at 10:02 AM.

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

Hammer Quote:

Spectre is not a problem for single hosted systems. It's a problem for shared systems.

Closed systems using only known software don't need to worry about Spectre. Is that the hardware limitation we want?

Hammer Quote:

Spectre exploits memory areas not being cleaned after use.

The problem is not memory not be cleaned but caches not being cleaned after speculative execution. Most in-order CPUs execute code speculatively and could have a problem but they usually perform much less speculative execution. OoO execution usually has more state data to record and restore in addition to more data from speculative execution. The solution is simple which is to use all separate caches for speculatively executed code and data but this reduces the usable system caches and performance. Reducing OoO performance makes in-order cores more competitive.

Hammer Quote:

False. Ken Kutaragi was a designer for SNES's sound DSP. For PS1's 3rd developer relations, Sony was active in 1993. Sony purchased Psygnosis in 1993. https://en.wikipedia.org/wiki/List_of_acquisitions_by_Sony Acquisitions by Sony for game consoles 19 September 1989, Materials Research 22 February 1990, AMD chip plant 21 May 1993, Psygnosis Sony learns a hard lesson from Beta vs VHS wars. Content is king.

Sony manufactured many of the hardware pieces that could be used by a console. They were more into audio/video and knew how to create audio CDs which was useful for a CD based console. They had experience with similar hardware but they were new to consoles and lacked software experience. The software house acquisitions like Psygnosis didn't come until later after a start that was less than clear they would succeed.