@Hammer

Quote:

Hammer wrote: Again, W65CB32 wasn't ready for the Amiga Lorraine, Apple Lisa, Atari ST, Sega Mega Drive and etc. Commodore's in-house 16-bit CPU selection was the Z8000 CPU for the Commodore 900.

According to Robert Russell, co-designer of the C900, they originally wanted to use a 68000 but "We were still butting heads with Motorola, so Motorola wasn't really an option". Apparently there still were ongoing lawsuits related the 6501 etc. But the C900 would have been a stink design no matter which CPU they put in it.

@bhabbott

Quote:

bhabbott wrote: @Hammer Quote: Hammer wrote: Again, W65CB32 wasn't ready for the Amiga Lorraine, Apple Lisa, Atari ST, Sega Mega Drive and etc. Commodore's in-house 16-bit CPU selection was the Z8000 CPU for the Commodore 900. According to Robert Russell, co-designer of the C900, they originally wanted to use a 68000 but "We were still butting heads with Motorola, so Motorola wasn't really an option". Apparently there still were ongoing lawsuits related the 6501 etc. But the C900 would have been a stink design no matter which CPU they put in it.

https://www-c64--wiki-de.translate.goog/wiki/Robert_Russell?_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc

Robert Russell advised Commodore management to go ahead with the Amiga.

Thomas Rattigan terminated Robert Russell's employment with Commodore.

Last edited by Hammer on 21-May-2024 at 08:39 AM.
Last edited by Hammer on 21-May-2024 at 08:36 AM.

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

Hammer Quote:

Useless benchmark. Try wolf 3D.

Sieve is a simple benchmark but 8 bit computers have trouble compiling benchmarks. I found the results on the Wiki for the 6809 which I was talking about.

https://en.wikipedia.org/wiki/Motorola_6809#Market_acceptance

Hammer Quote:

https://www.youtube.com/watch?v=MqiEQtzGk-Q Benchmarking Z3660 with ARM Cortex A9 @ 766 Mhz (via Z-turn Board V2 with an AMD Zynq 7020) emulating 68K. This ARM Cortex A9 implementation has a 32 KB L1 cache and a shared 512 KB L2 cache. https://docs.amd.com/v/u/en-US/ds190-Zynq-7000-Overview A4000's AMD Zynq 7020's ARM Cortex A9 @ 766 Mhz's 68k emulation reached the following: SysSpeed in 1550 MIPS, 139 MFLOPS. SysInfo is 138 MIPS, (problem with SysInfo's FPU detection)

It looks like OoO helps the emulation as I expected. FPU performance is weak which is probably why Quake fps is only about equivalent to a 68060@150MHz. The weak graphics performance may have played a role as well. 3D hardware allows a real 68060 to outperform emulation even with higher resolution and more colors. A real 68060@1GHz would be well over 100fps even using software.

Hammer Quote:

A500's PiStorm Emu68 with RPi 3A+ ARM Cortex A53 @ 1.4 Ghz's 68k emulation reached the following: SysSpeed is 499 MIPS and 269 MFLOPS. SysInfo is 914 MIPS and 868 MFLOPS.

The in-order Cortex-A53 falls on its face without instruction scheduling due to load-to-use stalls as I predicted. The AArch64 standard FPU is an upgrade from the Cortex-A9. Maybe the Emu68 FPU emulation is better but a standard FPU makes support easier.

Hammer Quote:

A1200's PiStorm32 Emu68 with RPi 4B+ ARM Cortex A72 @ 1.8 Ghz's 68k emulation reached the following: SysSpeed is 3446 MIPS and 3264 MFLOPS. SysInfo is 1973 MIPS and 2014 MFLOPS.

Newer OoO ARM cores have improved a lot but they are much larger and hotter. Even a 68060@2GHz would have trouble beating the SysSpeed numbers above but it would allow for a better GPU on a small SBC.

Hammer Quote:

Significant overclock works for RPi 3A+ and 4B without triggering warranty void status. Each benchmark has biases in different parts of the CPU instruction set, CPU cache and memory bus. For Amiga's context, it's games like Quake benchmarks. Z3660's RTG and FP emulation still needs work.

