@Rose

Quote:

They need to call their VHDL core something

Unless it uses extremely small amounts of power that wouldn't make sense. Oh, haha, the power is embedded. I'd get it if they called it Powerwatt.

Quote:

Doable, it's just that price of FPGA needed will make it pointless considering that you can get 1.4Ghz T1020 for ~$80 which would beat it anyway.

I wonder if it's easier to simulate than a 68K given all instructions are one size. But wait, what, PPC for $80?!

1.4Ghz is fairly decent. What's the catch? Not one of those SPE things is it?

@Hypex

Quote:

But wait, what, PPC for $80?!

That's actually for T1040 which is 4 core part and price is for single cpu. Drops closer to 70 if you buy 100.

Quote:

1.4Ghz is fairly decent. What's the catch? Not one of those SPE things is it?

Most likely would make too much sense to use one. Haves same e5500 cores than P50x0.

If you would want to do it really cheap. T1023@1.25Ghz with 2 e5500 cores is ~$35.

@Rose

Quote:

That's actually for T1040 which is 4 core part and price is for single cpu. Drops closer to 70 if you buy 100.

Bargain for Trevor.

Quote:

Most likely would make too much sense to use one. Haves same e5500 cores than P50x0.

That's even better. A fully supported CPU core already in production.

Quote:

If you would want to do it really cheap. T1023@1.25Ghz with 2 e5500 cores is ~$35.

If only this was available at the same price for the Tabor five years ago instead of the complicated time waster they picked.

@Hypex

Quote:

If only this was available at the same price for the Tabor five years ago instead of the complicated time waster they picked.

I have to ask, was the lack of conventional FPU or even the CPU in general REALLY the biggest problem for the Tabor release?

IMHO the small form factor and limited PCIe slots requiring drivers 'out of the box' for the onboard sound chip and ethernet seem far more of a problem pushing the launch back to the point of obsolescence on some of the components! AmigaOS developers are simply not equipped to write drivers in a timely manner to avoid stalling the launch of hardware. It's better to support currently supported chips / expansion boards and make sure ALL future AmigaOne boards have enough PCIe slots so that we can just slot in the sound and ethernet cards already supported. Doing anything else seems.... and is the real time waster!

Heck, Hyperion don't even seem to want to continue working on the AmigaOS 4.x fork and are on the face of it making more money out of AmigaOS 3.1.4. Only Enhancer keeps the wheels on because we have A-EON software developers that are handy with graphics boards! Thank goodness we have Thomas Richter etc because otherwise we'd still all be reliant on the Radeon 9200 for AmigaNG!

Last edited by BigD on 01-Jun-2020 at 07:15 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

I guess its not a lot of fun working on AmigaOS when all you get it shit from the community and costly legal problem with Cloanto.

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

@NutsAboutAmiga

When was it ever about fun for Hyperion since they dropped the ball with the Worms Armageddon license? Their software operation has become more and more like a shell company to service debts and legitimise the legal IP battles where the main interest and energy is expended!

If I'm wrong what happened in reference to the planned Q&A with Stephen Jones? Running scared or just not even trying to win hearts and minds like Cloanto? Either way AmigaOS 4.x is languishing and it's not A-EON's fault.

Last edited by BigD on 01-Jun-2020 at 10:46 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

Quote:

Hypex wrote: I wonder if it's easier to simulate than a 68K given all instructions are one size.

A simple PowerPC CPU likely uses less logic than a simple 68k CPU but they wouldn't be general purpose (fast but limited SRAM, flash or EEPROM instead of large caches), would not run an Amiga like OS without changes (lacks features of old PPC standard) and would have poor performance in comparison to more advanced PPC CPUs. Freescale/NXP had the e200 line of simple embedded PPC cores.

https://en.wikipedia.org/wiki/PowerPC_e200

Notice that all of the e200 cores support VLE (Variable Length Encoding) which Freescale/NXP claims to reduce code size by up to 30% without increasing the number of instructions by more than 10% (no mention of memory traffic increases with reduction to 16 GP registers and it doesn't look like VLE made it into the official GCC). There are only 2 encoding lengths so VLE is simpler to decode than the 68k but it does show that variable length encodings are not a problem for even simple low end processors. Some low end ARM processors support Thumb 2 only which also has 2 encoding sizes. The 68k has more complex decoding due to more encoding sizes but often superior code density, fewer instructions to execute and less memory traffic in comparison to compressed encodings like VLE or Thumb 2.

The PowerPC e300 line of cores are more general purpose and more compatible with traditional PPC standards but were based on the notoriously poor performance PPC 603(e). The PPC Efika used an e300 core in a MPC5200B CPU clocked around 400MHz. This core would likely fit in an affordable FPGA of similar size to what the Vampire's Apollo Core uses but running at a fraction of the frequency of a hard chip. The 68060 outperformed the PPC603 at the same frequency and the Apollo Core has similar performance. The e300 cores did not support VLE so not only would the performance likely be inferior but the e300 core would require substantially more caches and memory. One of the major complaints of Efika users was lack of memory with half that of the first Raspberry Pi with 128MiB and adding more would have increased costs hurting its chances in the embedded market. The planned Efika upgrade to the MPC5121e (same e300 core) SoC with PowerVR integrated GPU would have reduced the physical size and cost while enhancing features but the Efika MX switched to an ARM SoC with Cortex-A8 using Thumb 2.

Quote:

Hypex wrote: Bargain for Trevor.

Maybe Trevor has had his fill of bargains after the Tabor CPU purchase.

Quote:

That's even better. A fully supported CPU core already in production.

Do you mean already out of production PPC QorIQ chips? The place I looked only had the newer ARM based QorIQ chips available and in stock. It looks like they offer more in performance and features than the old PPC. Even though the QorIQ ARM Cortex-A72 is more powerful and similarly priced, is it that good of a deal when a Raspberry Pi 4 comes with the same core, GPU, 2GiB of memory, etc for less?

Quote:

If only this was available at the same price for the Tabor five years ago instead of the complicated time waster they picked.

You don't control your own destiny when only buying 1000 CPUs every few years and you don't get much of a discount.

Last edited by matthey on 02-Jun-2020 at 07:12 PM.

@matthey

Quote:

. One of the major complaints of Efika users was lack of memory even though it had the same as the first Raspberry Pi with 256MiB

Efika only has 128MB, which was more of on issue with MorphOS as you couldn't just use swap (as Linux does on the Pi). Running Linux on the Efika was doable but it was still only a 400MHz CPU.

Quote:

The planned Efika upgrade to the MPC5121e (same e300 core)

Not really the same core as this one would have lacked cache coherency and had some other issues as well requiring massive workarounds for existing PPC-OS to run on it. Not as bad as the one used on the Tabor but bad enough to make it a total non option.

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

@BigD

Quote:

I have to ask, was the lack of conventional FPU or even the CPU in general REALLY the biggest problem for the Tabor release?

Actually, yes it is. Freescale have continued the Motorola tradition of removing features or replacing them and breaking compatibility. But in this case, it's much worse.

The P1022 PPC in the Tabor lacks a standrd FPU. But instead features an SPE, Signal Processing Engine. Now, for it's intended use, the vendor can just compile their code so that's no problem.

But OS4 code and indeed, all PPC code since it was first introduced to the Amiga, expects a standard FPU and instructions to be present. Unlike 68K where FPU was optional and only few programs used it, on PPC it was included as standard, and more programs would use floats.

The SPE is used for FPU operatons can also do SIMD. So it's almost like a hybrid of FPU and AltiVec. But, the SPE instructions sit in the AltiVec space, yet the codes do different things. Almost like a ColdFire 68K uses different codes. Another thing is that the SPE registers use the standard registers for their work. This presents a few issues, so run time patching has to be done, to divert codes using FPU to patch routines that simulate the operation. Sitting in the AltiVec space is the least of the issues. All this took a lot of work and the result will always be slower than native SPE code.

Quote:

IMHO the small form factor and limited PCIe slots requiring drivers 'out of the box' for the onboard sound chip and ethernet seem far more of a problem pushing the launch back to the point of obsolescence on some of the components! AmigaOS developers are simply not equipped to write drivers in a timely manner to avoid stalling the launch of hardware.

It's supposed to be small. The CPU is also a SoC so internal things like USB and Ethernet woould need support. Drivers take time. Even with Linux sources as a reference it still needs to function correctly on OS4. Plus most would be working on it in their spare time.

Quote:

Only Enhancer keeps the wheels on because we have A-EON software developers that are handy with graphics boards! Thank goodness we have Thomas Richter etc because otherwise we'd still all be reliant on the Radeon 9200 for AmigaNG!

And Hans de Ruiter.

It's good with A-EON backing development but it does split up OS drivers to a third party.

@Hypex

Quote:

It's supposed to be small. The CPU is also a SoC so internal things like USB and Ethernet woould need support. Drivers take time.

Thing that has puzzled me is that motherboard is said to be designed for Amiga use, why not put ~$1.5 RTL8111 on motherboard which was already supported.

@matthey

Quote:

The planned Efika upgrade to the MPC5121e (same e300 core) SoC with PowerVR integrated GPU would have reduced the physical size and cost while enhancing features

The "Efika" was merely a development path towards what later became known as "LimePC" (and other planned products in the same family beyond the laptop/netbook, like an Efika-alike thin client, a TV, a handheld, a possible key-chain computer, etc), which was always the goal. The Efika "5k2" was merely a stepping stone. A misstep as it turned out.

Quote:

but the Efika MX switched to an ARM SoC with Cortex-A8

Indeed, both in the shape of the "smart top" and the netbook.



They were cool designs.

I have them both!

@Hypex

Quote:

The P1022 PPC in the Tabor lacks a standrd FPU. But instead features an SPE, Signal Processing Engine. Now, for it's intended use, the vendor can just compile their code so that's no problem.

"No problem"?

The MPC5121e surprised (read: shocked!) by not being cache-coherent. This (and indeed other things) made Genesi pull the plug on their PPC based Efika path. Painful in many ways, but they did it. The P1022 is way worse. It introduces an incompatible CPU into the eco-system, with instruction overlaps, etc. In a way like putting a ColdFire CPU in a 68k Amiga, thinking "the vendor can just compile their code so that's no problem". I believe all Linux distros has dropped support of the P1022 by now, as well as all major compilers? And still, after half a decade not being able to put a product to market, "AeonKit" has not abandoned the thought! Which is astonishing! But I suppose it goes completely in line with everything they have done so far, creating massively overpriced, under-specced and generally unwanted HW that is essentially nothing but lock-in dongles for OS4, honey-traps for the gullibles. Destroying any hope of a future for the platform in the process. No disaster ever in OS4's way too long history has helped killing off the OS4 platform more than "AeonKit" has. "Tabor" - any year now. Let's not go x86 or ARM, only Tabor is teh reel!!1!


@Rose

Quote:

Rose wrote: @Hypex Quote: It's supposed to be small. The CPU is also a SoC so internal things like USB and Ethernet woould need support. Drivers take time. Thing that has puzzled me is that motherboard is said to be designed for Amiga use, why not put ~$1.5 RTL8111 on motherboard which was already supported.

That would indeed have made sense (which I guess is what is disqualifying the idea). Putting a discrete controller on the board is NOTHING compared to the huge effort in man-hours of developing new drivers. Especially considering the volumes of, what, 50 boards? A hundred? Two?

@Rose

Quote:

Rose wrote: @Hypex Quote: It's supposed to be small. The CPU is also a SoC so internal things like USB and Ethernet woould need support. Drivers take time. Thing that has puzzled me is that motherboard is said to be designed for Amiga use, why not put ~$1.5 RTL8111 on motherboard which was already supported.

Lack of (free) PCIe lanes....

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

@matthey

Quote:

A simple PowerPC CPU likely uses less logic than a simple 68k CPU but they wouldn't be general purpose (fast but limited SRAM, flash or EEPROM instead of large caches), would not run an Amiga like OS without changes (lacks features of old PPC standard) and would have poor performance in comparison to more advanced PPC CPUs. Freescale/NXP had the e200 line of simple embedded PPC cores.

We won't see an FPGA PPC soon then which could match the speed of a CyberStorm PPC even it looks.

Quote:

Notice that all of the e200 cores support VLE (Variable Length Encoding) which Freescale/NXP claims to reduce code size by up to 30% without increasing the number of instructions by more than 10% (no mention of memory traffic increases with reduction to 16 GP registers and it doesn't look like VLE made it into the official GCC).

I see that. Does whole core drop to 16 GPR? Or only for VLE?

I tend to think VLE isn't suitable for PPC. It breaks structure as all PPC used 32-bit codes. As a comparison, the Vampire is including a new 32-bit copper write, but this breaks structure because there will be 48-bit sized instructions. The copper is like PPC, it uses a set 32-bit code standard, anything else doesn't exactly belong. I think the Vampire guys should use 64 bits exactly otherwise the codes are out of alignment. The copper isn't a 68K, it's a very RISC co-processor. But I digress.

Quote:

The PowerPC e300 line of cores are more general purpose and more compatible with traditional PPC standards but were based on the notoriously poor performance PPC 603(e). The PPC Efika used an e300 core in a MPC5200B CPU clocked around 400MHz. This core would likely fit in an affordable FPGA of similar size to what the Vampire's Apollo Core uses but running at a fraction of the frequency of a hard chip

The 603. Now that's going way back. Even at 400Mhz.

Quote:

The 68060 outperformed the PPC603 at the same frequency and the Apollo Core has similar performance. The e300 cores did not support VLE so not only would the performance likely be inferior but the e300 core would require substantially more caches and memory. One of the major complaints of Efika users was lack of memory with half that of the first Raspberry Pi with 128MiB and adding more would have increased costs hurting its chances in the embedded market. The planned Efika upgrade to the MPC5121e (same e300 core) SoC with PowerVR integrated GPU would have reduced the physical size and cost while enhancing features but the Efika MX switched to an ARM SoC with Cortex-A8 using Thumb 2.

So early models like 75Mhz PPC? Up to 100 almost? Doesn't loop good if the new RISC was being beat by the old CISC.

I didn't quite understand the Efika. It was slower and had less resources. If my timing is right wasn't the Efika released after the Pegasos? I suppose since it was PPC I expected it to run MOS. Otherwise why chose PPC? The move to ARM shows it didn't need PPC by the looks of it.

Quote:

Maybe Trevor has had his fill of bargains after the Tabor CPU purchase.

Quote:

Do you mean already out of production PPC QorIQ chips? The place I looked only had the newer ARM based QorIQ chips available and in stock. It looks like they offer more in performance and features than the old PPC.

Yes, but I just going by what Rose said. If it's sitting on a shelf it's useful for us.

Quote:

Even though the QorIQ ARM Cortex-A72 is more powerful and similarly priced, is it that good of a deal when a Raspberry Pi 4 comes with the same core, GPU, 2GiB of memory, etc for less?

It doesn't but how much more power has the QorIQ? A MiniITX RPi would be better for our market.

Quote:

You don't control your own destiny when only buying 1000 CPUs every few years and you don't get much of a discount.

That's too many. For that amount with little discount you really need to invest time studying the technical specifications. The P1022 uses an e500v2 or similar core which now is almost ten years old. It was replaced by the e500mc where they scrapped this SPE idea and brought back the standard FPU. Unfortunately the timing wasn't right. Maybe it was more expensive but it would have been better waiting for some e500mc CPUs to turn up, which aparently was out in 2008. That was old in 2015 so I don't know how they missed it and ended up with an even older CPU.

@TRIPOS

Quote:

"No problem"? The MPC5121e surprised (read: shocked!) by not being cache-coherent. This (and indeed other things) made Genesi pull the plug on their PPC based Efika path. Painful in many ways, but they did it. The P1022 is way worse. It introduces an incompatible CPU into the eco-system, with instruction overlaps, etc. In a way like putting a ColdFire CPU in a 68k Amiga, thinking "the vendor can just compile their code so that's no problem". I believe all Linux distros has dropped support of the P1022 by now, as well as all major compilers? And still, after half a decade not being able to put a product to market, "AeonKit" has not abandoned the thought! Which is astonishing! But I suppose it goes completely in line with everything they have done so far, creating massively overpriced, under-specced and generally unwanted HW that is essentially nothing but lock-in dongles for OS4, honey-traps for the gullibles. Destroying any hope of a future for the platform in the process. No disaster ever in OS4's way too long history has helped killing off the OS4 platform more than "AeonKit" has. "Tabor" - any year now. Let's not go x86 or ARM, only Tabor is teh reel!!1!

What I find even more astonishing is that there are people who are willing to gladly pay 4 figures for said systems that offer no more features and performance than was found on run-of-the-mill PC's back in 2002. Bunch of window lickers.....

Quote:

Hypex wrote: We won't see an FPGA PPC soon then which could match the speed of a CyberStorm PPC even it looks.

It looks like the lowest clocked CyberStorm PPC was 604e@150MHz. A simple PPC design with a deep pipeline in an affordable FPGA could probably reach this clock speed but it would be weak and likely not close to the strong performance of the 604e. A deeper pipeline allows for higher clock speeds but uses more transistors. Then you need better branch prediction and more caches which cost more transistors. OoO execution avoids some bubbles and allows more parallel operations but requires more transistors.

68060 2.5 million transistors (8 stage in order, 8kiB ICache 8kiB DCache)
Pentium P54C 3.3 million transistors (5 stage in order, 8kiB ICache 8kiB DCache)
Pentium Pro 7.5 million transistors (12 stage OoO, 8kiB ICache 8kiB DCache)

603 1.6 million transistors (4 stage OoO, 8kiB ICache 8kiB DCache)
603e 2.6 million transistors (4 stage OoO, 16kiB ICache,16kiB DCache)
604 3.6 million transistors (6 stage OoO, 16kiB ICache 16kiB DCache)
604e 5.1 million transistors (6 stage OoO, 32kiB ICache 32kiB DCache)

An FPGA core in an affordable FPGA probably could have competitive performance with the Blizzard PPC 603e@160MHz. The Apollo Core in the Vampire is probably competitive now.

PPC designs had trouble being clocked up because of their shallow pipelines despite the PPC 604 initially outperforming the Pentium. Intel quickly moved to a deeper pipeline for higher clock speeds. Ironically, the 68060 was initially best positioned for higher clock speeds with the fewest design changes. It was competitive with the Pentium and 603(e) at the same clock speed while using less resources (68060 is the only CPU above with only a 32 bit data bus as well).

How was the 68060 competitive with the PPC 603(e)? Integer instructions (like ADD) are the most common instructions in code and the 603(e) only has 1 integer unit. Doh! The load/store unit does EA (Effective Address) calculations but the PPC has only simple addressing modes so it can sometimes do another add on a load or store. The 68060 has 2 integer units with an EA calculation using more complex but powerful addressing modes before the ALU calculation on each. The following code can execute in one cycle on the 68060.

add.l (8,a0,d0.l*4),d1 ; 3 adds, 1 shift in EA and 1 add in ALU
lea (4,a1,d2.l*4),a2 ; 3 adds and 1 shift in EA

The 603(e) can only do 2 adds in one cycle in comparison.

ldz r0,8(r11) ; 1 add in load/store unit EA
addi r2,r3,r4 ; 1 add in integer unit ALU

The 603(e) does some simple OoO to reduce bubbles where possible but the 68060 design minimizes bubbles with early execution of simple integer instructions in the EA calc stage (both support register renaming and result forwarding to minimize bubbles). Some of the difference is code density. There are fewer instructions to execute on the 68060 (68k code uses 10%-20% fewer instructions?) and it can often execute more. The 68060 with 8kiB ICache is like 16kiB ICache on the PPC because of the code density difference. The PPC 604e received the 2nd integer pipe, has more aggressive OoO, has better branch prediction (similar to 68060) and larger caches. The 68060 will still outperform it cycle for cycle sometimes and it is more resource and energy efficient.

Quote:

I see that. Does whole core drop to 16 GPR? Or only for VLE?

The PPC e200z0 only supports VLE so it probably does only have 16 GPR registers. All the others e200 series cores have VLE as an option so they would require all 32 GPR registers but likely power down the unused registers when executing VLE code.

Quote:

I tend to think VLE isn't suitable for PPC. It breaks structure as all PPC used 32-bit codes. As a comparison, the Vampire is including a new 32-bit copper write, but this breaks structure because there will be 48-bit sized instructions. The copper is like PPC, it uses a set 32-bit code standard, anything else doesn't exactly belong. I think the Vampire guys should use 64 bits exactly otherwise the codes are out of alignment. The copper isn't a 68K, it's a very RISC co-processor. But I digress.

Adding code compression to the PPC was challenging because the 2 lowest bits of addresses were removed from branch encodings. I don't like how VLE code has to be in different memory regions or how most existing encodings were replaced even though most are still 32 bit encodings. This requires more developer support which, not surprisingly, wasn't strong. Higher end PPC CPUs would have benefited from code compression but it seemed late and poorly supported. ARM and RISC-V compressed ISAs appear to have utilized code density much better to their advantage. Some people thought code density didn't matter anymore yet the leading ISAs, minus x86_64, have leaned down.

Quote:

So early models like 75Mhz PPC? Up to 100 almost? Doesn't loop good if the new RISC was being beat by the old CISC.

The old CISC modernized has the advantages of RISC and CISC. There are some disadvantages to CISC but they aren't much worse than some bad RISC ideas like branch delay slots, register windows, conditional execution of large blocks of code, allowing the PC to be used explicitly in instructions, ignoring code density, etc.

Quote:

I didn't quite understand the Efika. It was slower and had less resources. If my timing is right wasn't the Efika released after the Pegasos? I suppose since it was PPC I expected it to run MOS. Otherwise why chose PPC? The move to ARM shows it didn't need PPC by the looks of it.

I'm not sure of the timing when Efika came out but it was sometimes criticized for lower performance than some of the "older" PPC hardware with more powerful CPUs like the G3.

Quote:

It doesn't but how much more power has the QorIQ? A MiniITX RPi would be better for our market.

The QorIQ SoCs have SerDes lanes to support SATA and PCIe so allow for more expansion and more expensive expansion than the RPi offers. Tabor is more of a MiniITX desktop than a RPi like device. If switching to the ARM based QorIQ SoCs, they could have the performance of a RPi 4 but I expect there will be a RPi 5 out with a few million more sold by then. The RPi hardware is not the newest or highest tech either but that is one of the ways they keep the price down.

Quote:

That's too many. For that amount with little discount you really need to invest time studying the technical specifications. The P1022 uses an e500v2 or similar core which now is almost ten years old. It was replaced by the e500mc where they scrapped this SPE idea and brought back the standard FPU. Unfortunately the timing wasn't right. Maybe it was more expensive but it would have been better waiting for some e500mc CPUs to turn up, which aparently was out in 2008. That was old in 2015 so I don't know how they missed it and ended up with an even older CPU.

There were probably plenty of cheap QorIQ e500v2 chips available after the QorIQ e500mc chips came out and customers complaining about compatibility upgraded. The e500v2 features look good on paper but they require too much developer support. The bargain probably looked like a good way to offer a better performance/price ratio on new Amiga hardware which is sorely needed but it was too good to be true.

Last edited by matthey on 05-Jun-2020 at 05:06 AM.
Last edited by matthey on 05-Jun-2020 at 03:40 AM.
Last edited by matthey on 05-Jun-2020 at 03:36 AM.

@Rose

Quote:

Thing that has puzzled me is that motherboard is said to be designed for Amiga use, why not put ~$1.5 RTL8111 on motherboard which was already supported.

I take the designed for Amiga saying with a grain of salt these days. The Sam had two Ethernet ports. But I think they caused confusion more than anything. Since OS4 doesn't autodetect. It would make sense to include chips that have working drivers. The Xena chip is added on the X1000. There is already a video chip with HDMI on the A1222 that's pretty much redundant apart from a back up.

Last edited by Hypex on 05-Jun-2020 at 05:32 PM.

@TRIPOS

"No problem"?



Yes no problem.

It's no problem for the dedicated market. Software can be tailoried to suit.

OS4 is not usng it for the intended use. OS4 wants to run desktop class code on an embedded CPU.

As a comparison, the G3 and G4 is similar enough to the 603, 604 or whatever the CyberStorm PPC used. With a wrapper WarpUP games like Hereitc II can run under OS4. But on a Sam it would eventually crash.

Quote:

The MPC5121e surprised (read: shocked!) by not being cache-coherent. This (and indeed other things) made Genesi pull the plug on their PPC based Efika path.

That's almost like going back to the Articia-S on the Pegasos I. The AmigaOne ws known for being cache-incoherent.

Quote:

The P1022 is way worse. It introduces an incompatible CPU into the eco-system, with instruction overlaps, etc. In a way like putting a ColdFire CPU in a 68k Amiga, thinking "the vendor can just compile their code so that's no problem".

LOL. For the vendor it's made for it's no problem.

Quote:

I believe all Linux distros has dropped support of the P1022 by now, as well as all major compilers?

GCC dropped SPE support some time recently. But, since OS4 SDK has an old GCC anyway, that's no problem!

Quote:

And still, after half a decade not being able to put a product to market, "AeonKit" has not abandoned the thought! Which is astonishing! But I suppose it goes completely in line with everything they have done so far, creating massively overpriced, under-specced and generally unwanted HW that is essentially nothing but lock-in dongles for OS4, honey-traps for the gullibles. Destroying any hope of a future for the platform in the process. No disaster ever in OS4's way too long history has helped killing off the OS4 platform more than "AeonKit" has. "Tabor" - any year now. Let's not go x86 or ARM, only Tabor is teh reel!!1!

It's been out four years. In the hands of betatesters. Shame it didn't work out as planned as it showed promise ansd lots of people were interested. But now people would expect more modern hardware. As I recently discovered, the P1022 is over ten years old. That's not only old in computer terms, it's old in PPC terms! Infact, a PPC that old, is like a 20 year old x86!

But, I don't think they could abandon it, because they have too much invested in it. A lot of time and money. They need to get it out there ASAP and get it done.

As to the x86 and now ARM argument. OS4 hasn't even been ported to little endian yet. So forget a native port. The only way it's running on x86 or ARM is through a custom emulator. Like the ALICE.

@Hypex

Quote:

As I recently discovered, the P1022 is over ten years old. That's not only old in computer terms, it's old in PPC terms! Infact, a PPC that old, is like a 20 year old x86!

To put it in perspective it's slightly slower than BCM2837B0 on Raspberry Pi 3B+. And thats when it's running native code.

Quote:

Rose wrote: To put it in perspective it's slightly slower than BCM2837B0 on Raspberry Pi 3B+. And thats when it's running native code.

The ARM Cortex-A53 is a low power offering being only 8 stage 2 way superscalar and in order. The Raspberry Pi was sticking to low power cores until the RPi 4 when it switched to a significantly higher performance core with the ARM Cortex-A72 which is deeply pipelined 3 way OoO. Performance has doubled in many benchmarks.

https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-4-73e5afbcd54b

The GPU is holding the RPi 4 back. Only 41 fps at 1280x720 for Quake 3 Arena reveals a major bottleneck in GPU performance. Tabor may be able to beat that with a descent gfx card *if* the floating point problem doesn't affect performance too much. Tower 57 gave some hope of acceptable 3D performance for the bastard PPC core. The RPi is still winning big time on performance/price but needs to update the GPU for entry level desktop performance. They can always move up to an ARM Cortex-A76 for more CPU performance if needed (3 times the integer performance of the Tabor CPU?). They would have trouble competing with higher performance x86_64 offerings but it doesn't matter if they can keep the price down. For Amiga, it's game over after the Tabor unless switching to another architecture or developing custom cores.