@matthey

Quote:

I wouldn't be surprised if more man hours have been spent on optimizing Quake for the Pentium than all the man hours spent on 68060 compiler support combined.

Classic Pentium FPU is superior e.g.
1. Limited FDIV out-of-order. Classic Pentium can execute other parallel FP instructions as long FDIV's result is not dependent within 16 cycles.

2. From register file control, it has multi-port FADD, FADD, and FDIV pipelines.

https://www.youtube.com/watch?v=DWVhIvZlytc

Quake software render is also memory bandwidth extensive.

68060 FPU is a disappointment.

Quote:

Your Zen RMW examples are not RMW operations. They are read operations.

https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf
Page 7-29, .7.5 Locked Read-Modify-Write Cycles

Last edited by Hammer on 25-Aug-2023 at 02:43 AM.
Last edited by Hammer on 25-Aug-2023 at 02:41 AM.
Last edited by Hammer on 25-Aug-2023 at 02:40 AM.
Last edited by Hammer on 25-Aug-2023 at 02:34 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

@matthey

Quote:

Some people think ARM cores are superior to the "outdated" 68060. The 68060 lacks many modern features of ARM in-order cores but stands up pretty well. More performance at a lower clock speed is better for embedded use as higher clock speeds generate more heat and use more power. The 133MHz Cortex-M0+ cores in the RP2040 are only 0.99 DMIPS/MHz (ARM claim) while a 68060@90MHz with 1.52+ DMIPS/MHz (Motorola claim) is higher performance. The ARM counter to low integer single core performance is to add more cores but this only works well for parallel workloads which Amiga emulation is not. David House predicted performance doubles every 18 months but I believe ARM designs were not able to surpass the 1994 68060 in integer single core performance as measured by DMIPS/MHz for over a decade until the 2005 Cortex-A8 which had 2.0 DMIPS/MHz (ARM claim). The in-order superscalar Cortex-A8 had 13 pipeline stages compared to the 68060 8 stages which gives more instruction level parallelism and potentially higher clock speeds at the cost of longer pipeline refills from mispredicted branches and interrupts and more transistors used. Despite the deeper pipeline not really being a good tradeoff for an embedded core, the Cortex-A8 was very popular (it was kind of like the Pentium 4 of ARM CPUs). By this time, a Cortex-A8 had at least twice and more commonly four times the L1 cache sizes of the 68060 and often came with a 128kiB or 1MiB L2 cache and, despite the ARM reputation for small cores, used many more transistors and likely more than the later 2011 in-order superscalar Cortex-A7 which returned to the more practical 8 stage pipeline (dropping to 1.9 DMIPS/MHz) and typically using about four times the transistors of the 68060, mostly for caches. The chip process for the 68060 started at 500nm while the Cortex-A8 started at 65nm and the Cortex-A7 started at 40nm. All the cores mentioned so far have been 32 bit cores with roughly equivalent extreme code compression which improves cache efficiency, reduces memory requirements and reduces memory bandwidth requirements. ARM's compressed Thumb encodings allowed them to gain major embedded market share and compete against the 68k which was not getting many new and especially not high performance designs. Motorola suits decided fat PPC was good for embedded use and lost all but the highest end embedded market to ARM Thumb cores (PPC cores could achieve better DMIPS/MHz than the weak performance ARM cores but needed more expensive hardware). Motorola created a simplified 68k ISA called ColdFire for low end embedded use but lost most of their 68k embedded market by not making it compatible enough to the 68k due to wanting to kill off the 68k so it couldn't compete with PPC. Despite ColdFire losing some performance and compression (code density) compared to the 68020 ISA, the 2002 in-order superscalar ColdFireV5 achieved 1.83 DMIPS/MHz with a design copied from the 68060 with a few more modern features added but still only 16kiB I+D caches, no L2 cache and using only a 130nm chip process. I believe the ColdFireV5 had better single core integer performance than any ARM designed core when it became available and even remained competitive against the significantly newer 2005 Cortex-A8 and 2011 Cortex-A7. Up to this point, the biggest 68k performance impediment was Motorola management who threw their baby out with the bathwater. The story is not over though. In 2012, ARM introduced the extremely popular 64 bit in-order superscalar Cortex-A53 with a higher performance AArch64 ISA now achieving 2.3 DMIPS/MHz. AArch64 does have some high performance features that likely explain some of the performance boost from previous year Cortex-A7 with 1.9 DMIPS/MHz. The number of integer general purpose registers were increased to 32 which is the same as PPC and CISC like addressing modes were added like the 68k helping to decrease the elevated instructions executed of Thumb encodings (equivalent Thumb2 code could use 20% more instructions than 68020 code despite being similar size). AArch64 code can be 50% larger than 68020 and Thumb2 32 bit code but PPC code density is worse (PPC 32 bit code is probably about 20% larger). 64 bit pointers are bigger and slower often making data harder to push as well. AArch64 makes compiler support easier and I believe ARM worked hard to improve it for a successful launch. I believe ARM stepped up their design quality and increasing the designs options like supporting more chip process sizes and more cache sizes. It is possible for the Cortex-A53 to use a 40nm chip process with 8kiB L1I/D caches and no L2, this CPU would be a total dog and I'd be surprised to see 2.3 DMIPS/MHz but at 10nm with 32kiB L1/I/D and 2MiB L2, maybe a Cortex-A53@1.4GHz could emulate more than a 68060@114MHz. The cost of 64 bit in the Cortex-A53 isn't too bad though as the transistors used are maybe roughly five times that of a 68060 not counting the other 3 cores which are commonly in a chip. For the early 64 bit OoO Cortex-A57 this jumps to roughly 30 times the transistors of a 68060 for one core and doesn't even double the single core integer performance at 4.1 DMIPS/MHz. ARM went big to try and compete in the desktop and server markets while focusing less on their historic small and cheap embedded market. Sorry for the long paragraph but I hope it gives some perspective that I'm not talking about anything close to the desktop.

Your theoretical DMIPS debate doesn't reflect the real-world use case e.g. Emu68's ARM MIPS near real-time statistics.

Amiga 68K has Star Wars Dark Forces 68K port in addition to other 68K game ports like Quake, Doom, and DevilutionX (Diablo) benchmarks.

For Quake and Doom 68K benchmarks, Emu68-ARM Cortex A53 @ 1.4Ghz (RPi 3A+) murdered 68060 Rev 6 @ 100 Mhz. Emu68-ARM Cortex A53 @ 1.4 Ghz is like Pentium II 266 Mhz to 300 Mhz Quake demo3 results. I overclocked ARM Cortex A53 to 1.6 Ghz without triggering an "overclocked" warning from RPi 3A+.

Last edited by Hammer on 25-Aug-2023 at 03:37 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

Hammer Quote:

Classic Pentium FPU is superior e.g. 1. Limited FDIV out-of-order. Classic Pentium can execute other parallel FP instructions as long FDIV's result is not dependent within 16 cycles.

Separate parallel units act like OoO execution including the FPU for both the 68060 and Pentium. The 68060 can often execute integer instructions under FPU instructions for free which I made extensive use of for the vbcc FPU support I worked on as well as Quake optimizations I did. The long FDIV execution time gives plenty of time to schedule code underneath but is often limited by lack of independent instructions available. It's true that the 68060 does not have the Pentium FDIV optimization which sounds good but may be annoying to use due to the old stack based Pentium FPU. The 68060 FPU is clean and lean while the Pentium FPU is the opposite. The 68040 FMOVE optimization and a few rarely used FPU instructions were also removed but they were smart enough to add back the common FINT(RZ) instruction which is an overall improvement in my opinion. Retaining more FPU instructions in hardware would have been better for compatibility and more optimizations, units and pipelining could have been added but compatibility and FPU performance were not as important as integer performance and cost for embedded use. The 68060 was a financial success but not because of the desktop market.

Hammer Quote:

Quake software render is also memory bandwidth extensive. 68060 FPU is a disappointment.

While the FPU has larger instructions and uses larger data sizes than the integer pipelines, most FPU calculations have 3+ cycle latency throttling FPU intensive code and reducing instruction and data requirements. Dual superscalar integer pipes which can each access memory like the 68060 can have comparatively high peak memory bandwidth requirements despite smaller instructions and usually 32 bit max data accesses. I suspect the 8kiB DCache significantly limits FPU performance although more memory bandwidth would help with all the misses.

Hammer Quote:

Page 7-29, .7.5 Locked Read-Modify-Write Cycles < multiple cycles. Look in the mirror.

A locked RMW access is not the same as a normal RMW access. The 68k only has TAS, CAS and CAS2 as locked RMW instructions while x86 has commonly used older instructions that use it by default and a prefix to add it to more instructions. It is trickier to support fast RMW accesses that can be optionally locked. Locked RMW instructions are very expensive with multi-core CPUs as the access must be locked in all caches including all core private caches (usually L1 and sometimes L2). A fast normal RMW access reduces the number of memory accesses and the memory bandwidth used.

Hammer Quote:

Your argument doesn't address the Quake benchmark problem.

If it was possible to combine the 68k GCC 2.95.3 to 3.3 integer code generation with the vbcc FPU code generation and then write an instruction scheduler for it, the 68060 would likely do much better. An instruction scheduler improved the execution speed of a 2 issue superscalar RISC CPU by 34% compared to unscheduled code but I expect this varies greatly and is significantly less on the 68060 due to design and ISA advantages. There is no reason to optimize for a specific CPU anymore anyway as the 68k Amiga is an emulated/virtual environment now. Optimizing for size may become the most common and recommended optimization as the Amiga fades away.

Hammer Quote:

Your theoretical DMIPS debate doesn't reflect the real-world use case e.g. Emu68's ARM MIPS near real-time statistics. Amiga 68K has Star Wars Dark Forces 68K port in addition to other 68K game ports like Quake, Doom, and DevilutionX (Diablo) benchmarks. For Quake and Doom 68K benchmarks, Emu68-ARM Cortex A53 @ 1.4Ghz (RPi 3A+) murdered 68060 Rev 6 @ 100 Mhz. Emu68-ARM Cortex A53 @ 1.4 Ghz is like Pentium II 266 Mhz to 300 Mhz Quake demo3 results. I overclocked ARM Cortex A53 to 1.6 Ghz without triggering an "overclocked" warning from RPi 3A+.

I'm not surprised the JIT emulated Cortex-A53 performance of a 68k Amiga is significantly better than SysInfo bogus results but the performance is still not impressive. It's a fraction of the performance of native code on a low end CPU. It's not attractive for performance/$ or performance/W so its only for cheap 68k emulation users with low standards of compatibility and quality. Retro Games Limited wanted better than Cortex-A53 emulation but they couldn't afford it by themselves. Well, their big reason was likely to lower the production cost. I wonder how much cost reduction of THEA500 Mini it takes to double the sales volume. Maybe $20 or $25 instead of $100 for the actual Amiga 500 back in the day?

Jeff Porter Quote:

We got the cost of the A500 down to $200. So we could sell it for $400 to the retail channel and then mark it up to the retailer for $600 and everyone was really happy. In fact, someone asked me today, "Why do we call it the Amiga 500?" I said, "Because that is what it is supposed to sell for." It's supposed to sell for 500 bucks. If you can make a computer for 500 bucks vs a computer for 600 bucks, you'll sell twice as many at 500 as at 600. There is just some magic price points in the world. And every time you take another 100 bucks out you double the volume. It's pretty amazing there that if you can get the right price points you can move a whole bunch of these things. So we did that and in January of 1987 we had the first Amiga 500 prototypes in plastic cases. I think our tooling had just come in. And I still remember Winfried Hoffmann coming in from Germany and he looked at that and it was running Defender of the Crown, it was running Deluxe Paint, it was running all these famous Amiga titles and it looked like a Commodore 64 and his eyes just lit up. He said, "Jeff, I know exactly what to do with this and by the way I'm taking that one. It's going with me. I'm hand carrying back to Germany. There is no way this one is going back to Pennsylvania. Sorry." I said, "Please, and by the way I have another one here, do you want two?" "Yes Please, and I have a third one from the guy in the UK."

https://youtu.be/otuQq4iqFgg?t=1029

I wonder if C= customers thought the A500 price cut was to "reduce to clear" a "dead end product".

Last edited by matthey on 25-Aug-2023 at 07:34 PM.
Last edited by matthey on 25-Aug-2023 at 07:22 PM.
Last edited by matthey on 25-Aug-2023 at 06:43 PM.
Last edited by matthey on 25-Aug-2023 at 06:41 PM.

@Thread

What a benchmarking nightmare!


Why has this devolved into this rubbish! Buy THEA500 Mini and get 030/50 AGA performance! Simple and I don't really care that it's an Arm chip carrying out the compute cycles/instructions! It 'feels' like a 68k Amiga so it is as far as I'm concerned! Buy one and forget about all this CPU Top Trump tripe!

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

@BigD

Quote:

BigD wrote: @Thread Why has this devolved into this rubbish! Buy THEA500 Mini and get 030/50 AGA performance! Simple and I don't really care that it's an Arm chip carrying out the compute cycles/instructions! It 'feels' like a 68k Amiga so it is as far as I'm concerned! Buy one and forget about all this CPU Top Trump tripe!

Well put.

Some would say: Users don't care about the tech specs, but developers care.
I would say: In today's day and age, unless a developer is working on low level stuff, even developers don't care. What language can I use? What sort of performance can be expected? How many potential buyers and what's their price sensitivity? Where's the SDK?

For all they care, under the hood instead of a SoC there could be a bat wing, some mixed feathers and rat bones tied around a rune adorned scroll. As long as it gets the job done.

_________________
All the way, with 68k

BigD Quote:

What a benchmarking nightmare!

I'm sorry, my last post is barely benchmark related. It is more about history, business, financial perspectives and marketing than benchmarking. I consider the big picture moving away from focusing on benchmarking hopefully ending arguments based on benchmarks. I attempted to return the thread to THEA500 Mini at the end with a comparison of marketing to the most successful mass market Amiga 500 which THEA500 Mini is based on. I'm sorry if people's attention spans, patience, memories and intellectual seeking and capacities have deteriorated. Let me extrapolate some of my points from the last post for you.

The 68k CPUs were used on the desktop for awhile by Apple, Atari and C= but Atari and C= bought cheap, often embedded CPUs while Apple bought, thus supporting, high performance 68k CPUs until Apple stopped at the 68040 and switched to PPC. We were fortunate to even get a 68060 which was likely originally targeted at dual embedded and desktop markets. It was switched to embedded market only and never upgraded despite roughly equivalent performance with the higher performance targeted desktop Pentium. The Amiga was designed to offload performance to the custom chips but C= minimally upgraded CPUs and custom chips despite customers clearly wanting more. A600 and CDTV dead inventories with 68000+ECS instead of sales of Amiga 1200 and CD32 with 68020+AGA significantly contributed to the demise of C=. THEA500 Mini is showing mass production potential yet may be missing an opportunity to push the 68k Amiga forward. Some people would argue that the performance is adequate to play 68020+AGA games which is all that is needed and intended. Perhaps this fits the "one and done" or "deadend" perspective of THEA500 Mini. Do customers want more like the AmigaOS exposed for general purpose use, ethernet/WiFi, RTG/Chunky support, more CPU performance, etc.? How many more units could be sold with these not "deadend" features and Amiga branding? Could a real hobbyist 68k Amiga like a Raspberry Pi be supported again long term and is emulation good enough?

Retro Games Limited approached Jeri Ellsworth about creating single chip retro computers. A single chip Amiga ASIC SoC could have significantly reduced cost and power. An ASIC SoC would have provided the potential to be used in other products like an Amiga in a controller similar to the C64 Direct-to-TV. They already have Amiga games licensed and a CD32 controller so this could have made sense. As a tiny business, they likely did not have adequate financial investments to justify the risk which could endanger the business if the product did not meet expectations. Instead of high risk high reward they chose low risk and hoped for better than low reward. With Covid supply problems and inflation, I believe THEA500 Mini introductory cost and the product price came in higher than they wanted which likely affected sales volumes while they also seemed to be disappointed in the sales volumes despite likely hundreds of thousands of units sold. The product could have offered much better value as well even though the eye candy and marketing was top notch. Value and especially price are very important for sales volumes. Jeff Porter talks about "magic price points" for the original Amiga 500 which he helped cost reduce. Dropping the cost of the Amiga 500 by $100 doubled the sales volume. THEA500 Mini likely has "magic price points" too where unit sales are doubled. Is it possible to significantly reduce the cost and increase the value of THEA500 Mini? Could sales volumes be doubled or tripled into the millions of units sold by hitting a few of these "magic price points" and increasing value like the A1200 did over the A600?

There isn't much intellectual stimulus for me here and businesses in the Amiga community would rather fight endlessly for their tiny portion of a low risk low reward market requiring little investment which is spent on lawsuits instead. Nothing is likely to change unless Michele can void the 2009 contract agreement that looks like Bill was intimidated and coerced into signing under financial duress which is illegal and should invalidate it (a pretty good argument could be made for it due to a previous threatening letter to Bill and a long list of Hyperion contract shenanigans). People with a lot to lose if the 2009 Hyperion agreement goes away remain arrogant. The golden ratio of nature and some say divine proportion of creation is ~1.618. Maybe Proverbs 16:18 is God's secret golden rule which is "Pride comes before destruction, and an arrogant spirit before a fall." Well, that is what happens to people who don't treat others as they want to be treated themselves.

Last edited by matthey on 26-Aug-2023 at 11:58 PM.

@BigD

Quote:

Buy THEA500 Mini and get 030/50 AGA performance! Simple and I don't really care that it's an Arm chip carrying out the compute cycles/instructions! It 'feels' like a 68k Amiga so it is as far as I'm concerned! Buy one and forget about all this CPU Top Trump tripe!

Indeed. It‘s now on sale for 74,95 EUR in Germany. Guess i‘ll get one, just for the fun.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@matthey

When they contacted Jeri - what year was this? And which 68k CPU did they have in mind? The 68SEC000? TG68 first came around in 2008 or so, on an extender board with its own FPGA for the C-One.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

The argument for why AROS on Raspberry PI, dwindled off, was lack documentation for the hardware, in embedded MPU, where everything is integrated, if have documentation for the hardware and there is little or no expandability, so can’t support the sound card, usb, gpu or ethernet controller your out of luck, sadly some companies only provide precompiled binary blobs, you can’t use, that has problem BSD and none Linux distributions.

I have seen raspberry pi, with PCIe 1x slots, so some expandability there is on even low cost mini PC’s, and seeing that being able to interface with a Amiga over GPIO pins is impressive. Perhaps not as pitch black as it seems, but with added cost hardware workaround, the mini pc, perhaps does not become so attractive cost vice.

Running AmigaOS / AROS hosted on top of Linux, looks to be smart choice for low end market, QEMU based low end Amiga can be, solution of extremely expensive hardware, but it will again depend on how well AmigaOS4 is supported by QEMU or how well AmigaOS4 supports QEMU.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: Running AmigaOS / AROS hosted on top of Linux, looks to be smart choice for low end market, ...

AROS hosted is still a code compiled natively for the CPU of the hosting system.

So OS and the compiled applications will run in full speed, performance of drivers and hardware depends on the usage of APIs on the hosting system.

Quote:

QEMU based low end Amiga can be, solution of extremely expensive hardware, but it will again depend on how well AmigaOS4 is supported by QEMU or how well AmigaOS4 supports QEMU.

QEMU for a PPC (or other alien architecture) usually needs an CPU emulator, resulting in a huge loss of performance in comparison to the hosting system. But for AOS3.x it's absolute OK and according to a lot of users, QEMU can beat an A1X1K on a actual cheap PC as long as no 3D acceleration is needed.

An AOS4.x or MOS with drivers for a simulated 3D acceleration though native hardware might be possible, but that's a task for developers writing QEMU friendly 3D drivers for AOS4 (or MOS).

Last edited by OneTimer1 on 27-Aug-2023 at 02:45 PM.

@matthey

Quote:

matthey wrote: Retro Games Limited approached Jeri Ellsworth about creating single chip retro computers. A single chip Amiga ASIC SoC could have significantly reduced cost and power. hat is what happens to people who don't treat others as they want to be treated themselves.

There was a single chip C64 but for the new retro C64s they switched to a solution using ARM.

I'm still a fan of the FPGA/ASIC solutions but the market seems to prefer software emulations.

@OneTimer1

Perhaps because FPGA are expensive. also, its technology people do not have at an arm’s length, not something I learned about at school, perhaps they do now.

There is also an upper limit to clock speed, at least for CPU emulation, approach to recompile with JIT, has some advantages, yes there is overhead, because of difference between the host and guest.

for everything else, FPGA is probably better, 500-600mhz range is acceptable for IO controllers, of course we faster RAM today then that, so you limit bus speed quite a bit, using a FPGA. Of course, the FPGA can be doing things while CPU is doing something different like the blitter. The FPGA can be used to fix wiring mistakes, or perhaps documentation does say active high or active low signal, this cases a FPGA good glue chip, as can allow you fix thigs, after PCB is produced.

the Software emulation approach, allows kernels to be patched, and native code replace emulated routines, this can give emulator a boost in for example disk emulation, bitmap rendering, this improvements are specific to routines that you patch.

The combination is probably the best approach.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: There is also an upper limit to clock speed, at least for CPU emulation, ...

Retro Projects like "THEA500 Mini" or "A600GS" are for Amiga games that where made for original Amigas, it's not about beating a Vampire V4 in speed. It's about beating them in price.

kolla Quote:

When they contacted Jeri - what year was this? And which 68k CPU did they have in mind? The 68SEC000? TG68 first came around in 2008 or so, on an extender board with its own FPGA for the C-One.

The first time Retro Games Limited contacted Jeri about a C64 SoC was in 2004 but it sounds like they contacted her again more recently about an Amiga SoC for THEA500 Mini.

https://game-news24.com/2022/04/07/a-500-mini-amiga-console-interview-is-our-passion-for-commodore/ Quote:

DM: It’s time to redistribute the clock to 2004. We managed to rebuild the whole chipset of a C64 on an easy chip. Because I say we, there’s a genius called Jeri Ellsworth who is a lone woman living in Portland, Oregon who is an absolute genius. And I spent a lot of time with him. We redesigned how we wanted the chip to work, and she ran it on one chip. That is quite unique for those who can do it, the job she did is generally done as a factory. We couldn’t replicate that for the Amiga, Jeris off doing other excellent things in the game of VR. We looked at doing it again but to create a solution for it would have been prohibitively expensive, so it’s an embarrassment.

There were other 68020 compatible FPGA CPU cores available to license before the TG68 68020 which became popular and well known because it was an open (free) core and FPGA prices had dropped enough to make them affordable in cheap FPGA hardware ($45 FleaFPGA Ohm for example). The 68k CPU is the most difficult and slowest part of an Amiga to simulate in FPGA so some older projects used actual 68k CPU chips as you say (original MiniMig for example). Even the $10 FPGA in a FleaFPGA Ohm can barely fit the TG68 68020 core along with AGA support for the 68020+AGA standard but higher performance in FPGA is difficult as the newer Apollo Core FPGA cost is several times the FleaFPGA Ohm FPGA cost and may exceed the whole FleaFPGA Ohm hardware cost. While CPU cores are expensive to develop and high performance cores use too much logic for cheap FPGAs, an ASIC is completely different. The logic (transistor/$) is very cheap in an ASIC. A mass produced Amiga ASIC using a TG68 with 68020+AGA may cost less than $1 while a semi-modernized 68060 or Apollo Core level of CPU core may also cost less than $1 but would have many times the performance due to both better performance/MHz and a higher clock speed. The ASIC package, pins, testing and shipping are more expensive than the logic for a simple Amiga SoC ASIC so it would pay to create a higher value ASIC. The ARM Cortex-A53 SoCs, not even counting any GPU logic, are using many times the logic of a 68060+AGA Amiga yet they are dirt cheap. Demand for in-order CPU cores continues where they dominate for embedded use because they are cheap, tend to have practical shorter 6-12 stage pipelines reducing jitter and interrupts are simpler. ARM cores have no inherent advantage for in-order CPUs. They just trade in and out advantages and disadvantages when they change ISAs. The first ARM cores were simple, tiny and low power because they lacked performance but this does not describe ARM Cortex-A53 chips which usually have 4 x 64 bit cores, L1 and L2 caches, support for 4+ ISAs, etc. yet remains the most popular small and cheap ARM CPU option.

NutsAboutAmiga Quote:

The argument for why AROS on Raspberry PI, dwindled off, was lack documentation for the hardware, in embedded MPU, where everything is integrated, if have documentation for the hardware and there is little or no expandability, so can’t support the sound card, usb, gpu or ethernet controller your out of luck, sadly some companies only provide precompiled binary blobs, you can’t use, that has problem BSD and none Linux distributions.

The Raspberry Pi Foundation has tried to be as open hardware as possible but they are limited when using commodity hardware which may be one of the reasons they have started designing their own chips like the RP2040 SoC. At least the standard RPi GPU is mostly documented which is unusual in the world of GPUs. The rest of the documentation has been good enough for non-Linux OSs to be used on RPis.

NutsAboutAmiga Quote:

I have seen raspberry pi, with PCIe 1x slots, so some expandability there is on even low cost mini PC’s, and seeing that being able to interface with a Amiga over GPIO pins is impressive. Perhaps not as pitch black as it seems, but with added cost hardware workaround, the mini pc, perhaps does not become so attractive cost vice.

The RPi is made for low power and even with a larger power supply, I doubt it would support much of a PCIe graphics card. An integrated GPU is the way to go for small SoC based SBCs.

NutsAboutAmiga Quote:

Running AmigaOS / AROS hosted on top of Linux, looks to be smart choice for low end market, QEMU based low end Amiga can be, solution of extremely expensive hardware, but it will again depend on how well AmigaOS4 is supported by QEMU or how well AmigaOS4 supports QEMU.

Dave Haynie had it right when asked on Quora if the Amiga could be resurrected.

Dave Haynie Quote:

As Harel said, not as a viable on-going operating system. It's just been too long, and there's no large company interesting in pushing it into the 21rst century. Yes, after taking more than twice as long as the original Amiga development, the Hyperion people have a release that runs on very, very expensive PowerPC boards. That's really not going to take AmigaOS anywhere, they will never have more than a very casual hobbyist interest in it. Of course, you can have a much faster system today on any old PC running it in emulation. Cloanto has been offering Amiga Forever, a pre-packaged system of UAE and Amiga ROMs, for quite some time: Amiga Emulation, Games, History and Support Since 1997. It's the best way to run legacy AmigaOS application today. The only possible way forward is AROS (AROS Research Operating System), but they really don't have enough people contributing to the project to make it competitive with Linux or any other FOSS systems. It's a particular shame because AROS/AmigaOS would be an ideal operating system for low-cost computers like the Raspberry Pi or the Beaglebone.

I agree that Amiga is still interesting on low cost computers like the RPi but even native AROS on ARM with run in UAE would have an uphill battle to gain OS market share on the RPi. The Amiga needs its own RPi like 68k hardware with a retro twist and games. The only way to leverage the tiny footprint of the Amiga, the responsiveness the Amiga is known for and the large software library of the Amiga is with a 68k CPU, Amiga chipset and the AmigaOS.

OneTimer1 Quote:

There was a single chip C64 but for the new retro C64s they switched to a solution using ARM. I'm still a fan of the FPGA/ASIC solutions but the market seems to prefer software emulations.

Emulation is cheaper and easier for one and done "deadend" hardware. The C64 market is likely different too. The C64 may not be useful enough to maintain production of a SoC ASIC, the fabrication process may have become too old to cheaply restart production or the C64 popularity may not be high enough for ASIC production anymore. That doesn't mean the original ASIC was a financial failure.

https://game-news24.com/2022/04/07/a-500-mini-amiga-console-interview-is-our-passion-for-commodore/ Quote:

Since it was originally introduced to the first of the series, the C64 was created in 2004, and became the first toy in QVC history to sell the most popular product. I believe we sold 666,000 units in the first hour of trading, a feat. But it proved to us that there was still that great love for all things Commodore. So, as you say well, the C64 then ran to the Wii and we were behind that. There’s a million sales people again, but they won’t sell all month.

Obviously with enough sales volume, the ASIC quickly pays for itself. Emulation is quicker to market and there is a time value of money though. Going to the trouble and expense of a quality ASIC is better suited for markets where ASIC production can be maintained or grown. Look at the RPi markets where the original RPi looked like an Acorn RISC OS retro product where demand was likely to drop off as the small RISC OS market became saturated but it was priced to compete in the hobby and embedded markets and the original RISC OS educational angle allowed them to be successful in the educational market. RPi sales just keep growing with no end in sight even though their SoC ASIC is new but already appears to be a huge success. The RPi Foundation probably wished they could have started with a larger enthusiastic retro market with software like the Amiga. We wish we had leadership like the RPi Foundation but unfortunately, we can't trade our "deadend" leadership.

Last edited by matthey on 27-Aug-2023 at 10:00 PM.

@BigD

Quote:

BigD wrote: @Thread Buy THEA500 Mini and get 030/50 AGA performance! Simple and I don't really care that it's an Arm chip carrying out the compute cycles/instructions!:

This is a very good post. If is works like an amiga and feels like an amiga then it is an amiga.

THEA500 Mini is a brilliant nostalgic illusion of the past Amiga but the hardware is just "good enough". The Amiga spirit came from "we can do better" and wouldn't exist without it. Let's take an Amiga related walk through history.

Amiga History

Chuck Peddle approached Motorola Semiconductor Division management about making a cost reduced version of their 6800 CPU but was told the 6800 was "good enough". Chuck left Motorola and his new business MOS nearly ended Motorola's Semiconductor Division with the famous 6502 CPU but one embedded automobile contract with GM saved them in 1976. Motorola knew that 16 bit versions of the Intel 8080 (8086) and Zilog Z80 (Z8000) were in development but this time they decided "we can do better" and the 1979 68000 CPU was born that was practically a generation ahead of the 16 bit competition by introducing an orthogonal 32 bit ISA with 16 32 bit general purpose registers and using 32 bit pointers for addressing of a huge flat memory model (no memory banks or segments). The 68000 microprocessor was evolutionary initially killing off minicomputers and replacing them with workstations. As the price fell, the 68000 was used in personal computers for the desktop and gaming PCs (Amiga, Apple Mac, Atari ST), later console gaming (Sega Genesis, NeoGeo, X68000) and even dominated 16/32 bit embedded markets.

Former Atari programmer Larry Kaplan went to a June 1982 CES show where he saw the NES console and thought, "we could do better". Larry was no doubt thinking of Jay Miner when he was thinking of "we" because it didn't take "we" long to approach the ex-Atari employee. Jay asked for two things before agreeing to join the group. They had to use the 68000 CPU and the console had to be expandable into a computer. Before Jay left Atari, he had approached management about creating the next generation console and computer hardware with the same request but the hardware Atari had was "good enough" while Jay knew "we could do better". Ironically, Larry was lured back to Atari by Nolan Bushnell who he was trying to get to help Amiga. Larry was at Atari when they saw a $1 billion loss due to the video game crash of 1983 caused in large part by Atari management greed which thought their existing hardware and software were "good enough". Jay Miner's "we could do better" requests for a 68000 CPU which was expensive for a console and unnecessary computer expandability likely saved the Amiga as it became a personal computer instead of a console.

Motorola was so overwhelmed by 68000 sales that they had trouble keeping the CPUs in stock which could have been a contributing reason why IBM made the fateful decision to choose the vastly inferior 8088 for the IBM PC. While the 68000 ISA made upgraded 68k CPUs which were fully 32 bit easy, they were slow to bring out upgraded 68k CPUs which weren't a priority because the 68000 was "good enough". Intel had their one huge win with IBM and focused on fast incremental improvements which kept chipping away at the mountain of advantages of the 68k. They 68k lost the workstation market to RISC hype (which ended up back at the less orthogonal CISC x86) and then the desktop market to Intel x86 but retained the less profitable embedded and console markets for many years where the stagnating CPU models were cheap and "good enough" now. Many businesses were buying embedded CPUs for consoles and the desktop because they were cheap and "good enough", including Commodore for their most mass produced Amigas. When Apple left the 68k desktop market after the 68040, there was not enough mass production to support high performance 68k CPUs anymore so embedded CPUs had to be "good enough".

Amiga Corporation had run up millions of dollars in debt developing the Amiga with the Amiga spirit of "we could do better". They had borrowed money from Atari who wanted the Amiga chips but Atari went on the auction block due to the video game crash of 1983. Jack Tramiel wanted the Amiga chips for revenge against Commodore who had just booted him, their founder. Commodore thought there C64 was still "good enough" but they didn't want Jack getting the Amiga and they could use the next C64 so they bought the Amiga out from under Jack. Jay Miner continued to improve the Amiga by developing the Ranger chipset and hoped to couple it with a newer 68k CPU but Commodore thought the Amiga with a few upgrades like PAL compatibility was "good enough" and the Amiga was "good enough" without Jay when they closed Los Gatos development. Commodore eventually released ECS years later which was still inferior to the Ranger chipset. It wasn't until AGA that the Ranger chipset was surpassed in features and the Commodore engineers developed the Amiga 3000+ with 68030+AGA and DSP but Commodore management under Bill Sydnes decided ECS was "good enough" for the Amiga 3000. Likewise, Bill Sydnes thought a 68000+ECS was "good enough" in the Amiga 600 and CDTV instead of the 68020+AGA Amiga 1200 and CD32 leading to having an oversupply of dead inventory in the former and not enough inventory of the latter to survive. Commodore had bought Chuck Peddle's MOS which once dominated the CPU market with the 6502 and should have given Amiga an advantage with the vertically integrated Commodore but Commodore thought the chip fabrication capabilities they had were "good enough". The Amiga chipset was never further integrated and the new Amiga chips being planned couldn't even be produced by the former MOS. Big tech companies looked at what was left of Commodore in bankruptcy and decided "we can do better" than what was left of the "good enough" Commodore Amiga technology.

Not much was attempted with the Amiga until Amiga Inc. backed by venture capitalist and Amiga fan Pentti Kouri acquired the Amiga IP. They tried to use the Amiga name to create a virtual machine called Amiga Anywhere kind of like the Java VM that runs on top of an existing OS. They thought having the Amiga name would be "good enough" to start with the loyal Amiga user base but it didn't really have anything to do with the Amiga that has a 68k CPU, custom chips, the AmigaOS and a large Amiga software library. Amiga users were used to poor CPU performance 1980s embedded 68k CPUs which Commodore used and even inefficient virtual machines on high performance x86 CPUs would seem faster but still Amiga fans complained. Amiga Inc. relented and contracted AmigaOS 4 on PPC to be created which used a real and much more efficient CPU but no 68k, no Amiga chipset and 68k emulation which is inefficient like a virtual CPU to run some 68k software which doesn't use the chipset while being on expensive PPC hardware. The AmigaOS was partially upgraded to desktop standards. Some people thought all this was "good enough" but only a few thousand units were sold. Then the cost of PPC hardware increased as the architecture died and cheap cut down embedded CPUs like Commodore used resulted in only a few hundred units sold but "good enough" for Trevor's rare collection of bastardized AmigaNOnes.

THEA500 Mini came along with a nostalgic Amiga illusion that showed there is an Amiga market even when the hardware is just "good enough", for a "deadend" toy. History tells us that emulation/virtual CPUs and machines are the end of a platform and not "good enough" to build a user base because native compilation is much more efficient. Even Retro Games Limited wanted to do better with a toy in respect of the original hardware but at least they gave us a good illusion. The Amiga spirit has been gone for a long time and we forget about the visionaries who believed "we can do better". The Amiga philosophies of elegance and CPU offloading are also dead, replaced by brute force perpetually high CPU load emulation.

Last edited by matthey on 31-Aug-2023 at 03:24 PM.
Last edited by matthey on 30-Aug-2023 at 04:29 PM.

@matthey

Quote:

matthey wrote: Let's take an Amiga related walk through history.

The enemy of the excellent or the very good is indeed the good enough.

Seeing the OG Amiga in this perspective is showing me just how much of a “moonshot” it was, and how Motorola’s own 68000 moonshot was the only natural choice for such a mission.

Alas, it also reminded me how after most moonshots comes the age of complacency. No one deemed it necessary to fit rear-view mirrors on the proverbial rockets.
That return to the “good enough”, drawn in by the gravity of greed, has been the bane of my existence.

The moonshots show us what’s possible when we have the will to act. When our mission is not the amount of money we will make, rather the lasting imprint we will leave on people’s lives.

Quote:

The Amiga spirit has been gone for a long time and we forget about the visionaries who believed "we can do better".

I have not forgotten, nor can I ever forget.
I know that in this regard, among those that frequent this forum and others like it, I am an outlier. My surveys of this demographic reveal a greater interest in nostalgia than that of a new moonshot. They’ve resigned themselves to short lasting moments of joy, through the dregs served up by those who share their hopelessness.

Last edited by agami on 30-Aug-2023 at 04:09 AM.

_________________
All the way, with 68k

@matthey

Quote:

Separate parallel units act like OoO execution including the FPU for both the 68060 and Pentium. The 68060 can often execute integer instructions under FPU instructions for free which I made extensive use of for the vbcc FPU support I worked on as well as Quake optimizations I did. The long FDIV execution time gives plenty of time to schedule code underneath but is often limited by lack of independent instructions available. It's true that the 68060 does not have the Pentium FDIV optimization which sounds good but may be annoying to use due to the old stack based Pentium FPU.

For the X87 stack design issue, Pentium has FXCH ST (x) instruction i.e. the contents in ST (0) can be exchanged with another stack register.

Earlier 486 CPUs didn't have Pentium FXCH instruction.

PC's Quake geometry workload is floating point while the integer units handle pixel-related processing. This mirrors DX8's floating point datatype vertex shaders and integer datatype pixel shaders.


Quote:

The 68060 FPU is clean and lean while the Pentium FPU is the opposite. The 68040 FMOVE optimization and a few rarely used FPU instructions were also removed but they were smart enough to add back the common FINT(RZ) instruction which is an overall improvement in my opinion. Retaining more FPU instructions in hardware would have been better for compatibility and more optimizations, units and pipelining could have been added but compatibility and FPU performance were not as important as integer performance and cost for embedded use. The 68060 was a financial success but not because of the desktop market.

The 68060 has a weaker FPU and 32-bit frontside bus which is not a problem for similar-era PowerPC 601, but PowerPC has inferior code density when compared to X86 and 68K.

idSoftware's Quake has single-handedly wreaked many wannabe 586 cloners.

68060's "success" in the embedded market is meaningless for the desktop AmigaOS platform.

Motorola exited the semiconductor business on October 6, 2003 to create Freescale.


Quote:

If it was possible to combine the 68k GCC 2.95.3 to 3.3 integer code generation with the vbcc FPU code generation and then write an instruction scheduler for it, the 68060 would likely do much better. An instruction scheduler improved the execution speed of a 2 issue superscalar RISC CPU by 34% compared to unscheduled code but I expect this varies greatly and is significantly less on the 68060 due to design and ISA advantages. There is no reason to optimize for a specific CPU anymore anyway as the 68k Amiga is an emulated/virtual environment now. Optimizing for size may become the most common and recommended optimization as the Amiga fades away.

Your argument still doesn't address the Quake benchmark issue.


Quote:

I'm not surprised the JIT emulated Cortex-A53 performance of a 68k Amiga is significantly better than SysInfo bogus results but the performance is still not impressive.

SysInfo MIPS is better than theoretical MIPS claims. Quake benchmark is more than a simple CPU benchmark.

Quote:

It's a fraction of the performance of native code on a low end CPU. It's not attractive for performance/$ or performance/W so its only for cheap 68k emulation users with low standards of compatibility and quality.

What a load of BS. Vampire has "turtle mode". This is not the first time when a faster 68K CPU breaks 68000 backward compatibility.

I have Wicher 508i (68HC000 @ 25 Mhz to 50 Mhz) for A500 and TF1260 (68060 rev1 @ 62.5 Mhz) for A1200. Using 68060, it's highly dependent on WHDload patched games.

For PiStorm32 Lite, Emu68 Beta 2.1 /EmuControl tool introduced "SlowdownCHIP" option.

This issue is due to the lack of resource tracking.

Quote:

Retro Games Limited wanted better than Cortex-A53 emulation but they couldn't afford it by themselves. Well, their big reason was likely to lower the production cost. I wonder how much cost reduction of THEA500 Mini it takes to double the sales volume. Maybe $20 or $25 instead of $100 for the actual Amiga 500 back in the day?

TheA500 Mini package includes other items besides SoC and PCB.

_________________
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

@matthey

Quote:

matthey wrote: THEA500 Mini is a brilliant nostalgic illusion of the past Amiga but the hardware is just "good enough". The Amiga spirit came from "we can do better" and wouldn't exist without it. Let's take an Amiga related walk through history. Amiga History (Cut for focus) Motorola was so overwhelmed by 68000 sales that they had trouble keeping the CPUs in stock which could have been a contributing reason why IBM made the fateful decision to choose the vastly inferior 8088 for the IBM PC. While the 68000 ISA made upgraded 68k CPUs which were fully 32 bit easy, they were slow to bring out upgraded 68k CPUs which weren't a priority because the 68000 was "good enough". Intel had their one huge win with IBM and focused on fast incremental improvements which kept chipping away at the mountain of advantages of the 68k. They 68k lost the workstation market to RISC hype and then the desktop market to Intel x86 but retained the less profitable embedded and console markets for many years where the stagnating CPU models were cheap and "good enough" now. Many businesses were buying embedded CPUs for consoles and the desktop because they were cheap and "good enough", including Commodore for their most mass produced Amigas. When Apple left the 68k desktop market after the 68040, there was not enough mass production to support high performance 68k CPUs anymore so embedded CPUs had to be "good enough".

Note that NEC's Intell X86-based PC-98 platform target has a higher install base when compared to Commodore's Amiga install base.

The install base for NEC's Intel X86-based PC-98 is about 18 million units.

Intel's 16-bit X86 evolved into a 32-bit 386 with industry-leading backward compatibility while Motorola played the "32-bit" instruction set "cut and paste" with 68K. 68000 has a 32-bit instruction set on 16-bit ALU hardware.

For business, Intel's 286's built-in MMU supports MS/SCO's Xenix. Motorola wasn't serious about Unix since it was late with the integrated MMU 68030. Xenix was best best-selling AT&T Unix-licensed distribution.

Intel 386's built-in MMU-enabled memory-protected/multi-user Windows NT and Linux to be created. Linux was created as the lower-cost Unix-like clone when the AT&T Unix license was expensive.

Quote:

Amiga Corporation had run up millions of dollars in debt developing the Amiga with the Amiga spirit of "we could do better". They had borrowed money from Atari who wanted the Amiga chips but Atari went on the auction block due to the video game crash of 1983. Jack Tramiel wanted the Amiga chips for revenge against Commodore who had just booted him, their founder. Commodore thought there C64 was still "good enough" but they didn't want Jack getting the Amiga and they could use the next C64 so they bought the Amiga out from under Jack. Jay Miner continued to improve the Amiga by developing the Ranger chipset and hoped to couple it with a newer 68k CPU but Commodore thought the Amiga with a few upgrades like PAL compatibility was "good enough" and the Amiga was "good enough" without Jay when they closed Los Gatos development. Commodore eventually released ECS years later which was still inferior to the Ranger chipset. It wasn't until AGA that the Ranger chipset was surpassed in features and the Commodore engineers developed the Amiga 3000+ with 68030+AGA and DSP but Commodore management under Bill Sydnes decided ECS was "good enough" for the Amiga 3000. Likewise, Bill Sydnes thought a 68000+ECS was "good enough" in the Amiga 600 and CDTV instead of the 68020+AGA Amiga 1200 and CD32 leading to having an oversupply of dead inventory in the former and not enough inventory of the latter to survive. Commodore had bought Chuck Peddle's MOS which once dominated the CPU market with the 6502 and should have given Amiga an advantage with the vertically integrated Commodore but Commodore thought the chip fabrication capabilities they had were "good enough". The Amiga chipset was never further integrated and the new Amiga chips being planned couldn't even be produced by the former MOS. Big tech companies looked at what was left of Commodore in bankruptcy and decided "we can do better" than what was left of the "good enough" Commodore Amiga technology.

Commodore leadership list and exits.

Jack Tramiel, exited in early 1984.
Marshall Smith, exited in 1986.
Thomas Rattigan, exited in 1987(?).
Max Toy, exited in late 1998-1989(?).
Mehdi Ali became Commodore International's president early in 1989.

"Read My Lips, No New Chips" memo during Amiga 3000's development seems to be under Max Toy and into Mehdi Ali.

Reference
https://www.afr.com/companies/commodore-falls-on-troubled-times-19900126-kalsw

Last edited by Hammer on 30-Aug-2023 at 04:45 AM.
Last edited by Hammer on 30-Aug-2023 at 04:39 AM.
Last edited by Hammer on 30-Aug-2023 at 04:37 AM.
Last edited by Hammer on 30-Aug-2023 at 04: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

@matthey

Quote:

There were other 68020 compatible FPGA CPU cores available to license before the TG68 68020 which became popular and well known because it was an open (free) core and FPGA prices had dropped enough to make them affordable in cheap FPGA hardware ($45 FleaFPGA Ohm for example).

hm, TG68 was primarily 68000 - 68020 was implemented later.

I don't know of any 68020 cores available for licensing (only several 68000 cores).

Quote:

Even the $10 FPGA in a FleaFPGA Ohm can barely fit the TG68 68020 core along with AGA support for the 68020+AGA standard ..

No, the FleaFPGA Minimig isn't AGA, only OCS and (limited) ECS, and defaults to 68000, though an early and quite buggy 68020 implementation is also present (noone updated it yet).

Quote:

A mass produced Amiga ASIC using a TG68 with 68020+AGA may cost less than $1 while a semi-modernized 68060 or Apollo Core level of CPU core may also cost less than $1 but would have many times the performance due to both better performance/MHz and a higher clock speed. The ASIC package, pins, testing and shipping are more expensive than the logic for a simple Amiga SoC ASIC so it would pay to create a higher value ASIC.

But with ASIC, you are locked and can no longer bugfix the cores. Not like the FPGA cores are bug free and not regularly updated, rather the contrary, there are typical a good handful of updates every year. With ASIC this would be a costly affair.

Last edited by kolla on 30-Aug-2023 at 04:58 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC