Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
|
Poster | Thread | matthey
|  |
Re: What Amiga products would you like to see? Posted on 26-Jan-2025 17:06:32
| | [ #41 ] |
| |
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2460
From: Kansas | | |
|
| kolla Quote:
No? Why?
First of all, RPi3... I presume you mean RPi3B+? Or do you mean RPi3A+? The first maxes out at 1GB of RAM, the latter at 512MB of RAM. Both have wifi and bluetooth.
A600GS has an Orange Pi Zero 3 which has up to 4GB of RAM, and is a lot cheaper as well. So why RPi3?
|
RPi hardware Broadcom SoCs have similarities like devices, especially the GPU. The RPi Foundation has tried to provide good documentation for the hardware and software and make it as open as possible. Also, they try to provide hardware availability of models for so many year and maintain form factor and pin out compatibility with the embedded standards they created. RPi hardware today resembles the standard hardware of the Amiga which would have become a 68k SoC in the 1990s had Commodore not been incompetent. Both the RPi Foundation and Commodore could have done a better job of standardization but it is much better than what the Amiga has become today.
Unfortunately, the RPi Foundation in-order CPU SoC offerings that are so important for embedded use are weak, even with the RPi 3B+ spec upgrade. They are likely losing significant embedded SBC volume due to less value than the competition. The Orange Pi Zero 3 not only out specs the RPi Zero 2W but the RPi 3B+ as well and it is not the only competition. The RPi Foundation targets the low power embedded market more with its in-order CPU SoCs including its in house fabless designed MCUs and has the higher performance embedded market covered with OoO CPU SoCs, but the Orange Pi exploits the middle ground between with higher performance from a low power in-order CPU SoC. The RPi Foundation should upgrade their in-order RPi 3 (Zero) to a Cortex-A55, at least LPDDR4 and a better chip process than 40nm but there may not be a Broadcom SoC with VideoCore GPU available with that configuration. That is the problem with using old smart phone SoCs which they may be addressing with fabless semiconductor development. For embedded use, it may never be worthwhile to upgrade past the in-order Cortex-A55 and OoO Cortex-A76 as the power efficiency of the successors have seen minimal improvement or declined. A chip process smaller than about 28nm, which the RPi 4 and OPi 3 Zero SoCs use, has reduced power and performance gains meaning price efficiency would be expected to decline as well. The end of Moore's law likely affects the embedded market before the high performance market as power efficiency and price efficiency are more important for the embedded market. ARM should work on improving the power efficiency of their in-order cores as lower power and cost in-order CPU cores on better silicon can offer better value than OoO cores on older silicon which has greatly contributed to PPC OoO CPU cores becoming antiquated by the weakest ISA on the market SiFive RISC-V 7-Series in-order cores using a CISC/68060 like design to reach 3.3 DMIPS/MHz, better than any PPC CPU core ever. A similar design using the 68k ISA would certainly be higher performance but the question remains if the power efficiency and price efficiency would improve, although the in-order 68060 was easily better than the in-order Pentium and competitive with OoO PPC CPUs in these metrics.
kolla Quote:
THEA500 Mini has a custom board, a lot cheaper than RPi3, and specifically no networking, so it doesn't fall into the category of products covered by the PSTI Act and similar, which would be a great economic risk for the vendor. So why RPi3?
|
Was THEA500 Mini custom board really that much cheaper than using RPi 3 hardware? Would a cheaper RPi Zero 2W have been used if it was available earlier and avoided COVID supply disruptions? Did THEA500 Mini customers find a way to get online? Does using a USB to networking adapter avoid the PSTI Act regulations?
Last edited by matthey on 26-Jan-2025 at 05:12 PM.
|
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 31-Jan-2025 2:12:42
| | [ #42 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
, the RPi Foundation in-order CPU SoC offerings that are so important for embedded use are weak, even with the RPi 3B+ spec upgrade. They are likely losing significant embedded SBC volume due to less value than the competition. |
https://www.londonstockexchange.com/news-article/RPI/interim-results/16679786
Unit volume (m) H1 2024 = 3.66m H1 2023 = 2.80m
Revenue ($m) H1 2024 = $144.0m H1 2023 = $89.3m
"Highlights include the successful IPO, strong uptake of Raspberry Pi5, and launch of new AI product"
Unfortunately, you're wrong.
Quote:
although the in-order 68060 was easily better than the in-order Pentium and competitive with OoO PPC CPUs in these metrics.
|
That's BS. 68060 was beaten by Pentium on Quake!!!
68060's very narrow L1 cache fetch bandwidth is easily exceeded by SysInfo benchmark.
Quake/Quake II/Quake 3engines are heavy FPU workloads.
Warp1260's 68060 @ 100Mhz with 2D RTG wouldn't even beat my classic Pentium 166 with S3 Trio 64 PC.
https://eab.abime.net/showpost.php?p=1720190&postcount=16 Carmageddon 68k chugs along around 3-to-5 fps on 68060 @ 100mhz TF1260 with Radeon (RTG).
Refer to https://arcziii.itch.io/carmageddon-68k comment on certain 3A product with Cortex A53 running Carmageddon 68k. PiStorm-Emu68 demolished both configs.
Carmageddon 68k is another heavy FPU game.
https://liliputing.com/up-4000-is-a-raspberry-pi-clone-with-an-x86-processor/ AAEON's UP 4000 is a Raspberry Pi Clone with an x86 processor i.e. Intel Celeron N3350, Pentium N4200 and Intel Atom x7-E3950 via Intel’s Apollo Lake architecture
AAEON's UP 4000 was displaced by UP 7000 series with Intel Gracemont E-Core microarchitecture.
AAEON is a different entity from A-EON. AAEON is a subsidiary of ASUS (ASUSTeK Computer Inc) targeting Raspberry Pi's market.
https://www.dfi.com/product/index/1598 AMD Ryzen Embedded R2000 "Picasso" Series in Raspberry Pi (known as "industrial Pi") form factor. AMD Picasso Embedded are desktop Ryzen 2000G/some mobile 3000U APU equivalents and are used in recent Tesla EVs. AMD's Picasso APUs are still fabricated by GoFlo and AMD can use their GoFlo allocation for embedded markets.
From real life X86-64 world, classic P5 Pentiums wouldn't be competing in the "industrial Pi" form factor i.e. newer X64 CPU cores are used instead.
Last edited by Hammer on 31-Jan-2025 at 03:38 AM. Last edited by Hammer on 31-Jan-2025 at 03:34 AM. Last edited by Hammer on 31-Jan-2025 at 03:22 AM. Last edited by Hammer on 31-Jan-2025 at 03:11 AM. Last edited by Hammer on 31-Jan-2025 at 03:04 AM. Last edited by Hammer on 31-Jan-2025 at 02:57 AM. Last edited by Hammer on 31-Jan-2025 at 02:55 AM. Last edited by Hammer on 31-Jan-2025 at 02:37 AM. Last edited by Hammer on 31-Jan-2025 at 02:21 AM. Last edited by Hammer on 31-Jan-2025 at 02:18 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | kolla
|  |
Re: What Amiga products would you like to see? Posted on 31-Jan-2025 18:39:48
| | [ #43 ] |
| |
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3359
From: Trondheim, Norway | | |
|
| @matthey
Quote:
Does using a USB to networking adapter avoid the PSTI Act regulations? |
Yes. And just plugging an adapter doesn’t work, the provided linux kernel isn’t built with support for network adapters so you need to add that support yourself._________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 31-Jan-2025 22:45:46
| | [ #44 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
typical code instructions load 26% (Cortex-A53: 4 cycles, 68060: 1 cycle but could be 2 per cycle with dual ported D-cache) store 10% (typically 1 cycle as data queued in store buffer) ALU 49% (1-2 instructions per cycle on average) branch 15% (0-1 cycle average with branch prediction)
There are no load-to-use stalls with 68k CPU designs and the also in-order 8-stage superscalar 68060 easily outperforms the Cortex-A53 in a per cycle comparison for executing 68k code. OoO ARM CPU cores can hide most of the L1 D-cache load-to-use latency but even the RPi 4 OoO Cortex-A72 cores are likely more than 6 times larger times 4 cores and the extra heat required a die shrink from a 40nm chip fab process to a 28nm process which have synergies to increase the cost. The ARM SoCs and SBCs are still very cheap compared to ancient silicon Amiga hardware but that leads to the other problem. Trevor wants to sell his outrageously expensive and hopelessly outdated PPC hardware so their ally AmigaKit has a reason to keep 68k hardware low end. OoO PPC silicon is being outperformed by more modern in-order ARM silicon with the latter having a large cost and power advantage, the reason why the old Cortex-A53 remains popular for Amiga emulation and is still used today despite poor performance.
|
A53 Floating Point and Vector Execution IPC FP32 ADD: 1.82 FP32 MUL: 1.67 FP32 FMA: 1.19
128-bit Vector FP32 Add: 0.91 128-bit Vector FP32 MUL: 0.91 128-bit Vector FP32 FMA: 0.95 128-bit Vector INT32 ADD: 0.95 128-bit Vector INT32 MUL: 0.91 128-bit Load from memory: 0.49 128-bit Store: 1
Dual issue ability doesn’t apply to vector operations. 128-bit instructions can’t be issued alongside scalar FP instructions.
A53 also has limited reordering capability that gives it some wiggle room around cache misses before stalling. Only eight total instructions in flight. Four floating point instructions in flight.
Assuming a L1 Data cache hit, memory loads have a latency of 3 cycles if a simple addressing mode is used, or 4 cycles with scaled, indexed addressing.
This single AGU pipeline means the A53 cannot sustain more than one memory operation per cycle. It’s a significant weakness compared to even the weakest out-of-order CPUs, which can usually handle two memory operations per cycle.
Unlike 68060's floating point capability, Cortex A53 can do dual-issue scalar floating point operations
Pipe FP01 = FADD, FMUL, FMA Pipe FP02 = FADD, FMUL, FMA FP pipelines combine to form a 128-bit vector unit.
For the Switch game console, Nintendo selected Cortex A57 instead of A53.
Cortex A53 is below a mainstream game console's A57 selection. Cortex A72 from RPi CM4 or 4B is on par with mainstream game console's A57. Cortex-A72 is an evolution of the Cortex-A57.
For history, during A500's 1987 to 1991, A500's 68000 selection is contemporary with mainstream game consoles such as the Sega Mega Drive/Genesis 68000. Motorola wasn't successful with the full 32-bit and 64-bit game console era which are dominated by R3000A MIPS and MIPS R5900.
Commodore touched the MIPS CPU family via custom MIPS-X @ 40 Mhz with CDTV-CR/CD32's FMV MPEG1/VCD module. The incoming PiStorm16 was designed for A600's RPi CM4 transition.
My unmodified RPi 4B with A500's PiStorm has L shape adapter that moves the addon PCB stack toward the back. Last edited by Hammer on 31-Jan-2025 at 10:54 PM.
_________________ 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | matthey
|  |
Re: What Amiga products would you like to see? Posted on 1-Feb-2025 21:44:35
| | [ #45 ] |
| |
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2460
From: Kansas | | |
|
| matthey Quote:
... the RPi Foundation in-order CPU SoC offerings that are so important for embedded use are weak, even with the RPi 3B+ spec upgrade. They are likely losing significant embedded SBC volume due to less value than the competition.
|
Hammer Quote:
Does the RPi 5 use in-order CPU cores? Is it popular for embedded use?
Volumes are up because of the new RPi 5 but it is less desirable for embedded use than the RPi 3 and RPi 4 which are cheaper and cooler.
https://www.londonstockexchange.com/news-article/RPI/interim-results/16679786 Quote:
Total board sales volumes increased by 31% on the supply constrained first half of 2023, due to the growth in compute module sales and 1.1 million unit sales of Raspberry Pi5 (launched in October 2023), while as expected, there was a decline in Raspberry Pi4 unit sales and the sales of legacy boards. In aggregate, volumes were marginally lower than expected as higher than usual customer and channel inventory levels persisted through Q2. We anticipate higher unit volumes for the second half, supported by new product launches.
...
ASP increased by 28% from $36.8 in 2023 to $47.2 in 2024 due to an increase in the mix of higher price Raspberry Pi4, Raspberry Pi5 boards and compute modules. The gross profit per unit of these higher priced boards was accordingly higher. However, as anticipated, the unit gross profit of Raspberry Pi5 boards was not as high as for Raspberry Pi4 and the increase in gross profit per unit was therefore not as large as the ASP increase.
The gross profit of accessories increased by 74% to $4.1 million as a result of higher board sales and in particular accessories for the new Raspberry Pi5 and improved margins on displays.
Gross margin reduced to 23.8% (2023: 26.1%) largely reflecting the higher mix of component sales in the half.
|
Margins are down for the RPi 5 compared to RPi 4, likely due to the desire to keep the cost below low end x86-64 SBCs. RPi 5 accessories for cooling and power supply are practically a necessity and make up for some of the SBC margin loss but they raise the total cost and the extra heat and power are bad for embedded use. The RPi 4 is more practical for embedded use and has higher margin but the older weaker OoO CPU cores are vulnerable to smaller cheaper in-order cores that come close to the performance with less power and cooling needs. SBCs with Cortex-A55 cores, LPDDR4 memory and a better chip process endangers both the RPi 3 and RPi 4 and they already exist. The SiFive series 7 in-order CPU cores are reaching 3.3 DMIPS/MHz, better performance than any PPC cores ever, and we witnessed how quickly PPC OoO cores using older silicon were antiquated by more powerful and much cheaper in-order cores.
The RPI stock has performed wonderfully, doubling recently, which I pointed out in a post on here. Eben Upton is as good as Trevor Dickinson is bad. Eben has been focusing on the higher end higher margin RPi models while the RPi 3B+ upgrade was not enough. It is kind of like ARM pushing up into higher end markets with ARM64/AArch64 while their in-order cores and code dense Thumb cores that won the embedded market receive less attention. ARM pretty well wiped out the competition first with code density only the 68k could match and where it was derived from, 68k to SuperH to Thumb(-2). RPI has lots of cheap Chinese SBC competition using the same poor selection of in-order ARM cores. There may not be a Broadcom SoC that is competitive enough so they may need to design their own SoCs to remain competitive and compatible with features and specs better selected for the target markets. Their fabless semiconductor MCUs have been very successful and they increased their engineering staff from 46 to 61 with increased R&D funding so I expect to see more SoCs, perhaps more than MCUs in the future. However, the valuation of RPI in light of the competition and with AI and tech valuations coming into question, is too high for me to consider. Their reputation is good and they are dependable but they produce low end low margin hardware and they dominate the hobby and embedded markets far less than ARM Holdings.
matthey Quote:
... although the in-order 68060 was easily better than the in-order Pentium and competitive with OoO PPC CPUs in these metrics.
|
Hammer Quote:
That's BS. 68060 was beaten by Pentium on Quake!!!
...
From real life X86-64 world, classic P5 Pentiums wouldn't be competing in the "industrial Pi" form factor i.e. newer X64 CPU cores are used instead.
|
Bait and switch again? At the end, you admit that there are no in-order P5 Pentium like cores that scale down to RPi and smartphone levels, despite Intel trying twice with Bonnell (Atom) and Larrabee micro-architectures. The 68060 was easily better than the P5 Pentium in PPA just as i contended. Let us compare using PPA the 68060 with the P54C both using a 500nm process and operating at 3.3V.
Power 5.5W@75MHz 9.5W@75MHz (+73% for Pentium) Performance 1.20 0.82 (+46% for 68060) Area 2.5million 3.3million (+32% for Pentium)
Power is max or worst case Watts. Performance is integer performance from the ByteMark benchmark (https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45085&forum=33&start=780&794#867044). PPA is important for embedded use but even floating point heavy programs like Photoshop are ~94% integer instructions (https://www-appuntidigitali-it.translate.goog/18054/statistiche-su-x86-x64-parte-1-macrofamiglie-di-istruzioni/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp). Transistor counts are used as an estimate of area.
The in-order 68060 dominated the in-order P54C Pentium in PPA desired for embedded use. This also helps explain why the 68060 was a success in the embedded market and the Pentium was not. The x86 architecture had been successful in the embedded market up to the Pentium. Later OoO x86 CPUs were unsuccessful in the embedded market as they used significantly more power and area even though the performance improved.
matthey Quote:
typical code instructions load 26% (Cortex-A53: 4 cycles, 68060: 1 cycle but could be 2 per cycle with dual ported D-cache) store 10% (typically 1 cycle as data queued in store buffer) ALU 49% (1-2 instructions per cycle on average) branch 15% (0-1 cycle average with branch prediction)
There are no load-to-use stalls with 68k CPU designs and the also in-order 8-stage superscalar 68060 easily outperforms the Cortex-A53 in a per cycle comparison for executing 68k code. OoO ARM CPU cores can hide most of the L1 D-cache load-to-use latency but even the RPi 4 OoO Cortex-A72 cores are likely more than 6 times larger times 4 cores and the extra heat required a die shrink from a 40nm chip fab process to a 28nm process which have synergies to increase the cost. The ARM SoCs and SBCs are still very cheap compared to ancient silicon Amiga hardware but that leads to the other problem. Trevor wants to sell his outrageously expensive and hopelessly outdated PPC hardware so their ally AmigaKit has a reason to keep 68k hardware low end. OoO PPC silicon is being outperformed by more modern in-order ARM silicon with the latter having a large cost and power advantage, the reason why the old Cortex-A53 remains popular for Amiga emulation and is still used today despite poor performance.
|
Hammer Quote:
A53 Floating Point and Vector Execution IPC FP32 ADD: 1.82 FP32 MUL: 1.67 FP32 FMA: 1.19
128-bit Vector FP32 Add: 0.91 128-bit Vector FP32 MUL: 0.91 128-bit Vector FP32 FMA: 0.95 128-bit Vector INT32 ADD: 0.95 128-bit Vector INT32 MUL: 0.91 128-bit Load from memory: 0.49 128-bit Store: 1
|
About 1 in 4 instructions is a load in typical code which is mostly integer instructions. About 1 in 20 instructions is a SIMD or FPU instruction in Photoshop while most programs will have far fewer of these instructions. With an in-order CPU core design like the Cortex-A53 and without instruction scheduling like ARM to 68k JIT compilation, loads will commonly require 4-5 cycles each where most other instructions require ~1 cycle. Does anything else as far as Cortex-A53 performance matter? Is 68k Amiga code more likely to be integer or floating point code?
OoO cores can sometimes avoid load-to-use stalls but they are often several times the size of in-order cores. An OoO Cortex-A57 core is about 6 times larger than an in-order Cortex-A53 core, uses more power and dissipates more heat. Load-to-use stalls kill performance and the Cortex-A53 load-to-use penalty of 3 cycles is one of the worst.
CPU/core | load-to-use penalty 68060 0 Cortex-A7 1 Cortex-A53 3 Cortex-A55 2 SiFive-U74 0
A load-to-use penalty of 3 cycles makes instruction scheduling very difficult as 6 independent superscalar instructions have to be placed under each load to avoid stalling. Compiler instruction schedulers will often not be able to find enough independent instructions to place after the load thus reducing performance. It is a bad design and a reason why the Cortex-A55 successor reduced the load-to-use penalty which is a big improvement but it is still difficult to find 4 independent instructions to place under a load. SiFive figured out the solution which is to eliminate the load-to-use penalty altogether by using a CISC/68060 like design. It is better for a CISC ISA like the 68k ISA which allows to execute the equivalent of 2 RISC instructions in each execution pipe but even the weak RISC-V ISA reaches 3.3 DMIPS/MHz with an in-order 7 series core design, better than any OoO PPC CPU core ever.
|
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 1-Feb-2025 23:03:03
| | [ #46 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
Does the RPi 5 use in-order CPU cores? Is it popular for embedded use? |
Bait and switch again, Amiga is NOT embedded. Amiga is a desktop computer with a gaming bias use case and audience.
Quote:
Margins are down for the RPi 5 compared to RPi 4, likely due to the desire to keep the cost below low end x86-64 SBCs. RPi 5 accessories for cooling and power supply are practically a necessity and make up for some of the SBC margin loss but they raise the total cost and the extra heat and power are bad for embedded use. The RPi 4 is more practical for embedded use and has higher margin but the older weaker OoO CPU cores are vulnerable to smaller cheaper in-order cores that come close to the performance with less power and cooling needs. SBCs with Cortex-A55 cores, LPDDR4 memory and a better chip process endangers both the RPi 3 and RPi 4 and they already exist. The SiFive series 7 in-order CPU cores are reaching 3.3 DMIPS/MHz, better performance than any PPC cores ever, and we witnessed how quickly PPC OoO cores using older silicon were antiquated by more powerful and much cheaper in-order cores.
|
SiFive series 7 doesn't have SIMD hardware and has a single FPU port.
For SiFive U74's S7 CPU core LH, LHU, LB, LBU, LW instructions = Three-cycle latency, assume cache hits. Effective address not ready in AG stage. Load latency use = load to use delay + 1
MUL, MULH, MULHU, MULHSU = Three-cycle latency
DIV, DIVU, REM, REMU = Between six-cycle to 68-cycle latency, depending on operand values
CSR Reads = One-cycle latency, cycle delay + 1
Provided there are no data hazards between a pair of instructions, the two instructions may issue in the same cycle, provided the following constraints are met: • At most, one instruction accesses data memory. • At most, one instruction is a branch or jump. • At most, one instruction is a floating-point arithmetic operation. • At most, one instruction is an integer multiplication or division operation. • Neither instruction explicitly accesses a CSR.
Not a good processor solution for low-cost 3D command list generation for 3D accelerator.
Cortex A53 can dual issue up to two FP instructions and a single FP issue on SiFive U74.
Quote:
The in-order 68060 dominated the in-order P54C Pentium in PPA desired for embedded use. This also helps explain why the 68060 was a success in the embedded market and the Pentium was not. The x86 architecture had been successful in the embedded market up to the Pentium. Later OoO x86 CPUs were unsuccessful in the embedded market as they used significantly more power and area even though the performance improved.
|
Bait and switch again, Amiga is NOT embedded. Amiga is a desktop computer with a gaming bias use case and audience.
From DataQuest, 68060 unit sales didn't replace 68000's success. 68060's unit sales are small.
P5 Pentium targets desktop gaming and business software. FPU-heavy 3D gaming killed Cyrix 6x86. Direct3D geometry pipeline has Intel SSE and AMD 3DNow optimizations. Quake II has AMD 3D Now optimization.
Carmack reported that a MMX version of Quake he had in alpha stages would run, at best, the same speed in 16-bit color as an 8-bit color version does on a non-MMX Pentium chip of the same clock speed. Unreal 3D game engine uses MMX.
For 1990s, MIPS R3000A, R4400 and R5900 dominated low-cost 3D CPUs. 68060 and 68LC060 is too expensive for a low-cost 3D use case.
http://www.quake2.com/q2faq.html#II.4
Quake II does NOT use Intel's latest MultiMedia eXtensions. Unreal will though as well as other upcoming games. Even then, it's wise to buy a MMX chip if you're already thinking of upgrading your machine.
The Quake engine uses the Intel FPU extensively, and also uses a native feature of the Intel FPU called Parallel FPU lines. This allows simultaneous integer and FPU calculations and Quake uses these to do lots of calculations at the same time. The problem is that the MMX instructions use the Parallel FPU lines for calculation, and if MMX were supported in Quake, Quake and the MMX would be fighting over the usage of the Parallel FPU lines. This isn't the problem for most programs because Quake is just about the first major program that even uses Parallel FPU lines in the first place, so other programs don't have this conflict.
Carmack reported that a MMX version of Quake he had in alpha stages would run, at best, the same speed in 16-bit colour as an 8-bit colour version does on a non-MMX Pentium chip of the same clock speed. Carmack says this increase in colour depth only isn't worth the development time and money and has decided not to support MMX with the Quake engine in its current form.
Quake II has optimization for AMD K6-II with 3D Now support that will crush Quake II 68K 68060 version.
For the late 1990s R&D phase, AMD K7 Duron with 3DNow+ and later Bill Gates intervention Intel Coppermine with SSE was selected for the original Xbox. 68060 or ColdFire wasn't selected for a high-performance embedded 3D game console.
AMD Jaguar (K16) was selected as a low-cost high-performance embedded 3D game console i.e. Xbox One and PS4. During the contract bargaining phase, AMD Jaguar competed against and beat ARM Cortex A15 and IBM PowerPC A2 (PPE follow-on).
AMD Jaguar has dual port 128-bit SIMD (packmath INT and FP) units with support for 256-bit AVX via double pump methods and optimized for AMD's AVX-128 subset. This layout was doubled into four 128-bit pipelines in Zen1 with two FADD and two FMA/MUL pipelines. This layout was doubled into four 256-bit pipelines with Zen 2 (current-gen Xbox Serise S/X and PS5).
For PS6 and Next Xbox, Zen 6 wins game console contracts. Each Zen 6 CCD has 12 CPU cores with multiple 512-bit SIMD units. Intel competed in PS6 and Next Xbox contracts.
PS6/Next Xbox would have AMD's latest semi-custom Zen 6, NPU, and UDNA GPU IP (after RDNA 4).
AMD created a K12 ARMv8 clone for the Nintendo Switch contract bargaining phase. K12 recycled Zen1 R&D. Nintendo's selection for NVIDIA's TX1 SOC is due to NVIDIA's superior 3D game development support.
AMD wins Valve's SteamDeck (Zen 2, RDNA2, DSP) handheld (embedded) game console contract. SteamOS 3.x official support has expanded to other PC vendors for Steam Deck clones with AMD's Strix Point/Kraken Point-based SoCs.
From history, A500's 68000 selection was contemporary with mainstream game consoles such as Sega Mega Drive's 68000. In modern times, PiStorm-Emu68's ARM Cortex A72 is contemporary with lowball mainstream Nintendo Switch's ARM Cortex A57.
AMD is winning 3D games embedded devices more than NXP/Freescale and RISC-V. NVIDIA Switch/Switch 2 and Intel Meteor Lake/Luna Lake SoC (Steam Deck clones) are also heavily participating in 3D games embedded devices that are mostly driven by GpGPU offerings vs value. Historically, Amiga's value-add is with the GPU aspect, not with the off-the-self 68000 CPU
On value, Intel Battle Mage 580's USD $256 price range with RTX 4060+ performance range is hard to beat.
Last edited by Hammer on 02-Feb-2025 at 02:56 AM. Last edited by Hammer on 01-Feb-2025 at 11:43 PM.
_________________ 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | kolla
|  |
Re: What Amiga products would you like to see? Posted on 2-Feb-2025 0:30:42
| | [ #47 ] |
| |
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3359
From: Trondheim, Norway | | |
|
| @Hammer
Quote:
Debatable. Amiga systems were also sold as embedded, even branded with (among others) SCALA and Newtek logos.
On the other hand, RPi5 is much less of an embedded system than what previous models were, RPi5 is more akin to be a desktop or server.Last edited by kolla on 02-Feb-2025 at 12:31 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 2-Feb-2025 1:38:19
| | [ #48 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
The in-order 68060 dominated the in-order P54C Pentium in PPA desired for embedded use. This also helps explain why the 68060 was a success in the embedded market and the Pentium was not. The x86 architecture had been successful in the embedded market up to the Pentium. Later OoO x86 CPUs were unsuccessful in the embedded market as they used significantly more power and area even though the performance improved.
|
Fact: Motorola/Freescale 68K CPU designs wouldn't be winning in mainstream embedded game consoles during post-1993 full 32bit and 64bit.
Fact 2: The original Xbox embedded game console, Coppermine CPU demolished Cold Fire V on 3D processing.
Embedded 3D game consoles AMD wins Steam Deck AMD wins MS Xbox One and Xbox One X AMD wins Sony PS4 and PS4 Pro AMD wins Sony PS5 and PS5 Pro AMD wins MS Xbox Series S and X. AMD wins Sony PS6 AMD wins MS Next Xbox after Xbox Series X. AMD wins Lenovo Legion Go S (SteamOS 3.x OEM, Ryzen Z2 SoCs), Valve's 1st officially supported Steam Deck clone. https://www.youtube.com/watch?v=UmdVELEBtgY
AMD Phoenix 2/Hawk Point/ Strix Point and Intel Meteor Lake / Luna Lake SoCs have design wins with embedded 3D game handhelds i.e. Steam Deck clones with Windows 11.
USB4 enables GpGPU upgrades.
How many AMD/Intel X64 designs win and install base size to shut you up on embedded 3D gaming?
Quote:
About 1 in 4 instructions is a load in typical code which is mostly integer instructions. About 1 in 20 instructions is a SIMD or FPU instruction in Photoshop while most programs will have far fewer of these instructions.
|
Are you claiming 68060 Rev6 @ 100 to 133Mhz is the fastest Mac 68K against PiStorm-Emu68-RPi 3A @ 1.4Ghz?
Amiga 68K couldn't use Quake II engine's 3DNow SIMD optimizations since 68060 and Cold Fire V does NOT have 3DNow equivalency!
68060 or Cold Fire V is behind on PC's Direct3D's SSE and 3D Now geometry pipeline optimization use case.
Quote:
With an in-order CPU core design like the Cortex-A53 and without instruction scheduling like ARM to 68k JIT compilation, loads will commonly require 4-5 cycles each where most other instructions require ~1 cycle. Does anything else as far as Cortex-A53 performance matter? Is 68k Amiga code more likely to be integer or floating point code?
|
Are you claiming 68060 Rev6 @ 100 to 133Mhz is the fastest Mac 68K against PiStorm-Emu68-RPi 3A @ 1.4Ghz? Your argument is absurd.
PiStorm16 is purposely designed for RPi CM4 upgrade and A600.
There's a high chance Pentium-era game ports for the 68K Amiga platform will be FPU heavy. Cyrix 6x86 died in the marketplace for valid reasons.
Cortex-A53 is under embedded mainstream 3D game console Nintendo Switch's Cortex A57 level.
Quote:
OoO cores can sometimes avoid load-to-use stalls but they are often several times the size of in-order cores. An OoO Cortex-A57 core is about 6 times larger than an in-order Cortex-A53 core, uses more power and dissipates more heat. Load-to-use stalls kill performance and the Cortex-A53 load-to-use penalty of 3 cycles is one of the worst.
|
Are you claiming 68060 Rev6 @ 100 to 133Mhz is the fastest Mac 68K against PiStorm-Emu68-RPi 3A @ 1.4Ghz?
Photoshop Mac68K runs on both 68060/A1200 and PiStorm-Emu68/A1200 via Shapeshifter.
PiStorm16 is purposely designed for RPi CM4 upgrade and A600.
Tomb Raider (OpenLara) on 68060 @ 100Mhz Amiga 68K would be interesting to see i.e. more LOL on 68060. Carmageddon 68K is a slideshow joke on 68060 Rev6 @ 100Mhz. My 1996 estimate on the 68060 upgrade for my A3000 vs Pentium 166 PC build continues to be correct.
OpenLara port for 3DO uses ex-original Amiga engineers' designed 3D hardware acceleration. GoldStar (LG) sold 3DO at USD399.
As the Amiga 68K platform gains well-known Pentium-era game ports, it shows the absurdity of your argument i.e. 68060 is a con job.
Again, Cortex-A53 has a limited out-of-processing before stalling i. 8 instructions deep for integers and 4 instructions deep for floating point. Cortex-A53 is not a strict in-order with in-order loads CPU.
On 3D games, Warp1260's 68060 @ 100Mhz with 2D RTG wouldn't beat my 1996 era Pentium 166 with S3 Trio 64UV+ PC build.
https://www.youtube.com/watch?v=vxYnz3S87uE Carmageddon 68K port on Amiga 4000 with 68060 running in 100Mhz and zz9000 gfx, it doesn't get a good framerate.
https://www.youtube.com/watch?v=wJpMeIjQwCA Carmageddon 68k port test on Amiga 1200 with PiStorm32-Emu68 and RPi 4B. Smooth frame rates.
https://www.youtube.com/watch?v=FXN9SGK8xBQ Carmageddon WarpOS port on Amiga 4000 with Ragnarok PowerPC G3 750FX 800 Mhz (WarpOS, sonnet. Library by Dennis Boon) and Voodoo3 PCI. Good frame rate results. https://www.amiga-news.de/en/news/AN-2018-08-00031-EN.html Cheap PowerPC-based network PCI card for Amiga WarpOS. PowerPC-based network PCI card doesn't have the usual Amiga 3rd party tax.
Last edited by Hammer on 02-Feb-2025 at 03:38 AM. Last edited by Hammer on 02-Feb-2025 at 03:18 AM. Last edited by Hammer on 02-Feb-2025 at 02:36 AM. Last edited by Hammer on 02-Feb-2025 at 02:28 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 2-Feb-2025 1:54:01
| | [ #49 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @kolla
Quote:
kolla wrote: @Hammer
Quote:
Debatable. Amiga systems were also sold as embedded, even branded with (among others) SCALA and Newtek logos.
|
They are a tiny minority.
Amiga 2000 with the Newtek logo is just a video workstation.
My local shopping mall's information kiosk machines are running X86-64 PCs e.g. disk failure shows Ami BIOS.
https://www.tomshardware.com/software/windows/ms-dos-and-windows-311-still-run-train-dashboards-at-german-railway-company-listed-admin-job-for-30-year-old-operating-system MS-DOS and Windows 3.11 still run train dashboards at the German railway. The systems have 166MHz processors and a 8MB of RAM.
https://www.thebookpc.com/product-p/sca-p1.htm Scala preinstalled AOpen DE5100I (Intel Core i3 and mobile Intel HM65 Express platform).
https://www.youtube.com/watch?v=PkmM-TPiO04 Scala Media B308 Player L Windows 10 IoT Enterprise LTSB Digital Signage Unit with Intel Atom x5-Z8350 SoC.
I can play the "embedded" game.
https://www.virtualgraffiti.com.au/Partner/Scala My local SCALA vendor in Australia. SCALA bundles - Six-core Rockchip RK3399 (2 core A72 and 4 core A53, Mali-T860 MP4). - Intel Atom x5-Z8350 (Cherry Trail quad-core, HD Graphics 400). - Intel Celeron N3160 (Braswell quad-core, HD Graphics 400), two SKUs. - AMD Ryzen V1202B (Zen 1 dual-core/4 threads, RX Vega 3 IGP), two SKUs and designed for 4K UHD.
Quote:
On the other hand, RPi5 is much less of an embedded system than what previous models were, RPi5 is more akin to be a desktop or server.
|
https://www.youtube.com/watch?v=1zwehc6E1RY Raspberry PI 4 running HONKAI Impact, ANDROID 11(LineageOS 18.1). It's like an old mobile phone.Last edited by Hammer on 02-Feb-2025 at 02:21 AM. Last edited by Hammer on 02-Feb-2025 at 02:15 AM. Last edited by Hammer on 02-Feb-2025 at 02:05 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | matthey
|  |
Re: What Amiga products would you like to see? Posted on 2-Feb-2025 3:22:23
| | [ #50 ] |
| |
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2460
From: Kansas | | |
|
| Hammer Quote:
Bait and switch again, Amiga is NOT embedded. Amiga is a desktop computer with a gaming bias use case and audience.
|
News flash. Amiga wannabe hardware uses embedded CPU cores. X1000, X5000, A1222, Sam440/460, Efika PPC, THEA500 Mini and the A600GS all use embedded SoCs. The RPi uses embedded SoCs too although prices are low enough that about half of their sales are into the embedded market which improves economies of scale. There is nothing wrong with using embedded cores and embedded in-order cores for the low end market like RPi hardware. Choose the hardware wisely and stay away from compromised for embedded use hardware like the A1222 SoC without a FPU and the Cortex-A53 with a 3 cycle load-to-use latency when JIT compilation produces unscheduled Cortex-A53 code.
Hammer Quote:
SiFive series 7 doesn't have SIMD hardware and has a single FPU port.
|
SiFive has a SoC with in-order 7 series CPU cores and a vector unit which they won the NASA contract to replace PPC OoO CPU cores with.
https://www.sifive.com/cores/intelligence-x280 Quote:
o SiFive Intelligence Extensions for ML workloads - Custom instructions to greatly accelerate Neural Network computation - Optimized TensorFlow Lite implementation - Hundreds of Neural Network models ported - 4.6 TOPS performance o 512-bit vector register length processor - Variable length operations, up to 512-bits of data per cycle - Ideal balance of control logic and data parallel compute - Decoupled Vector pipeline - INT8 to INT64 integer data type - BF16/FP16/FP32/FP64 floating point data type o Performance benchmarks - 5.75 CoreMarks/MHz - 3.25 DMIPS/MHz - 4.6 SpecINT2k6/GHz o Built on silicon-proven U7-Series core - 64-bit RISC-V ISA - 8-stage dual-issue in-order pipeline - Coherent multi-core, Linux capable o High performance vector memory subsystem - Memory parallelism provides cache miss tolerance - Virtual memory support with precise exceptions - Up to 48-bit addressing o Multi-core, multi-cluster processor configuration, up to 8 cores
|
It looks like the 7-series has continued to increase performance.
https://www.sifive.com/cores/essential-7 Quote:
o Up to 3.32 DMIPS/MHz, 5.75 Coremarks/MHz
|
SiFive has improved the performance of the 7-series several times some of which likely comes from newer silicon. You have seen the following old chart which shows 2 different older SiFive 7-series SoCs with difference performance.

Despite the weak RISC-V ISA handicap, the in-order 7-series CPU cores were already matching the OoO Cortex-A57 cores (Nintendo Switch) but five 7-series cores is likely smaller than one OoO Cortex-A57 core (the SiFive JH71110 SoC has 4xU7 and 1xS7 cores). It is not just OoO PPC CPU cores which are becoming obsolete on old silicon but older ARM OoO cores on old silicon too. It is really bad when much smaller and cheaper in-order cores approach the performance of and can replace big expensive OoO cores.
Hammer Quote:
For SiFive U74's S7 CPU core
|
I am not sure why you are looking at the S7 core latencies. The S7 core is for real time use, I/O and system functions although latencies are generally similar. S7 cores are more like ARM Cortex-R cores where U7 cores are more like Cortex-A cores. The SiFive core naming conventions are more confusing than the more logical ARM names.
Hammer Quote:
LH, LHU, LB, LBU, LW instructions = Three-cycle latency, assume cache hits. Effective address not ready in AG stage. Load latency use = load to use delay + 1
|
SiFive documentation describes what they call a load-use delay in different ways.
SiFive U74-MC Core Complex Manual 21G3.02.00 Quote:
Loads produce their result in the M2 stage. There is no load-use delay for most integer instructions. However, effective addresses for memory accesses are always computed in the AG stage. Hence, loads, stores, and indirect jumps require their address operands to be ready when the instruction enters AG. If an address-generation operation depends upon a load from memory, then the load-use delay is two cycles.
|
I prefer the Motorola terminology which calls these delays change/use delays.
M68060 USER’S MANUAL 10-10 Quote:
The OEP does not experience any sequence-related pipeline stalls. The most common example of this type of stall is a “change/use” register stall. This type of stall results from a register being modified by an instruction and a subsequent instruction generating an address using the previously modified register. The second instruction must stall in the OEP until the register is actually updated by the previous instruction. For example:
muls.l #,d0 mov.l (a0,d0.l*4),d1
In this sequence, the second instruction is held for 2 clock cycles stalling for the first instruction to complete the update of the d0 register. If consecutive instructions load a register and then use that register as the base for an address calculation (An), a 2-clock-cycle wait may be incurred. This represents the maximum change/use penalty for a base register. The maximum change/use penalty for an index register (Xi) is 3 clock cycles (for Xi.l*2, Xi.l*8, and Xi.w). The change/use penalty for an index register if Xi.l*1 or Xi.l*4 is 2 clock cycles.
|
The 68060 manual goes on to describe hardware optimizations that avoid or minimize change/use stalls. Change/use stalls are easier to avoid than load-to-use stalls as the performance of the 68060 and SiFive 7 series cores show. There are no change/use stalls for the simplest addressing modes and only complex index register addressing modes could experience the worst case 3 cycle stalls. ARM cores with load-to-use stalls often need extra cycles for complex EA calculations of loads as you mentioned earlier. The Cortex-A53 can require 5 cycles worst case for a complex addressing mode load with maximum load-to-use stall and there are no hardware optimizations to avoid any load-to-use stalls like for common change/use stalls on the 68060. More change/use hardware optimizations on the 68060 are likely possible as well. The SiFive U7 cores just do not have complex addressing modes which reduces the need for hardware optimizations but may increase complex addressing mode load latencies by requiring more dependent instructions.
Hammer Quote:
MUL, MULH, MULHU, MULHSU = Three-cycle latency
DIV, DIVU, REM, REMU = Between six-cycle to 68-cycle latency, depending on operand values
CSR Reads = One-cycle latency, cycle delay + 1
Provided there are no data hazards between a pair of instructions, the two instructions may issue in the same cycle, provided the following constraints are met: • At most, one instruction accesses data memory. • At most, one instruction is a branch or jump. • At most, one instruction is a floating-point arithmetic operation. • At most, one instruction is an integer multiplication or division operation. • Neither instruction explicitly accesses a CSR.
Not an ideal processor solution for low-cost 3D command list generation for 3D accelerator.
|
U7 core latencies are often worse than 68060 latencies but integer MUL and most FPU instructions are fully pipelined where the 68060 integer MUL and FPU are not. Integer division, FDIV and FSQRT are not pipelined on either.
instruction | 68060 latency | U7 latency int_mul 2 3 int_div ?-38 6-68 FABS 1 2 FADD 3 5 FDIV 37 9-58(.d)/9-36(.s) FMUL 3 5 FNEG 1 2 FSQRT 68 9-57(.d)/9-28(.s)
The RISC-V FPU ISA has many instructions I wanted to add to the Spartan 68k FPU, which would improve performance. The fully pipelined U7 FPU helps for heavy FPU use but mixed int and FPU code is more common where the 68060 reduced latencies are better. Both of these FPUs are more embedded use FPUs than desktop use FPUs but still much better than the A1222 embedded PPC SoC non-FPUs.
Hammer Quote:
Bait and switch again, Amiga is NOT embedded. Amiga is a desktop computer with a gaming bias use case and audience.
From DataQuest, 68060 unit sales didn't replace 68000's success. 68060's unit sales are small.
|
The 68060 was a high end high margin embedded market CPU. The successful desktop Pentium could not match the 68000 and perhaps 68020 volumes either. The in-order high performance desktop P5 Pentium was at least 6 different designs that increased from 3.1 million to 4.5 million transistors too. The 68060 was a minimalist in-order high end embedded CPU design that balanced power and area with performance yet it still competed in performance with the most comparable P54C Pentium and destroyed the P54C in PPA important for embedded use. Motorola throwing out their beautiful 68k baby for a fat and ugly PPC baby for political instead of technical reasons is reprehensible but Trevor did the same thing.
Last edited by matthey on 02-Feb-2025 at 03:32 AM. Last edited by matthey on 02-Feb-2025 at 03:29 AM. Last edited by matthey on 02-Feb-2025 at 03:23 AM.
|
| Status: Offline |
| | bhabbott
|  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 2:21:39
| | [ #51 ] |
| |
 |
Cult Member  |
Joined: 6-Jun-2018 Posts: 509
From: Aotearoa | | |
|
| @matthey
Quote:
matthey wrote: Motorola throwing out their beautiful 68k baby for a fat and ugly PPC baby for political instead of technical reasons is reprehensible but Trevor did the same thing.
|
Political? No. The reason they dropped 68k was simply that other architectures were faster, and Motorola was struggling to keep up. It wasn't Motorola who made the decision to switch, it was their customers who weren't getting a powerful enough CPU. Sun developed SPARC because 68k wasn't fast enough. Apple turned to PPC for the same reason.
From the user's perspective the ISA was irrelevant. Compilers took care of differences so developers didn't care, and only the results mattered. So when the results showed x86 machines performing better, everybody wanted them (even more than they did anyway because PCs were the industry standard). With Motorola not keeping up, computer makers who were using 68k turned to RISC because it was widely recognized as the way to get more speed with less effort. By 1993 even Commodore intended to go RISC.
Part of the reason 68k wasn't faster is that Motorola wasn't as good at making chips as Intel. The first batch of 68020's had practically zero yield. The 68030 was better but it was beaten to market by the 80386. When they finally got the power hungry 68040 out a year after the 80486 and never got it to go faster than 40MHz, it was obvious that they were never going to keep up. By 1994 Intel had the 486DX4 running at 100MHz which was 2.5 times faster than the fastest 040. By this time the Pentium had also been out for a year, with a 64-bit data bus and twice the throughput making it equivalent to a 130MHz 486.
The other reason 68k was hard to speed up was that the 68020 had more complex instructions that were difficult to deal with. Many of those instructions were hardly ever used in typical code, partly due to limited application and partly because compilers weren't sophisticated enough to make best use of them. In many cases they didn't make the code go much faster either.
None of this mattered to the user of course. All they cared about were the results, which were better with Intel (or so they were led to believe). Furthermore choosing 68k meant being locked out from all that lovely PC stuff that was everywhere. Your 68k machine needed a clear speed advantage to make up for that huge downside - and it didn't so... If Motorola hadn't got so carried away with the 68020 they might have done better. A less sophisticated ISA would be easier to implement and easier to speed up, putting a faster cheaper 68k CPU into our hands earlier. Motorola eventually realized this and started stripping stuff out of it, but by that time it was far too late for the desktop market. They had to go RISC because they couldn't get the performance their customers wanted with 68k. Not politics, just market forces.
|
| Status: Offline |
| | bhabbott
|  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 3:08:36
| | [ #52 ] |
| |
 |
Cult Member  |
Joined: 6-Jun-2018 Posts: 509
From: Aotearoa | | |
|
| Getting back on topic, I would like to see more 'period accurate' hardware that enhances the retro experience, with a focus on DIY like I was doing back in the day. No Raspberry Pis, Arduinos, fpgas or cplds, just good old TTL, GALs, RAM/ROM and other generic parts that were available back in the day which can still be obtained, in circuits that the average hobbyist can understand, build and and debug with period tools. This year I hope to produce at least one of the following:-
- OPL3 / AY sound card attached to clockport or parallel port.
- 16 channel logic analyzer on Zorro or PCMCIA.
- PCMCIA port for Zorro.
- ISA bus expansion for Zorro or PCMCIA.
I also want FastRAM and IDE for the A500, and FastRAM for the A1200. Existing products may do the job but it would be nice to see more options there, including DIY.
I have a few faster 68k CPUs that I want to use too. Not too fast though, 14 or 28 MHz would be fine. None of the current projects tick all of my boxes, so...
Finally I am interested in ways that OCS could be enhanced for eg. chunky pixels, with relatively simple circuits that might have been possible to produce back in the day.
Last edited by bhabbott on 07-Feb-2025 at 03:47 AM.
|
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 4:27:23
| | [ #53 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
News flash. Amiga wannabe hardware uses embedded CPU cores. X1000, X5000, A1222, Sam440/460, Efika PPC, THEA500 Mini and the A600GS all use embedded SoCs. The RPi uses embedded SoCs too although prices are low enough that about half of their sales are into the embedded market which improves economies of scale. There is nothing wrong with using embedded cores and embedded in-order cores for the low end market like RPi hardware. Choose the hardware wisely and stay away from compromised for embedded use hardware like the A1222 SoC without a FPU and the Cortex-A53 with a 3 cycle load-to-use latency when JIT compilation produces unscheduled Cortex-A53 code.
|
Efika's PPC CPU core is a former desktop PowerPC core since it's a descendant of PowerPC 603e (e.g. Apple Mac Gen 2) and PowerQUICC II. Efika's main issue is release timing and relative desktop competition.
It's no different when AMD reallocates older GoFlo 14/12nm fabricated Zen 1.x mobile APUs for embedded markets. AMD's CEO Lisa Su is a former IBM Semiconductor executive and a primary interface between IBM Semiconductor and Sony.
AMD's focus on 3D game CPUs are the combination of ex-IBM CELL executive Lisa Su and AMD''s history with 3DNow and K8 Athlon FX golden era (before Intel Core 2).
IBM Semiconductor has a history with game consoles starting from ex-Amiga engineers 3DO M2 design. It's unfortunate that IBM's Cyrix partnership wasn't good since Cyrix 6x86 FPU wasn't good while IBM PowerPC FPU design is good.
Microsoft later purchased Samsung's 3DO M3 group which opened IBM PPC option e.g. Xbox 360.
PPC was pushed out from the desktop by X86, not by 68K/Cold Fire.
IBM still competes in the server market against X86-64 and ARM Neoverse (based on Cortex X series).
There's no bad design, but there's bad pricing.
Quote:
Despite the weak RISC-V ISA handicap, the in-order 7-series CPU cores were already matching the OoO Cortex-A57 cores (Nintendo Switch) but five 7-series cores is likely smaller than one OoO Cortex-A57 core (the SiFive JH71110 SoC has 4xU7 and 1xS7 cores). It is not just OoO PPC CPU cores which are becoming obsolete on old silicon but older ARM OoO cores on old silicon too. It is really bad when much smaller and cheaper in-order cores approach the performance of and can replace big expensive OoO cores.
|
https://www.phoronix.com/review/visionfive2-riscv-benchmarks/4 StarFive VisionFive 2 with JH7110 SoC's U74 quad core vs Raspberry Pi 400 Cortex A72 quad core vs Orange Pi 5 Cortex A76 quad-core and A55 quad-core
Coremark 1.0 (iteration per second) Orange Pi 5 = 85,500.31 Raspberry Pi 400 = 39,918.96 VisionFive 2 = 20,188.74
Himeno Benchmark (MFLOPS, Poisson Pressure Solver) Orange Pi 5 = 2304.06 Raspberry Pi 400 = 796.49 VisionFive 2 = 121.01
SiFive U74 is showing floating point performance issue.
BRL-CAD 7.34, VGR performance metric Orange Pi 5 = 34,952 Raspberry Pi 400 =14,400 VisionFive 2 = 4,748
SiFive U74 inferior CAD performance.
Dolfyn 0/527, compulational fluid dynamics (lower is better) Orange Pi 5 = 34.55 Raspberry Pi 400 = 89.58 VisionFive 2 = 308.14
WebP Image Encode 1.2.4 (Quality 100, highest compression, more is better) Orange Pi 5 = 1.85 Raspberry Pi 400 = 1.1 VisionFive 2 =0.44
Timed FFmpeg Compilation 6.0 (less is better) Orange Pi 5 = 251.57 Raspberry Pi 400 = 852.91 VisionFive 2 = 1429.79
Mobile Neural Network 2.1 (less is better, model mobilenetV3) Orange Pi 5 = 70.80 Raspberry Pi 400 =79.82 VisionFive 2 = 549.01
The quad-core 1.5GHz VisionFive 2 RISC-V SBC tended to be multiple times slower than the quad-core Raspberry Pi 4 (400). Raspberry Pi 4 was replaced by Raspberry Pi 5. Quad-core Raspberry Pi 4 murdered VisionFive 2 RISC-V with JH7110's SiFive U74 quad core.
PS; StarFive Technology has received investments from the China Internet Investment Fund, a CPC state-backed fund.
https://www.eembc.org/viewer/?benchmark_seq=13658 Raspberry Pi 5 Model B (quad-core Cortex A76) CoreMark score = 72,059.09 CoreMark/Mhz = 30.020
Large boost from RPi's ARM Cortex A76 quad core relative to Orange Pi 5's Cortex A76 quad-core and A55 quad-core.
https://www.eembc.org/viewer/?benchmark_seq=2757 AMD Ryzen 1700X CoreMark score = 309,792 CoreMark/Mhz = 81.524
https://www.eembc.org/viewer/?benchmark_seq=13604 AMD Ryzen 9 7940HS mobile CoreMark score = 486,371 CoreMark/Mhz = 121.59
Phoronix Linux camp removes CCP propaganda bullshit.
------------ Note that StarFive Technology (China) is a different entity from SiFive, Inc (USA).
https://www.starfivetech.com/en/site/soc StarFive Technology removes SiFive name from U74 core.
Quote:
The 68060 was a high end high margin embedded market CPU. The successful desktop Pentium could not match the 68000 and perhaps 68020 volumes either.
|
Wrong.
https://archive.computerhistory.org/resources/access/text/2013/04/102723335-05-01-acc.pdf For Dec 1996 DataQuest,
Page 40 of 520 Pentium murdered 68020.
Page 44 of 520 Supply base for 32bit Microprocessors 1995 16bit X86 MPU (15.6 percent) = 12,050 (NEC dominates this market, LOL) 32bit X86 MPU (38.2 percent) = 70,175
68000 MPU (29.7 percent) = 54,446 PowerPC (1.8 percent) = 3,371
MIPS MPU (2.5 percent) = 4,678
Quote:
The in-order high performance desktop P5 Pentium was at least 6 different designs that increased from 3.1 million to 4.5 million transistors too. The 68060 was a minimalist in-order high end embedded CPU design that balanced power and area with performance yet it still competed in performance with the most comparable P54C Pentium and destroyed the P54C in PPA important for embedded use.
|
I'll bite, that's propaganda bullshit.
Quote:
Motorola throwing out their beautiful 68k baby for a fat and ugly PPC baby for political instead of technical reasons is reprehensible but Trevor did the same thing.
|
"Don't disturb when your enemy makes a mistake".
Motorola ground zeroed 6809 (with 16bit math ALU)'s customer desktop platforms with incompatible 68000 (16bit ALU with 32bit programming model). Motorola's history with trashing customer's software investments is in Motorola's DNA.
Intel 80386 and IA-32 protected customer's desktop software investments.
Last edited by Hammer on 03-Feb-2025 at 05:40 AM. Last edited by Hammer on 03-Feb-2025 at 05:26 AM. Last edited by Hammer on 03-Feb-2025 at 05:18 AM. Last edited by Hammer on 03-Feb-2025 at 05:15 AM. Last edited by Hammer on 03-Feb-2025 at 04:41 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | matthey
|  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 5:38:13
| | [ #54 ] |
| |
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2460
From: Kansas | | |
|
| bhabbott Quote:
Political? No. The reason they dropped 68k was simply that other architectures were faster, and Motorola was struggling to keep up. It wasn't Motorola who made the decision to switch, it was their customers who weren't getting a powerful enough CPU. Sun developed SPARC because 68k wasn't fast enough. Apple turned to PPC for the same reason.
|
IBM sold Apple on PPC and Motorola went along as a 2nd supplier which Apple wanted and the 68k did not have for high end CPUs after the Hitachi fallout. IBM and Motorola developed CPUs together saving develop costs as well. Motorola chose the easy path but the AIM Alliance was bad for Motorola and Apple. IBM fared better but they proposed it. Apple abandoned AIM out of frustration that the shallow pipeline PPC CPUs could not be clocked up and then with the expensive and disappointing performance PPC G5 developed by IBM. The x86 CPUs had moved to deeper pipelines allowing them to be clocked up more. The 68k had the advantage with early superscalar CISC CPUs as the 68060 had an 8-stage pipeline to the Pentium P5 5-stage pipeline. More stages allows higher clock speeds and provides more performance because of instruction level parallelism but uses more transistors and power. The Pentium P54C already used 32% more transistors and 73% more power with a 5-stage pipeline compared to the 68060 with an 8-stage though (both 3.3V and 500nm). Motorola announced and were testing a 68060@66MHz but then never advertised more than a 68060@50MHz. An 8-stage pipeline with a 50MHz max would have been incompetent.
CPU max clock rating @ ~500nm process size with pipeline stages and MHz/stage ARM710@40MHz 3-stage 13MHz/stage PPC601+@120MHz 4-stage 30MHz/stage PPC603@160MHz 4-stage 40MHz/stage Pentium P54C@120MHz 5-stage 24MHz/stage PPC604@180MHz 6-stage 30MHz/stage X704@~500MHz 6-stage 83MHz/stage HP PA-8000@180MHz 7-stage 26MHz/stage Alpha 21064@300MHz 7-stage 43MHz/stage MIPS R4400@200MHz 8-stage 25MHz/stage 68060@50MHz 8-stage 6MHz/stage Average MHz/stage: 32MHz/stage

Do you understand how pipelines work and why more stages allows higher clock speeds?
bhabbott Quote:
From the user's perspective the ISA was irrelevant. Compilers took care of differences so developers didn't care, and only the results mattered. So when the results showed x86 machines performing better, everybody wanted them (even more than they did anyway because PCs were the industry standard). With Motorola not keeping up, computer makers who were using 68k turned to RISC because it was widely recognized as the way to get more speed with less effort. By 1993 even Commodore intended to go RISC.
|
The 68040 fell behind but it had more to do with being very late than having poor performance. It should have been designed as a 3.3V CPU from the start and it had other issues. The 68040 delays made the 68060 late too and the desktop customers AIMed for PPC even though the 68060 was a great design with a performance efficiency on par or better than the PPC601, PPC603 and PPC603e and with a deeper pipeline that could be clocked up giving the 68060 more performance (the 8-stage 68060 could have been clocked up more than the 5-stage Pentium as well). Motorola AIMed to transition 68k customers to PPC including both desktop and embedded customers to improve economies of scale but they ignored organic development, ignored technical analysis and chose PPC for political reasons, resulting in the loss of both markets. The 68k continued to be king of the embedded market for about another decade before the old silicon was replaced by SuperH and finally ARM more than the fat and ugly PPC Motorola tried to force on embedded customers. Motorola dropped the 68k but Hitachi's SuperH was copied from the 68000 and licensed to ARM for Thumb.
bhabbott Quote:
Part of the reason 68k wasn't faster is that Motorola wasn't as good at making chips as Intel. The first batch of 68020's had practically zero yield. The 68030 was better but it was beaten to market by the 80386. When they finally got the power hungry 68040 out a year after the 80486 and never got it to go faster than 40MHz, it was obvious that they were never going to keep up. By 1994 Intel had the 486DX4 running at 100MHz which was 2.5 times faster than the fastest 040. By this time the Pentium had also been out for a year, with a 64-bit data bus and twice the throughput making it equivalent to a 130MHz 486.
|
Motorola fab tech was far behind Intel when the 68000 was released but did it stop the 68000 from dominating the 8086, 80186 and 80286? Operation Crush lies were the best Intel could do in response for how many generations of Intel CPUs? The 80386 may be more comparable to a 68020 than 68030 as they were both the first 32-bit CPUs with large flat address spaces. The 68020 had an instruction cache which the 80386 did not. Both the 80386 and 68030 were the first CPUs in their lines to have MMUs, the 68030 additionally had instruction and data caches with cache bursting while the 80386 had no caches. Motorola did not spend to move older designs to newer fab processes to clock them up because more of their sales were into the lower margin embedded market instead of high margin desktop market. Motorola had problems with the 68040 and it was a sub par design which was recognized and fixed with the 68060 design, only to have it ignored with the political decision to move to PPC. Intel tried to move away from 808x/x86 at least twice as well but they did not abandon development and never looked back.
bhabbott Quote:
The other reason 68k was hard to speed up was that the 68020 had more complex instructions that were difficult to deal with. Many of those instructions were hardly ever used in typical code, partly due to limited application and partly because compilers weren't sophisticated enough to make best use of them. In many cases they didn't make the code go much faster either.
|
Complete BS. The 68060 handles the most complex 68k addressing modes with ease and without microcode. What x86(-64) CPU has ever not used microcode?
bhabbott Quote:
None of this mattered to the user of course. All they cared about were the results, which were better with Intel (or so they were led to believe). Furthermore choosing 68k meant being locked out from all that lovely PC stuff that was everywhere. Your 68k machine needed a clear speed advantage to make up for that huge downside - and it didn't so...
|
Your inevitable PC theory again. Commodore should have come out ahead of Apple to become the survivor but upper management botched it. The 68k Amiga could have even come out on top of the PC. The 68k and Amiga were years ahead of the 808x PC but failed to upgrade the technology fast enough.
bhabbott Quote:
If Motorola hadn't got so carried away with the 68020 they might have done better. A less sophisticated ISA would be easier to implement and easier to speed up, putting a faster cheaper 68k CPU into our hands earlier. Motorola eventually realized this and started stripping stuff out of it, but by that time it was far too late for the desktop market. They had to go RISC because they couldn't get the performance their customers wanted with 68k. Not politics, just market forces.
|
The 68000 ISA is relatively simple and a 68000 CPU core could be clocked to 5+ GHz. A superpipelined design is in many ways not as efficient and more difficult to program due to stalls than a superscalar medium depth pipeline with a moderate clock speed that is designed to avoid stalls. The more powerful but complex 68020 ISA limits the clock speed some compared to the 68000 ISA but it is worth it for the Amiga considering how much 68020 code there is. More powerful at a lower clock speed is generally better than high clocked but weak RISC designs.
Last edited by matthey on 03-Feb-2025 at 05:46 AM.
|
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 6:55:07
| | [ #55 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @bhabbott
Quote:
From the user's perspective the ISA was irrelevant. Compilers took care of differences so developers didn't care, and only the results mattered. So when the results showed x86 machines performing better, everybody wanted them (even more than they did anyway because PCs were the industry standard). With Motorola not keeping up, computer makers who were using 68k turned to RISC because it was widely recognized as the way to get more speed with less effort. By 1993 even Commodore intended to go RISC.
|
From Commodore - The Final Years
In December 1987, Bob Welland, a VLSI chip designer named James Redfield, and Hedley Davis began investigating the next generation chipset. The new chipset would not be hardware compatible with the previous Amiga chipset, although programs that used the Amiga software API would theoretically still work. Bob Welland wanted to move away from the Motorola 68000 family and instead use a RISC processor designed by Commodore, or at the very least, a RISC processor from another company. Then, after Welland left, the next generation chipset plans sat in limbo until around June 1988, when Hedley Davis began discussing them again with other engineers. “Occasionally we’d have meetings and we’d hash out all the details between the systems people and software people and chip designers,” says Dave Haynie.
In 1988, Amiga 500 co-designer Bob Welland argued for RISC, he was ignored and he left Commodore and joined Apple's RISC ARM project e.g. Newton PDA.
From Commodore - The Final Years
RISC Ever since the late eighties, when A500 co-designer Bob Welland was still working for Commodore, the company had been investigating RISC processor technology, often in relation to developing its Unix machines. (skip) Commodore’s engineers wanted to design computers around RISC. Using RISC chips, the processor could theoretically operate faster with the most common opcodes in an instruction set. It would be up to the programmers to use this reduced instruction set to create more complex instructions, in software. (skip) Commodore’s Ted Lenthe began looking into RISC chips with the AAA chipset back in the summer of 1989, specifically the Motorola 88000. But the engineers always balked at concrete plans due to the incompatibility problems a new processor would cause. For his part, Ed Hepler favored creating his own RISC CPU on the basis that Commodore could produce it much cheaper than buying the 88000 from Motorola.
In late 1990, Hepler began writing a formal design for a new chipset dubbed Hombre, which would use a RISC processor.
However, department heads Ted Lenthe and Ned McCook tried their best to keep him focused on AAA.
(skip)
By 1993, Ed Hepler began favoring the PA-RISC chip (Precision Architecture) from Hewlett-Packard, the same company that fabricated many of Amiga’s custom chips. “What we were looking for was something that we could integrate right into our design,” says Hepler, who had temporarily given up his dream of designing his own CPU. “Obviously we weren't going to build a 68000 chip at that point.”
The PA-RISC chip allowed Commodore’s semiconductor engineers to implement a graphics chip on the same chip as the PA-RISC CPU core. “You could buy cores from some folks. Most of the time the cores were rectangular in shape,” explains Hepler. “If you put the core down on a chip, all you had left was a periphery around the edge where you could put your own logic—an L shaped thing was all that was left because typically chips are made to be rectangular and you want to make them as close to square as possible because they're stronger that way.
-------------- During 1991, Commodore's multimedia group (Jeff Porter) selected RISC-based custom MIPS-X SoC during CDTV-CR's development.
For FMV MPEG1, CDTV-CR had MIPS-X based SoC bundled in.
From Commodore - The Final Years
the final cost of the CDTV-CR came in higher than Mehdi Ali had anticipated. Porter had hoped for under $300 as his low-ball estimate, but the final cost was $351.19. “What ended up happening is after it gets built, it's a really nice machine and it's really slick and they've also incorporated the potential for doing MPEG decoding, so it can play movies and that kind of thing,” says Carl Sassenrath. “And it ends up not meeting the cost estimates. So it was a little more expensive.”
Commodore was close to bundling 40Mhz custom MIPS-X SoC with CDTV-CR.
Commodore FMV module has separate 24bit video and 16bit audio DACs and 512 KB local memory independent of AGA Amiga which is less cost-efficient when compared to a fully integrated East Asian PS1 version with VCD capability.
If Amiga had a 24-bit chunky pixel display, it wouldn't need two separate video DAC chips.
CDTV-CR's MPEG1 FMV feature was recycled for CD32's FMV module.
_________________ 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 7:34:28
| | [ #56 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @matthey
Quote:
The 68040 fell behind but it had more to do with being very late than having poor performance. It should have been designed as a 3.3V CPU from the start and it had other issues. The 68040 delays made the 68060 late too and the desktop customers AIMed for PPC even though the 68060 was a great design with a performance efficiency on par or better than the PPC601, PPC603 and PPC603e and with a deeper pipeline that could be clocked up giving the 68060 more performance (the 8-stage 68060 could have been clocked up more than the 5-stage Pentium as well). |
P5 Pentium's floating-point pipeline consists of eight stages.
P55 Pentium MMX FPU has an extra pipeline stage for higher clock speed i.e. FPU has 9 stage pipeline. Pentium MMX FPU has 1.0 IPC improvement.
68060 rev6 overclocking potential doesn't reach Pentium counterpart.
The highest clock speed Pentium MMX "Tillamook" is the mobile variant with 300Mhz.
Your pipeline stage vs clock speed argument is flawed since you didn't factor the integrated FPU.
Clock speed attainment is based on the slowest part.
68060 FPU would need a redesign since it's not properly pipelined and 1 IPC FPU improvement would be desirable.
Circuit layout also influences clock speed attainment e.g. Zen 4 and Zen 4C have the same pipeline stage count with different circuit layouts and clock speed potentials.
DEC Alpha 21064 (starting with 0.75 microns, reached 200Mhz). Integer: 7 stage, Floating point: 10 stage,
PowerPC 601 (starting with 0.6 microns, reaching 80 Mhz). Integer: 4 stage, Floating point: 6 stage,
PowerPC 604 (starting with 0.5 microns, reaching 180 Mhz). Integer: 6 stage, Floating point: 8 stage.
HP PA-7100LC (starting with 0.75 microns, reaching 100Mhz).
CISC CPU designs are inherently complex and they are harder to reach at high clock speed which is overcome by Intel's large R&D budget with design skills assimilated from DEC Alpha.
AMD's CPU R&D is significantly stacked with ex-DEC Alpha engineers via NexGen purchase. AMD's in-house K5 reached a clock speed wall which led to AMD's buying NexGen for 2nd generation RISC86-based 686 project renamed into K6.
in 1986, NexGen Inc. was co-funded by Compaq, ASCII Corporation (precursor to Microsoft Japan / Microsoft Kabushiki Kaisha) and venture capitalist Kleiner Perkins. The primary R&D focus is the RISC X86 project. Microsoft Japan's ex-ASCII Corporation executives have hedged their bets and created a backup plan to Intel's P5 and P6 plans.
For proven high clock speed at a given process tech, DEC Alpha engineers are superior to Motorola engineers.
My point, people's engineering skills matter, not just the pipeline stage count.
References https://en.wikipedia.org/wiki/ASCII_Corporation https://en.wikipedia.org/wiki/Microsoft_Japan https://en.wikipedia.org/wiki/NexGen https://www.eetimes.com/fifty-years-of-amd-a-tech-leader/
The first clean-slate x86 processor by AMD was the AMD-K5. Using RISC design concepts first developed for the 29K team, lead architect Mike Johnson created a design that took x86 instructions (a complex instruction set also known as CISC) and broke them down to groups of RISC instructions (sometimes called micro-operations). Intel’s PentiumPro also followed a parallel design path.
To keep pace with Intel, AMD needed a second design team and a new CPU design. Jerry Sanders found the x86 processor and the design team the company needed in a startup named Nexgen. Sanders took a gamble by buying Nexgen and porting their next-generation design to AMD’s semiconductor process. That product became the AMD-K6 and was followed by the AMD-K6-2, with a new set of instructions for PC games called AMD-3DNow!
The next breakthrough for AMD PC processors came with the Athlon processor (also known as K7). AMD had hired some leading engineers from the DEC Alpha microprocessor team, by Kevin Krewell, an ex-employee of AMD of 10 years, currently working at Broadcom, the silicon that powers Raspberry Pi that is used in Amiga's PiStorm.
Again, people's engineering skills matter.
Quote:
Complete BS. The 68060 handles the most complex 68k addressing modes with ease and without microcode. What x86(-64) CPU has ever not used microcode?
|
Intel has industry leading C++ complier and MSVC+ is second best.
For X86-64, microcode is mostly use for patching CPU bugs and rarely used instructions. Upgradeable microcode firmware was introduced after Pentium FDIV bug.
X86-64 doesn't use 68060 style end-user support package that doesn't survive kick the OS.
You can't use 68060 on Macintosh without hack-in MacROM with 68060's support package.
68060 running unsupported instruction via the trap method severely slows down the CPU. 68060 has bugs that CPU libraries have to account and it's not OS independent.
Emu68 self reports as 68040 that emulates the entire 68K instruction set minus work in progress 68K MMU. As a hypervisor, Emu68 survives the "kick the OS" Amiga games.
Quote:
Motorola fab tech was far behind Intel when the was released but did it stop the 68000 from dominating the 8086, 80186 and 80286?
|
Facts: 1. Intel had 8087 and 80287 to handle large datatypes such as INT32, INT64, FP32, FP64 and FP80. This integer and floating point processing capability was inherited by Pentium FPU.
The "killer app with text UI" Lotus 123 2.0 supports X87 FPU.
2. 68000's largest data type is INT32 and switching to two instructions approach (add.l for low, addx.l for high) for processing INT64. FP is software emulated by 68000's ISA.
3. Intel provided 8088 for IBM PC's requirements while 68008 is late. IBM's original PC includes an FPU socket.
Quote:
Operation Crush lies were the best Intel could do in response for how many generations of Intel CPUs? The 80386 may be more comparable to a 68020 than 68030 as they were both the first 32-bit CPUs with large flat address spaces
|
80386 has integrated MMU with TLB cache i.e. it had standard hardware features important for Unix (Xenix support for Compaq's 386AT clone standard) and Linux foundation with interoperability. Compaq allowed 386AT standards to be cloned.
68K Unix has vendor locking with vendor custom MMU which lacks Unix OS interoperability. Linux killed closed-source Unix.
Motorola was late with 68551 and 68030 integrated MMU, hence Commodore wasted two MMU R&D for 68000 and 68020.
68K's platform fragmentation was carried over to PPC. During 68K's desktop golden era, no major 68K system integrators from Apple, Commodore, and Atari allowed their platform to be cloned.
Quote:
. The 68020 had an instruction cache which the 80386 did not. Both the 80386 and 68030 were the first CPUs in their lines to have MMUs, the 68030 additionally had instruction and data caches with cache bursting while the 80386 had no caches.
|
80386 MMU has a TLB cache and supported external cache. My 386DX motherboard had an external 64 KB cache.
At 16 Mhz to 25 Mhz, 68020 and 68030 don't have MUL math processing intensity with effective 7.1 Mhz (140 ns readd-write cycle) FPM DRAM. Hint: refer to custom MIPS-X CL450's FPM DRAM vs compute capability. 68030's L1 data cache starts to play a role with 40 Mhz to 50 Mhz with FPM DRAM.
For integer processing, Intel countered the RISC threat with 486's 1989 release with tight system integration 1989 release with Compaq at the expense of foolish PC cloners like Commodore (as a semi-conductor competitor to Intel)'s excessive 386 inventory. Intel rewarded loyalty.
During 1986, Motorola lost SGI due to MIPS R2000's RISC advantage. 68882 wasn't designed with RISC concepts. MIPS R2000 has 8 to 10 MIPS and 0.9 MFLOPS at 12.5Mhz that is geared towards math processing e.g. 1987 SGI IRIS 4D and 1988 DECstation 2100 workstations.
Similar RISC technology appeared with Sun's first SPARC microprocessor, Hewlett Packard's first PA-RISC microprocessor, and the first Acorn RISC Machine (ARM) evaluation kits shipping to developers. SGI, DEC, SUN, and HP are former *nix 68K workstation vendors.
Apple backed two RISC CPU families i.e. PowerPC and ARM.
Within SUN's graphics division in the late 1980s, it developed a GPU skill set that led to the co-founding of NVIDIA. SGI spawned many rebel daughter companies that served as a basis for ArtX (for Nintendo, purchased by ATI) and 3DFX (for PC 3D games, purchased by NVDIA), and influenced other vendors towards OpenGL, Sony PlayStation (triangle 3D model, and MIPS R3000A CPU selection), 3DO M2 (switched to triangle 3D model with two strong IBM PPC 602 FPUs) and 'etc'. 3DO M3 project was led by a former SGI engineer.
MS Windows NT's SMP, metal 3D GUI design, and Direct3D road map is SGI and DEC VMX.
Intel and Compaq ganged together to buy out DEC (Alpha RISC CPU, PC clone business). Intel's Pentium road map was DEC Alpha including the stolen DEC Alpha's patents. Intel MMX SIMD IP with VLIW-RISC i860 (1989 release) that was refitted into Pentium MMX and Pentium II.
Since Commodore had double rate processing IP, AMD hired C65's CPU engineer in 1991 and later joined the K7 Athlon project team. AMD's road map is DEC Alpha. With US government funding, US universities learned from ARM after the MIPS's defeat and created RISC-V. Common US RISC-V microcontroller is a national security issue.
Quote:
Motorola did not spend to move older designs to newer fab processes to clock them up because more of their sales were into the lower margin embedded market instead of high margin desktop market. Motorola had problems with the 68040 and it was a sub par design which was recognized and fixed with the 68060 design, only to have it ignored with the political decision to move to PPC. Intel tried to move away from 808x/x86 at least twice as well but they did not abandon development and never looked back.
|
IBM PC's second source insurance for X86 AMD worked against Intel's IA-64 Itanium attempt.
iAPX 432, i860 (RISC-VLIW), and Itanium (from HP PA-WIDE project) are Intel's three attempts to move away from X86.
Intel X86S initiative is dead since AMD didn't support it and was replaced by the x86 Ecosystem Advisory Group. https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end. That's Intel's 4th attempt to kill off 16bit X86.
Last edited by Hammer on 04-Feb-2025 at 04:21 AM. Last edited by Hammer on 04-Feb-2025 at 04:17 AM. Last edited by Hammer on 04-Feb-2025 at 04:00 AM. Last edited by Hammer on 03-Feb-2025 at 10:55 PM. Last edited by Hammer on 03-Feb-2025 at 10:44 PM.
_________________ 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | kolla
|  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 16:10:37
| | [ #57 ] |
| |
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3359
From: Trondheim, Norway | | |
|
| Why must just about every thread end up like this? :) _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
| Status: Offline |
| | Hammer
 |  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 21:20:09
| | [ #58 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6173
From: Australia | | |
|
| @kolla
I will counter Matthey's arguments. I purchased 68060 Rev1 during the COVID-19 lockdown to investigate the hype with 68060. The first bump on the road was 68060's narrow L1 cache fetch.
Instruction usage needs to be carefully crafted with two 2-byte instructions. This bottleneck was mitigated in AC68080 V2.
6-byte instruction is slower on 68060 when compared to 68040.
SysInfo benchmark easily trips over 68060's narrow L1 cache fetch design. 68060 seems to be intentionally crippled.
Cold Fire V has a 64-bit external bus which is very late for 68060.
68060 and PPC601 could have shared 64bit 60x 88000 bus which simplifies the switching between 68060 and PPC601. Motorola wasn't paranoid enough to support 68060 and PPC601 on the same desktop 64bit 60x platform. Motorola has a near 100% trust in IBM PPC adventure.
Last edited by Hammer on 03-Feb-2025 at 11:23 PM.
_________________ 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 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | Karlos
|  |
Re: What Amiga products would you like to see? Posted on 3-Feb-2025 21:54:46
| | [ #59 ] |
| |
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| | Status: Offline |
| | AmigaMac
|  |
Re: What Amiga products would you like to see? Posted on 5-Feb-2025 14:01:08
| | [ #60 ] |
| |
 |
Super Member  |
Joined: 26-Oct-2002 Posts: 1117
From: 3rd Rock from the Sun! | | |
|
| @Hammer
Didn’t Apple and IBM fool Motorola into giving up on significant R&D on the 68k and join the PowerPC venture forming the AIM alliance? _________________
|
| Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|