Some of the benchmark numbers seem out of place. JIT can skip code that doesn't do anything like some benchmarks. I trust the Quake benchmarks more than MIPS and MFLOPS benchmarks, especially the SysInfo ones.

Hammer Quote:

SiFive U74 is useless for the Amiga. When Google dropped RISC-V support from Android, RISC-V's "application processor" chance also dropped. I'm not interest in pure "embedded CPUs" since the Amiga is a desktop computer.

Android didn't really support RISC-V hardware as there was no RISC-V hardware for Android yet.

SiFive U74 cores are fine for application processors. They are roughly equivalent to a Cortex-A55 but likely smaller where size matters. The in-order ARM application cores like the Cortex-A53 and Cortex-A55 likely outnumber any OoO ARM cores at least 10,000 to 1. The Cortex-A53 is likely the most popular 64 bit CPU core ever and not just from ARM.

SiFive U74 cores were underpowered for low end desktop hardware like the HiFive Unmatched with PCIe and no integrated GPU at over $600 USD. It had newer specs than AmigaNOne hardware as far as memory and PCIe and was cheaper but wasn't competitive on the desktop either. The SiFive U74 core was perfect for a small SBC like the $45-$100 USD StarFive VisionFive 2 with integrated Imagination GPU. The CPU performance is between a RPi 3 and RPi 4 but the GPU is likely better than any RPi GPU. There is a Quake II video playing at the following link.

https://www.kickstarter.com/projects/starfive/visionfive-2

It blows the doors off the A1222+ at a fraction of the price. There is still no SIMD unit but at least there is a standard FPU which provides more than the 3-4fps of the A1222+.

SiFive is also working on an OoO core in partnership with Intel.

https://www.hackster.io/news/sifive-s-hifive-pro-p550-developed-in-partnership-with-intel-aims-to-be-the-fastest-risc-v-sbc-yet-5789a4734bcc

Perhaps Intel is backing RISC-V and partnering with SiFive to counter ARM? Maybe Intel is not as threatened by the weaker RISC-V ISA? With Intel partnering with SiFive and ARM partnering with the RPI Foundation, where does that leave A-Eon and AmigaNOne hardware with hobby market performance and specs but high end desktop market prices?

Last edited by matthey on 21-May-2024 at 04:11 PM.
Last edited by matthey on 21-May-2024 at 09:56 AM.

@Hammer

Quote:

Hammer wrote: @matthey Quote: Byte Sieve Useless benchmark. Try wolf 3D.

Wolfenstein 3D needs at least 528k of 'conventional' RAM to run in DOS. An 8 bit system might not need quite that much, but it's still well over the memory addressing capabilities of the 6502, Z80 and 6809. So your 'benchmark' is useless for over half the CPUs in matthey's list.

Officially it's useless for the 8086 too because Wolfenstein 3D needs a 286 CPU, but it has since been patched to work on 8086, so we can test it - and I did! I ran it on my Amstrad PC2086 which has an 8MHz 8086, 640k RAM and VGA graphics. The result - with window size set 4 steps down - was ~3.3 fps.

I also tried the recently released CGA version which is optimized for the 8088, and got ~5.5 fps at maximum windows size (which would be almost playable, if 4 colors didn't make it almost impossible to tell what you are looking at).

Not sure how to relate that to the 68000. I am not aware of Wolf3d any port that we could try. Dread gets about 10 fps on a stock A500, but that's a completely different program so it's not really comparable.

bhabbott Quote:

Not sure how to relate that to the 68000. I am not aware of Wolf3d any port that we could try. Dread gets about 10 fps on a stock A500, but that's a completely different program so it's not really comparable.

There is a pretty good AGA Amiga Wolfenstein port.

https://www.indieretronews.com/2022/03/spear-of-destiny-wolfenstein-3d-two.html

A 68000 Amiga port would need more optimizations and would still be slow but is likely possible as the following tech demo demonstrates.

Wolfenstein 3D Amiga 500 technical demo by britelite
https://www.youtube.com/watch?v=6qsY8tXRFh0

There is even a C64 version of Wolfenstein.

C64 - Wolfenstein 3D
https://www.youtube.com/watch?v=Pa9cC6HcgrE

6502@20MHz > 68000@8MHz

Last edited by matthey on 21-May-2024 at 10:26 AM.

@matthey

Quote:

matthey wrote: Sieve is a simple benchmark but 8 bit computers have trouble compiling benchmarks.

That's OK, because the Byte Sieve was designed to be a programming language benchmark, not a CPU benchmark. So if 8 bit computers have trouble compiling it efficiently that's part of the test!

One of the strengths of the 68000 over 8 bit CPUs like the 6502 and Z80 is that it was a better match to C's minimum 16 bit integer size, and the large number of registers with orthogonal operation also helped. The 68000's large flat memory map was an advantage too in real-world applications. The 8 bitters often struggled to make program size small enough to fit in their tiny memory, and machines with > 64k were dramatically slowed down by bank switching.

@bhabbott

Quote:

bhabbott wrote: Wolfenstein 3D needs at least 528k of 'conventional' RAM to run in DOS. An 8 bit system might not need quite that much, but it's still well over the memory addressing capabilities of the 6502, Z80 and 6809. So your 'benchmark' is useless for over half the CPUs in matthey's list.

Wrong.

https://youtu.be/acUH4lWe2NQ?t=738
Apple IIGS has Wolfenstein 3D port. This example has a 65C816 @ 8 Mhz CPU accelerator which replaced 2.8 MHz 65C816.

Last edited by Hammer on 21-May-2024 at 11:04 AM.

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

@matthey

Quote:

matthey wrote: There is a pretty good AGA Amiga Wolfenstein port. https://www.indieretronews.com/2022/03/spear-of-destiny-wolfenstein-3d-two.html A 68000 Amiga port would need more optimizations and would still be slow but is likely possible as the following tech demo demonstrates. Wolfenstein 3D Amiga 500 technical demo by britelite https://www.youtube.com/watch?v=6qsY8tXRFh0 There is even a C64 version of Wolfenstein. C64 - Wolfenstein 3D https://www.youtube.com/watch?v=Pa9cC6HcgrE 6502@20MHz > 68000@8MHz

https://www.youtube.com/watch?v=aL_ZXgTtlpU
BSzili's Wolfenstein 3D port is available for AGA and 64-color EHB.
This port runs the PC VGA and FM sound as Amiga PCM.

Britelite's tech demo is not the full Wolfenstein 3D port.

Grind / Dread is better optimized for the A500 and limiting render to 16 color 4-bit planes.

https://youtu.be/jThOhgiIC8I?t=155
Wolfenstein 3D for stock Atari ST (68000 @ 8 Mhz). The 16-color artwork redraw was supplied by the same Wolfenstein 3D porting team for Apple IIGS.

C2P has a higher impact with slower CPUs and higher 8-bit planes.

Last edited by Hammer on 21-May-2024 at 11:57 AM.
Last edited by Hammer on 21-May-2024 at 11:52 AM.
Last edited by Hammer on 21-May-2024 at 11:51 AM.
Last edited by Hammer on 21-May-2024 at 11:48 AM.
Last edited by Hammer on 21-May-2024 at 11:30 AM.
Last edited by Hammer on 21-May-2024 at 11:20 AM.
Last edited by Hammer on 21-May-2024 at 11: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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Sieve is a simple benchmark but 8 bit computers have trouble compiling benchmarks. I found the results on the Wiki for the 6809 which I was talking about. https://en.wikipedia.org/wiki/Motorola_6809#Market_acceptance

That's a compiler benchmark issue.

Quote:

It looks like OoO helps the emulation as I expected. FPU performance is weak which is probably why Quake fps is only about equivalent to a 68060@150MHz.

You missed the point on Z3660's MYS-7Z020-V2's lower price vs 68060 Rev 6.

MYS-7Z020-V's AMD Zynq 7020 SoC includes FPGA and Z3660's MYS-7Z020-V2 combo includes RTG, AHI, Network, and 'etc' that is hosted by Linux.

Warp1260 (68060 rev 6 with RTG, AHI, WiFi, microSD, and ARM co-processor) has a crazy "Phase 5" price.

For big box A3000/A4000, Z3660 competes against A3660, BGF9060, and TF4060.

Open-source A3660 could be modified for PiStorm32-RPi 3A/4B since Z3660 itself is based on open-source A3660.

Doom benchmark doesn't use FPU.

Quote:

The weak graphics performance may have played a role as well. 3D hardware allows a real 68060 to outperform emulation even with higher resolution and more colors. A real 68060@1GHz would be well over 100fps even using software.

For FPU emulation, Z3660's 68K-to-ARM emulation is less mature when compared to PiStorm-Emu68.

https://www.phoronix.com/review/gentoo_arm_x32/3
ARM Cortex A9 @ 1Ghz beats Intel Atom N450 Pineview @ 1 Ghz on C-Ray.

https://www.youtube.com/watch?v=VjReLuIvyqQ
PiStorm32-Emu68 can use 3DFX Voodoo 3 PCI via Mediator PCI 1200 TX bus board. This would need a tower case conversion.

RPi CM4 has PCIe, hence a path towards PCie 3D acceleration. The problem is A1200's small case.

My point, soft 68K-on-ARM can use 3D acceleration when there are 3D drivers available.

There's no "68060 @ 1 GHz".

Quote:

Android didn't really support RISC-V hardware as there was no RISC-V hardware for Android yet.

Wrong. Before this Google move in April 2024, https://www.androidauthority.com/android-drop-risc-v-kernel-3438330/ Android kernel has patches to support RISC-V architecture.

Quote:

https://www.hackster.io/news/sifive-s-hifive-pro-p550-developed-in-partnership-with-intel-aims-to-be-the-fastest-risc-v-sbc-yet-5789a4734bcc

Counter, https://www.theregister.com/2023/01/30/intel_ris_v_pathfinder_discontinued/

SiFive claims of anti-proprietary single-source FUD are debunked by ARM clones from Apple's M series and Qualcomm Oryon.

AMD's K12 ARMv8 clone is based on Zen R&D building blocks. RISC-V is for the weak IP CPU R&D vendors.

https://liliputing.com/sifive-hifive-premiere-p550-high-performance-risc-v-dev-board-coming-this-summer
P550 RISC-V dev board prices start at $650 USD with 16GB of DDR5 memory and $800 with 32GB of RAM.

I rather buy Valve's Steam Deck with games.

Last edited by Hammer on 21-May-2024 at 01:06 PM.
Last edited by Hammer on 21-May-2024 at 01:01 PM.
Last edited by Hammer on 21-May-2024 at 12:58 PM.
Last edited by Hammer on 21-May-2024 at 12:53 PM.
Last edited by Hammer on 21-May-2024 at 12:46 PM.
Last edited by Hammer on 21-May-2024 at 12:43 PM.
Last edited by Hammer on 21-May-2024 at 12:38 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

So... fancy RISC-V dev boards with tons of RAM are still cheaper than Apollo V4SA :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Seems Commodore was better at designing cpus than Motorola:

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

8/16 chip, executes in 1 clock cycle, adds back the Z register that was removed to make a cheaper version of Motorola's 6800 (aka the original 6502), removes some delays resulting in another 25% performance increase.
...also added a B register...and many other features...

This was used in an Amiga serial card and was to be the C65's cpu.

So yes, that's why Motorola failed. They were bad at designing good, fast affordable cpus.

Last edited by Lou on 21-May-2024 at 06:02 PM.
Last edited by Lou on 21-May-2024 at 06:01 PM.

Quote:

Lou wrote: Seems Commodore was better at designing cpus than Motorola: https://en.wikipedia.org/wiki/CSG_65CE02 .... (I deleted the features list)

This chip has 2 main problems:

1. Launched 1988
2. Discontinued 1988

It would had been a big thing in 1982 (of course as a NMOS chip) but 1988 was to late, there was a big market for embedded 8-Bit and C=/MOS was to late with its enhanced 6502 versions and I/O chips.

If they had been on top of their time, C= would had a C64 successor with a 16/32 bit CPU around 1984 and they would have never bought Amiga.

bhabbott Quote:

That's OK, because the Byte Sieve was designed to be a programming language benchmark, not a CPU benchmark. So if 8 bit computers have trouble compiling it efficiently that's part of the test!

The Byte Sieve benchmark is just as applicable for CPU benchmarking as language benchmarking. It is a simple enough algorithm that CPU specific assembly language code can be fully optimized and compared to programming language benchmarks as well as other CPU benchmarks. The algorithm itself is a mathematical computation like calculating Pi or factorial. These types of mathematical algorithms are useful but more often are used for educational purposes than real world purposes. Byte magazine did use their Byte Sieve benchmark in the Byte UNIX Benchmark Suite but later dropped it from their more comprehensive and real world NBench/BYTEmark benchmarks using more common algorithms.

bhabbott Quote:

One of the strengths of the 68000 over 8 bit CPUs like the 6502 and Z80 is that it was a better match to C's minimum 16 bit integer size, and the large number of registers with orthogonal operation also helped. The 68000's large flat memory map was an advantage too in real-world applications. The 8 bitters often struggled to make program size small enough to fit in their tiny memory, and machines with > 64k were dramatically slowed down by bank switching.

Right. Motorola was headed in the right direction with programming language, compiler and OS support. Hardware support for position independent code, reusable/reentrant code, a large flat address space and an orthogonal ISA with large datatypes and many GP registers went with this philosophy. CPU metrics were evaluated and hardware changes were made to improve CPU metrics like better code density, reduced memory traffic and reduced instructions to execute. These were philosophies which carried over into 68k Amiga development and make the 68k Amiga special today.

The 68000 wasn't a high performance design as it was a large and lower performance microcoded CPU design. Performing 32 bit address calculations and using 32 bit pointers in memory reduced performance. Memory access timing was not aggressive. There was no pipelining or caches. An old and practically outdated chip fab process was used at launch. Why was the 68000 not only high performance but market leading in performance?

https://en.wikipedia.org/wiki/Byte_Sieve#Origins Quote:

Example runs were provided for a variety of machines, mostly Zilog Z80 or MOS 6502-based. The best time was initially 16.5 seconds, turned in by Ratfor on a 4 MHz Z80 machine, but Gary Kildall personally provided a version in Digital Research's prototype version of PL/1 that ran in 14 seconds and set the mark for this first collection. The slowest was Microsoft COBOL on the same machine, which took a whopping 5115 seconds (almost one and a half hours), longer even than interpreted languages like BASIC. A notable feature of this first run was that C, Pascal and PL/1 all turned in a roughly similar performance that easily beat the various interpreters. A second set of tests was carried out on more powerful machines, with Motorola 68000 assembly language turning in the fastest times at 1.12 seconds, slightly besting C on a PDP-11/70 and almost twice as fast as 8086 assembler. Most PDP-11 and HP-3000 times were much slower, on the order of 10 to 50 seconds. Tests on these machines using only high-level languages was led by NBS Pascal on the PDP-11, at 2.6 seconds. UCSD Pascal provided another interesting set of results as the same program can be run on multiple machines. Running on the dedicated Ithaca InterSystems Pascal-100 machine, a Pascal MicroEngine based computer, it ran in 54 seconds, while on the Z80 it was 239, and 516 on the Apple II. ... Motorola 68000 (68k) assembly remained the fastest, almost three times the speed of the Intel 8086 running at the same 8 MHz clock. Using high-level languages the two were closer in performance, with the 8086 generally better than half the speed of the 68k and often much closer. A wider variety of minicomputers and mainframes was also included, with times that the 68k generally beat except for the very fastest machines like the IBM 3033 and high-end models of the VAX. Older machines like the Data General Nova, PDP-11 and HP-1000 were nowhere near as fast as the 68k.

We can even add in disadvantaged 68k compiler support compared to the 808x and later x86 which continued all the way through the 68060. The Byte Sieve is a good enough CPU benchmark to show the superior 68k ISA. The 68k ISA remains competitive in performance metrics today with room for improvements and the elegance remains one of the greatest ever. The 6502 ISA is crude and limited in comparison but every bit as historically important by allowing practically the smallest low cost CPUs possible. The 6502 created the PC, console and low end 8 bit embedded markets while the 68k created the workstation and 16/32 bit embedded markets. It's crazy to think that these two computer evolutions occurred just 4 years apart considering how crude the 6502 is and how elegant and modern the 68000 is in comparison.

@Hammer

Quote:

Hammer wrote: @bhabbott Quote: bhabbott wrote: Wolfenstein 3D needs at least 528k of 'conventional' RAM to run in DOS. An 8 bit system might not need quite that much, but it's still well over the memory addressing capabilities of the 6502, Z80 and 6809. So your 'benchmark' is useless for over half the CPUs in matthey's list. Wrong. https://youtu.be/acUH4lWe2NQ?t=738 Apple IIGS has Wolfenstein 3D port. This example has a 65C816 @ 8 Mhz CPU accelerator which replaced 2.8 MHz 65C816.

Is 65C816 on matthey's list ? Let's see...

Quote:

matthey wrote: Byte Sieve comparison 6502@1MHz 13.9s Z80@4MHz 6.8s 6809@2MHz 5.1s 8086@8MHz 1.9s 68000@8MHz 0.49s

No.

So I'm not wrong. Wolfenstein 3D is pretty useless as a benckmark for 8 bit CPUs. Most of them can't run it at all without major modifications which invalidate it as a benchmark.

According to your YouTube video the CPU in that accelerated Apple IIGS is running at 10 MHz. Frame rate looks to be a wee bit faster than my Amstrad PC2086 with 8MHz 8086. Of course it's only rendering in 16 colors (with some palette swapping in the status bar).

But hey, let's play that game. Here's Wolfenstein 3D on the ZX Spectrum:-

Wolfenstein 2004 Walkthrough, ZX Spectrum

Looks like about the same frame rate as the Apple IIGS. So 3.5 MHz Z80 = 10 MHz 65C816!

And if that wasn't impressive enough, here it is running 'Doom'!

DOOM game on ZX Spectrum

Last edited by bhabbott on 21-May-2024 at 08:37 PM.

Hammer Quote:

You missed the point on Z3660's MYS-7Z020-V2's lower price vs 68060 Rev 6. MYS-7Z020-V's AMD Zynq 7020 SoC includes FPGA and Z3660's MYS-7Z020-V2 combo includes RTG, AHI, Network, and 'etc' that is hosted by Linux. Warp1260 (68060 rev 6 with RTG, AHI, WiFi, microSD, and ARM co-processor) has a crazy "Phase 5" price. For big box A3000/A4000, Z3660 competes against A3660, BGF9060, and TF4060. Open-source A3660 could be modified for PiStorm32-RPi 3A/4B since Z3660 itself is based on open-source A3660.

I understand the value provided by integration. The A3660 reduced all the PAL logic into a single FPGA providing room for new features and a SoC provides a lot of resources in a small area, even though it is an older ARM SoC with limited performance. Jay Miner understood the philosophy of innovate, integrate and conquer but CBM and successors chose antiquate, divide and be conquered.

Hammer Quote:

For FPU emulation, Z3660's 68K-to-ARM emulation is less mature when compared to PiStorm-Emu68. https://www.phoronix.com/review/gentoo_arm_x32/3 ARM Cortex A9 @ 1Ghz beats Intel Atom N450 Pineview @ 1 Ghz on C-Ray.

Your review above compares a dual core OoO Cortex-A9 to a single core in-order Atom N450. The Atom N450 uses a 45nm process and the Cortex-A9 likely uses either a 40nm or 28nm process. The in-order Atom cores were the lowest power Intel x86(-64) cores while the Cortex-A9 cores were the highest performance ARM cores at that time. The Cortex-A9 is mildly underclocked from 1.2GHz while the N450 is severely underclocked from 1.67GHz. In-order CPU cores are simpler than OoO cores and can sometimes clock higher. Intel tried to reduce the x86(-64) ISA baggage by reducing x86-64 hardware support which resulted in incompatibility so they returned to full compatibility and OoO with later Atom cores. The x86-64 ISA had grown too fat for an efficient in-order core using less power. You can read about some of the problems at the following link.

https://en.wikichip.org/wiki/intel/microarchitectures/bonnell

The in-order Atom CPUs were not bad performance but they were handicapped at their power target. The design is based on the Pentium P5 which had limited superscalar issue for FPU instructions so maybe they have a similar issue with SSE instructions or maybe they didn't have the transistor budget to pipeline such robust FPU/SIMD unit ISAs (~94 old FPU mnemonics and ~408 SIMD unit mnemonics with newer instructions having grown very long which is another problem).

Hammer Quote:

https://www.youtube.com/watch?v=VjReLuIvyqQ PiStorm32-Emu68 can use 3DFX Voodoo 3 PCI via Mediator PCI 1200 TX bus board. This would need a tower case conversion. RPi CM4 has PCIe, hence a path towards PCie 3D acceleration. The problem is A1200's small case. My point, soft 68K-on-ARM can use 3D acceleration when there are 3D drivers available. There's no "68060 @ 1 GHz".

Yep. Frankenmiga hardware is alive while the elegant 68k Amiga is dead.

Hammer Quote:

Wrong. Before this Google move in April 2024, https://www.androidauthority.com/android-drop-risc-v-kernel-3438330/ Android kernel has patches to support RISC-V architecture.

So which RISC-V hardware was supported by Android?

Hammer Quote:

Counter, https://www.theregister.com/2023/01/30/intel_ris_v_pathfinder_discontinued/ SiFive claims of anti-proprietary single-source FUD are debunked by ARM clones from Apple's M series and Qualcomm Oryon.

The RISC-V news goes both ways with conflicting reports.

https://www.eetimes.com/intel-looking-to-buy-sifive-for-2bn/
https://www.theregister.com/2022/12/15/qualcomm_talks_up_riscv_roasts/

Developers love the royalty free, open hardware and customization options for the RISC-V ISA but the ISA is a weak underwhelming do over with minor improvements of RISC-I through RISC-IV and there is a lack of standardization which reduces proliferation and developer support. It's a love hate relationship as customization and standardization are partially conflicting goals. ARM had the same problem before trying the standardization route with AArch64.

Hammer Quote:

AMD's K12 ARMv8 clone is based on Zen R&D building blocks. RISC-V is for the weak IP CPU R&D vendors. https://liliputing.com/sifive-hifive-premiere-p550-high-performance-risc-v-dev-board-coming-this-summer P550 RISC-V dev board prices start at $650 USD with 16GB of DDR5 memory and $800 with 32GB of RAM. I rather buy Valve's Steam Deck with games.

I agree that SiFive is going to have a difficult time competing in the low end desktop market at that price point. Even if they had a competitive OoO RISC-V CPU, x86-64 has that market locked up due to standardization and compatibility with Windows software including games. Small affordable SBCs with integrated GPUs below where x86-64 can scale is where the hobby, embedded, retro gaming/microconsole, educational markets merge as the RPi Foundation has discovered. The RPi market is primarily based on standard hardware as customers use different OSs and most of the gaming is emulation of retro games too. It's not like the old days with a standard 68k Amiga platform even though small footprint integrated hardware using a SoC makes sense again.

Last edited by matthey on 22-May-2024 at 12:34 PM.
Last edited by matthey on 21-May-2024 at 11:00 PM.

@kolla

Quote:

kolla wrote: @Hammer So... fancy RISC-V dev boards with tons of RAM are still cheaper than Apollo V4SA :)

RISC-V dev boards are useless for Amiga.

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

@bhabbott

Reminder, Amiga is not an embedded platform. I just ignored the embedded spill from Matt.

Quote:

But hey, let's play that game. Here's Wolfenstein 3D on the ZX Spectrum:- Wolfenstein 2004 Walkthrough, ZX Spectrum

That's not" Wolfenstein 3D".

Amiga's chunky pixel is 1 bitplane. Amiga's stock 68000 7.1 Mhz Wolfenstein 3D clone would speed up with 1 bitplane.

Quote:

DOOM game on ZX Spectrum

That's NOT "Doom". It's yet another Wolfenstein 3D clone with a very low color display.

---------------------------------------

@matthey

Quote:

Your review above compares a dual core OoO Cortex-A9 to a single core in-order Atom N450. The Atom N450 uses a 45nm process and the Cortex-A9 likely uses either a 40nm or 28nm process. The in-order Atom cores were the lowest power Intel x86(-64) cores while the Cortex-A9 cores were the highest performance ARM cores at that time. The Cortex-A9 is mildly underclocked from 1.2GHz while the N450 is severely underclocked from 1.67GHz.

ARM Cortex-A9 has passed 2 Ghz clock speed.

https://www.anandtech.com/show/6787/nvidia-tegra-4-architecture-deep-dive-plus-tegra-4i-phoenix-hands-on/3

NVIDIA Tegra 4i has ARM Cortex A9 (r4p1) reached 2.3 GHz on TSMC's 28 nm process node.

NVIDIA Tegra 3's Cortex A9 has 1.7 Ghz on TSMC's 40nm LPG process node.


Quote:

I agree that SiFive is going to have a difficult time competing in the low end desktop market at that price point. Even if they had a competitive OoO RISC-V CPU, x86-64 has that market locked up due to standardization and compatibility with Windows software including games. Small affordable SBCs with integrated GPUs below where x86-64 can scale is where the hobby, embedded, retro gaming/microconsole, educational markets merge as the RPi Foundation has discovered. The RPi market is primarily based on standard hardware as customers use different OSs and most of the gaming is emulation of retro games too. It's not like the old days with a standard 68k Amiga platform even though small footprint integrated hardware using a SoC makes sense again.

RPi 4 is ARM SystemReady ES and SystemReady IR certified.

Instructions to make PRi 4 board to be SystemReady certified from https://github.com/ArmDeveloperEcosystem/systemready-guides/blob/main/Raspberry%20Pi/Raspberry%20Pi%204%20Model%20B/readme.md

Quote:

So which RISC-V hardware was supported by Android?

https://www.theregister.com/2023/10/31/google_android_risc_v/
For during 2023, "Google formally gets to work on Android on RISC-V"


Quote:

The RISC-V news goes both ways with conflicting reports. https://www.eetimes.com/intel-looking-to-buy-sifive-for-2bn/

Factor in the article's date. Your link has June 2021 date.

My link has Jan 2023 date.

Quote:

https://www.theregister.com/2022/12/15/qualcomm_talks_up_riscv_roasts/

The keyword in your article is microcontrollers.


Qualcomm ramping up its AArch64 clone Oryon CPU in 2024.


https://www.qualcomm.com/news/onq/2022/11/qualcomm-oryon-custom-cpu-at-center-of-next-gen-premium-experiences-on-snapdragon-platforms
"Qualcomm Oryon CPU: a custom CPU at the center of next-generation premium experiences on Snapdragon platforms" - Qualcomm's official PR.

Last edited by Hammer on 22-May-2024 at 08:58 AM.
Last edited by Hammer on 22-May-2024 at 08:54 AM.
Last edited by Hammer on 22-May-2024 at 08:49 AM.
Last edited by Hammer on 22-May-2024 at 08:44 AM.
Last edited by Hammer on 22-May-2024 at 08:42 AM.
Last edited by Hammer on 22-May-2024 at 08:39 AM.
Last edited by Hammer on 22-May-2024 at 08:36 AM.
Last edited by Hammer on 22-May-2024 at 08:27 AM.
Last edited by Hammer on 22-May-2024 at 08:09 AM.
Last edited by Hammer on 22-May-2024 at 08:01 AM.
Last edited by Hammer on 22-May-2024 at 07:47 AM.
Last edited by Hammer on 22-May-2024 at 07: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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Hammer wrote: @kolla Quote: kolla wrote: @Hammer So... fancy RISC-V dev boards with tons of RAM are still cheaper than Apollo V4SA :) RISC-V dev boards are useless for Amiga.

And?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: And?

Fact.

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

@Hammer

Quote:

Hammer wrote: @kolla Quote: kolla wrote: And? Fact.

Another fact… V4SA is an embedded system, and hence not Amiga.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC