@Mr-Z

That's the point. You have an upgrade that's already far faster than any existing 68K silicon for a fraction of the cost of the fastest available 68K silicon. Fretting over how efficient the emulation is, is moot, because it is already fast enough to run any software written for the 68K comfortably. Could it be better? Yes, I'm sure that a much more complicated JIT could be engineered that is able to perform deeper analysis of 68K hot paths and perform optimisations to the scheduling of instructions and more aggressive register allocations etc. But is it necessary?

The best bit about the upgrade is that you get and will get additional expansions. RTG already. 3D perhaps in the near future. The framethrower also looks like a great value add later.

_________________
Doing stupid things for fun...

@Karlos

The 13x faster than 50 mhz 060 is realistic btw.

On running Heretic2 i get around 5-6x higher
speed than 100 mhz 060.

@Mr-Z

Signed to that. I look forward to when Heretic2 in
3d hw runs on my a1200 with pistorm.

AND i look forward to once Baldur’s Gate does (thumbs
crossed there might be some news on the Python front
soon… not as to a finished implementation but as
to a deal on paying a developer to deliver it ;))

@MagicSN

I don't doubt it. It does suggest perhaps that the build could be faster than this, since 13x is for a case we believe to be especially pathological.

You might test a 68K binary compiled and optimised for 68020, since this would hopefully put more emphasis on register only operands, loop unrolling, branch minimisation etc. This might allow it to perform faster on Emu68 than code fine tuned for 68060.

Last edited by Karlos on 21-Feb-2025 at 05:01 PM.

_________________
Doing stupid things for fun...

@Karlos

Speed difference between different cpu versions
was not so big but generally 060 version was fastest.
020 was one of the slower options.

@MagicSN

That's interesting. We know that branching, in particular, is more expensive under emulation since there's a lot more going on than just a branch. On the 060 though, branching is often free - you can see that plain as day in the results that were posted before. You might reasonably expect code optimised for 060 to be unconcerned with branch overhead compared to earlier processors. Mind you, how branchy code is more influenced by the code itself than compiler optimisations (except for loop unrolling).

Last edited by Karlos on 21-Feb-2025 at 05:44 PM.

_________________
Doing stupid things for fun...

MagicSN Quote:

The 13x faster than 50 mhz 060 is realistic btw. On running Heretic2 i get around 5-6x higher speed than 100 mhz 060.

Much of the JIT performance comes from caches. The 68k code translated to ARM code likely more than doubles in size but modern CPU cores have 4 times the L1 caches of the 68060. L2 caches are much better performance than the 68060 memory and even when the memory must be accessed, modern memory is much better too. The max CPU performance is when the code and data is in the L1 caches which is what we are looking at here and JIT is not good at keeping code in the L1 due to simple translation and much worse code density ISAs with ARM64 and x86-64. The translated code is not nearly as efficient as native compiled code either. The Karlos emububble benchmarks only examine all L1 cache performance which should scale linearly with the clock speed.

I will post the original emububble benchmark performance results again.

CPU@MHz | time | 68060 equivalent
68060@50MHz 408ms 68060@50MHz
Cortex-A53@1200MHz 251ms 68060@81MHz
Cortex-A72@2200MHz 128ms 68060@159MHz
i7@3000MHz 58ms 68060@408MHz

The new benchmark results see an improvement in JIT performance relative to the 68060 performance. Was this just the branch change from BGT to BNE?

All of the first 4 tests are similar to real code that could be found on the 68k. The last 3 tests are synthetic tests designed to try to improve RISC performance as simple 68k to ARM code translation is not the best for performance but the extra instructions reduce the 68060 performance.

CPU@MHz | test0 | test0 like | test1 | test1 like | test2 | test2 like | test3 | test3 like
68060@50MHz 2037ms 68060@50MHz 1528ms 68060@50MHz 1272ms 68060@50MHz 1145ms 68060@50MHz
Cortex-A53@1200MHz ?
Cortex-A72@2300MHz 561ms 68060@182MHz 286ms 68060@267MHz 155ms 68060@410 88ms 68060@651MHz
i7@3000MHz 140ms 68060@728MHz 71ms 68060@1076MHz 48ms 68060@1325MHz 38ms 68060@1507MHz

Unfortunately, there are no new results for the Cortex-A53 which I expect to see anemic results above like the original emutest and closer to Cortex-A72 results below with load-to-use stalls reduced or eliminated.

CPU@MHz | test4 | test4 like | test5 | test5 like | test6 | test6 like
68060@50MHz 2038ms 68060@50MHz 1781ms 68060@50MHz 1909ms 68060@50MHz
Cortex-A53@1200MHz ?
Cortex-A72@2300MHz 275ms 68060@371MHz 149ms 68060@598MHz 89ms 68060@1072MHz
i7@3000MHz 121ms 68060@842MHz 71ms 68060@1254MHz 51ms 68060@1872MHz

The 68060 branch folding is working well for the loops including for the tight loop which is good for code sharing and was one of the 68k Amiga strengths. It is difficult to separate the hardware from the JIT compilation as to why performance is so poor, but I expect a 68060@500MHz (and likely AC68080@500MHz too) with equivalent caches and memory would have better performance than Emu68 JIT using a Cortex-A72@2300MHz. A mobile Core i7@3GHz using JIT may be closer to a 68060@1GHz with equivalent caches and memory. The general rule of thumb that emulation can reach up to 1/3 of native performance seems to be close here. Whether 1/3 performance is good enough depends on whether someone is a 1/3 glass full or 2/3 empty personality. The remaining Amiga community have weathered the storms with their optimism so are more likely to be happy with their 1/3 full glasses while the majority of Amiga fans that left see the glass as 2/3 empty. Who would have bought their CPU clocked at 1/3 of what it currently is or be content to go to the pub and get a glass 1/3 full?

@matthey

I disagree with the conclusion. Let's proceed from the assumption that you are correct that typical emulation is 1/3 of native performance (I don't necessarily agree, it varies depending on the task, and tasks vary by user). The question naturally arises, "so what?" We're running 68K code on it, not native.

You could always look into AROS if that's a problem.

_________________
Doing stupid things for fun...

@matthey

But there is no 500 mhz 68060. Best there is is
100 mhz. And that is massively slower than even
A53 with emu68. Discussing hypotheticals does
not help.

@matthey

So, to summarize:

A 600 MHz 68060 is as fast or faster than Emu68. A 68060 running at the same clock speed as Cortex A72 with Emu68 shows how bad a JIT translators are. Of course 2GHz 68060 is running with the memory of adequate speed so it has no load/store penalties compared to poor ARM.

What wonders me, why so many people prefer to use PiStorm accelerators instead of Amiga accelerators with 1 GHz+ 68060 setups. Don't they understand that their glasses are only 1/3 full?

Ah wait, now I remember. There is no 68060 running at that speed. They are only in the 100MHz range, where a poor 1GHz A53 from Raspberry Pi Zero2 easily beats them in terms of performance and memory speed.

What is better for me? A 1cl full glass of water for $200 (68060) or 100cl 1/3 full glass of water for $10 (Pi Zero2W)? I pick the latter - I will still get 30 times more water for much lower price. Of course, I will loose all the fun of academic discussion how this 1cl glass of water is better than the 100cl glass of water if and only if it had a volume of 300cl and still be full... No, it is not and that's the sad reality :)

@michalsc

Please people, don't start pouring water into your computers, it was just an analogy.

I thought it was needed to clarify it!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

I think Matthey is far too hung up on what the PiStorm is *not* to appreciate it for what it *is*.

The PiStorm+CM4 is not:
1. As fast as a hypothetical 68060 @ 1GHz could be.
2. As fast as equivalent code compiled/optimised for ARM native would be.

The PiStorm+CM4 is:
1. Much faster than the fastest available 68060 @0.1GHz is
2. Much more available than a full 68060 at any clock speed is.
3. Much cheaper than any 68060 compatible accelerator+68060 CPU+Ram is
4. A multipurpose expansion solution providing RTG, WiFi and perhaps soon 3D.
5. All this expansion in a form factor that fits inside and existing A1200.

If you want it carry on the glass 1/3 full analogy, there's ample more water included here: your glass may be 1/3 full but you also get the bottle it was poured from.

I just googled it. I can buy the complete PiStorm lite+CM4+IO adapter (HDMI etc) for around 230 standard earth credits from more than one vendor (assuming I don't want to build it myself) *right now*. With returns if I am not happy.

Compare that experience to eBay fishing for a genuine 68060 CPU alone.

Last edited by Karlos on 22-Feb-2025 at 10:03 AM.

_________________
Doing stupid things for fun...

Karlos Quote:

I disagree with the conclusion. Let's proceed from the assumption that you are correct that typical emulation is 1/3 of native performance (I don't necessarily agree, it varies depending on the task, and tasks vary by user). The question naturally arises, "so what?" We're running 68K code on it, not native.

Loop performance from L1 caches is extremely important to overall performance. Small loops are common for existing 68k code because 68k CPUs do not have to worry about load-to-use stalls and early 68k CPUs had tiny caches. The superscalar 68060 is a very good CPU design that is tolerant of existing 68k code, is tolerant of instruction scheduling and has amazing in-order CPU performance. RISC cores generally need careful instruction scheduling to avoid stalls, schedule instructions for resources and avoid dependencies which requires significant loop unrolling. This was a problem even before RISC cores became superscalar. Consider the scalar 32-bit ARM11@700MHz used in the original RPi.

http://mazsola.iit.uni-miskolc.hu/~drdani/docs_arm/36_Elsevier-ARM_Sy.pdf Quote:

D.8 ARM11 Cycle Timings The ARM11 core uses an eight-stage pipeline with three execute stages. There is usually a two-cycle delay following a load instruction before you can use the data. Some operations such as shift, multiply, and address calculations require their input registers a cycle early. For example, the following code sequence will stall the core for three cycles because the result of the load is not available for two cycles, and the input to the shift is required one cycle early: LDR r0, [r1] ; r0 not available for 2 cycles MOV r2, r0, ASR#3 ; r0 required one cycle early The ARM11 core has a separate address generation unit that can calculate simple addresses in one cycle. More complicated addresses take two cycles. Table D.13 defines the number of address calculation cycles A for each addressing mode.

I will rewrite the ARM11 code with cycles and stalls labeled.

0 LDR r0, [r1] ; r0 not available for 2 cycles
1 load-to-use bubble/stall
2 load-to-use bubble/stall
3 change/use bubble/stall
4 MOV r2, r0, ASR#3 ; r0 required one cycle early

The scalar 8-stage ARM11 only has a 2 cycle load-to-use penalty and only loses one instruction per cycle during the penalty where the superscalar Cortex-A53 has a 3 cycle load-to-use penalty and loses two instructions per cycle during the penalty. Ouch! Instruction scheduling is imperative for good performance and lots of cache wasting loop unrolling when there are not enough instructions to fill the bubble/stall slots. Legacy ARM code like ARM11 code is likely to have instruction scheduling that at least removes 1/3 of the Cortex-A53 3 cycle load-to-use penalty and half of the Cortex-A55 2 cycle load-to-use penalty. A simple translation of 68k code to ARM code is near worst case for load-to-use stalls on the Cortex-A53 because 68k pipelines have never had load-to-use stalls, there was no stall to avoid and 68k code has a better code density as a result. From a technical perspective, this is extremely wasteful and an abomination even if a Cortex-A53@1200MHz is better performance than a 68060@100MHz due to a higher clock speed and more caches. OoO Cortex-A72 cores have better performance but waste a huge amount of resources to bring performance back to 68060 levels.

Year | CPU | transistors/core | cores/CPU | CPU transistors
1994 68060 2,530,000 x1 2,530,000 superscalar in-order 2-way
2002 ARM11 7,500,000 x1 7,500,000 RPi1 scalar
2011 Cortex-A7 10,000,000 x4 40,000,000 RPi2 superscalar in-order 2-way
2012 Cortex-A53 12,500,000 x4 50,000,000 RPi3 64-bit superscalar in-order 2-way
2012 Cortex-A57 75,000,000 x4 300,000,000 64-bit OoO 3-way predecessor of Cortex-A72

For the transistors/area of the RPi 3 CPU with 4xCortex-A53, 19x68060 cores is possible with room for the AA+ chipset. Stronger cores are wanted rather than parallel cores but if all that was done was to increase the L1 cache size of the 68060 to 32kiB I+D and add a memory controller like the ColdFire V5, a 68060 core would still be smaller than a scalar ARM11 core and 4x68060 cores less than half the size of 4xCortex-A53 cores. A single core could be beefed up more if ignoring SMP like 68k to ARM JIT compilation. The 1/3 glass full is actually just for one core but there are 4 cores or glasses so 1/3 of 1/4 or a glass 1/12 full. Once you throw engineering and efficiency out the window, who cares though? Does the Amiga need to have competitive hardware to attract customers? Amiga fans will be lined up to buy 40 year old failing hardware using 50 year old Amiga NMOS silicon to use PiStorm hardware that is more expensive than a RPi 4 that gives 1/12 of the ARM performance for the 68k Amiga when most fans could get more 68k Amiga performance using WinUAE on their x86-64 hardware for free? Do we really need more than Cloanto selling ROMs for WinUAE with Amiga hardware going away and A-Eon, AmigaKit and Hyperion with it?

Karlos Quote:

You could always look into AROS if that's a problem.

No thanks. The Amiga is the elegant 68k Amiga Jay Miner envisioned and developed into a reality including the 68k, chipset and AmigaOS. Move too far from it and it does not appeal to me. I love Jay's vision! Some Amiga fans are happy with a facade outside and x86-64, ARM or PPC inelegant hardware inside. I would rather switch entirely to some other vision, even originally inferior vision, like most Amiga fans. I suppose I am a purist and there is not much left for me in Amiga Neverland.

@matthey

Quote:

The Amiga is the elegant 68k Amiga Jay Miner envisioned and developed into a reality including the 68k, chipset and AmigaOS. Move too far from it and it does not appeal to me

Ahem. The 68060 has almost nothing whatsoever on common with the original 68000 other than the fact it happens to execute the same (well, mostly the same) object code. Everything else about the design and implementation is different.

Enter Emu68. How's is any different, really? It's just another implementation of the 68K ISA. Sorry I'm not sorry that it's not in silico.

The fact is, if someone had smuggled it inside a 68040 pin package and it wasn't revealed that it was a JIT emulation, just a "proprietary high performance 68040 compatible", people would have no idea. But it's not. It's actually much better than that. It's a shame some people's hardware hubris can't get past it.

_________________
Doing stupid things for fun...

@Karlos

Quote:

The fact is, if someone had smuggled it inside a 68040 pin package and it wasn't revealed that it was a JIT emulation, just a "proprietary high performance 68040 compatible", people would have no idea. But it's not. It's actually much better than that. It's a shame some people's hardware hubris can't get past it.

Precisely! My main issue with emulation on my setup isn’t the fact that it’s emulation per se. Rather, it’s that my PC setup doesn’t provide the flawless, consistent experience I had on the Amiga. This inconsistency might not even be due to the emulation itself—it could just as easily be caused by the display I’m using.

My primary concern lies with chipset emulation, particularly when displayed on an LCD monitor. I’d love to see side-by-side comparisons: the ones I’ve encountered so far compared a real Amiga on a CRT to emulation on an LCD. However, I’d rather see the opposite—a real Amiga on an LCD and an emulated setup on a CRT. I wonder if the same issues would appear on an LCD-equipped Amiga, and conversely, whether emulation on a CRT would perform flawlessly.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Its not always what you can see or not see, it’s also a latency issue.

graphics being rendered into a buffer, and then displayed, instead of render directly on the screen, that’s lag of 1 frame, USB can easily have a lag of 1 to 2 frames.

Amiga games were already extremely hard to play, game trainers were pretty much needed on some games. A lot of Amiga games where fast side scrollers.

Perhaps lowres graphics and low refresh rate also adds to the problem.
A pixel moved one way in the wrong direction can mean the difference between being alive or being dead.

While some games it not a big issue, if all you do is play Monkey Island, and Benth a steel sky, Indy and other Role playing adventure games.

Last edited by NutsAboutAmiga on 23-Feb-2025 at 12:46 PM.
Last edited by NutsAboutAmiga on 23-Feb-2025 at 12:45 PM.
Last edited by NutsAboutAmiga on 23-Feb-2025 at 12:45 PM.
Last edited by NutsAboutAmiga on 23-Feb-2025 at 12:42 PM.
Last edited by NutsAboutAmiga on 23-Feb-2025 at 11:04 AM.

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

Karlos Quote:

Ahem. The 68060 has almost nothing whatsoever on common with the original 68000 other than the fact it happens to execute the same (well, mostly the same) object code. Everything else about the design and implementation is different.

Jay Miner not only accepted but wanted newer more powerful 68k CPUs as he wanted the Amiga to go after IBM.

http://www.bambi-amiga.co.uk/amigahistory/jayinterview2.jpg Quote:

'Go after IBM' It was my biggest regret that we did not go after IBM right from the start. I know that sounds weird. But really IBM was very vulnerable just then in the PC market, they had no color or sound and could only address 640k memory. We had a much better machine and a much better processor.

Jay was most interested in hardware that could improve the Amiga value which he understood well.

http://www.bambi-amiga.co.uk/amigahistory/jayinterview3.jpg Quote:

Why was the Amiga a success? It was a success you know, even though it stumbled. The first year it sold almost as many as the Macintosh did in the first year and the Macintosh didn't have all the competition we have now. I believe to be successful you have to give value. Personal success requires giving value to what you do. Product success requires giving value to the product. Companies usually fall when they stop giving value and they become greedy. It wasn't essential to have 256 logic functions in the blitter. It wasn't essential to have 4 DMA channels on the blitter. Or 4 DMA channels of stereo audio. Or eight sprites. Or 4000 colors. Hardware linedraw was definitely overdoing it. People would buy it anyway! I was told this over and over again. To a certain extent it is true. They will buy lesser quality for awhile. And if it is cheap enough. I believe though that eventually the quality product will win. Because costs will come down with time but the quality will still be there. There is a rule of thumb that the your selling price must be three to four times your cost. And this is generally a good rule. However, if I should add another 512k of ram to a product, why should I charge the customer three times what I have to pay for it? It didn't increase the development costs. It didn't increase my marketing costs. This is just another way to gouge the customer instead of giving value. I believe the Amiga is a success because it is a really terrific value!

The 68k Amiga was a success when Commodore delivered value and failed when Commodore stopped delivering value. The PPC AmigaNOne lacked value and compatibility and when PPC died, the old silicon offered less value. Eben Upton delivered value with the RPi which has become a huge success due to aggressively pushing down prices of low end mediocre hardware. A-EonKit sabotages the 68k Amiga even as they move into the low end market themselves and protects their businesses because their hardware does not offer value and the RPi is eating their lunch. Retro Games Limited is getting their lunch eaten by the RPi. The Vamp/AC FPGA hardware is getting their lunch eaten too due to RPi hardware despite someone trying to improve the value of their FPGA CPU into a better value ASIC. Is is easy for an ASIC to compete in the 68k Amiga market. Even a cheap AC68080 SoC FPGA to ASIC conversion would cut the RPi out of the Amiga market. I would prefer a better quality 68k SoC ASIC that could compete with RPi hardware in other markets though. The 68k has unique advantages like a large quality retro 2D game library, performance with code density that Thumb(-2) never had and one of the best and easiest to program ISAs ever. The 68k Amiga is all that is left of the Amiga market yet there is no attempt to create hardware with value. The 68k CPU is 100% CPU utilization 100% of the time on an ARM core and DMA/interrupts are replaced by polling. Jay was all for enhancing the 68k Amiga and improving value but virtual Amigas are not modern 68k Amiga hardware. A virtual 68k Amiga is a good thing for simulation and testing, using Amiga software under a different OS and EOL software support but it is cringe worthy to use as dedicated Amiga hardware and can not deliver value any better than Amiga Nowhere and AmigaNOne.

Karlos Quote:

Enter Emu68. How's is any different, really? It's just another implementation of the 68K ISA. Sorry I'm not sorry that it's not in silico. The fact is, if someone had smuggled it inside a 68040 pin package and it wasn't revealed that it was a JIT emulation, just a "proprietary high performance 68040 compatible", people would have no idea. But it's not. It's actually much better than that. It's a shame some people's hardware hubris can't get past it.

Using emulation for a hardware platform is starting with defeat. Emulation can never deliver the value of native performance in the same way that there are no perpetual machines. Michal is a good developer who has done a good job with Emu68 but even he must realize the limitations. It is not his fault. The ARM ISA and CPU core designs are much different than 68k hardware. The real problems are the saboteurs of the 68k Amiga that ensure 68k Amiga development is a 2nd class citizen even though PPC is more dead than the 68k and the 68k is the only possible way forward due to the size and popularity of the retro 68k market.

It would be possible to shrink an ARM SoC down and deliver it in a 68040/68060 package but it can not deliver competitive general purpose computing value. Let us consider a Cortex-A72@1.8GHz using a 28nm process like the RPi 4. It is already low enough power but may only provide ~68060@500MHz performance. The clock speed could be doubled to 3.6GHz to reach ~68060@1GHz performance which would be very expensive and pushing it even for a 5nm-12nm core and it may not be designed for that small of process. The Cortex-A76 can reach over 3GHz and may provide our target of 68060@1GHz performance with a lower clock speed due to the increased Cortex-A76 performance. Power is still low enough but our transistor count has grown significantly and we are now using a very expensive chip process. I do not expect a commodity single core Cortex-A76 SoC exists and even finding one without a GPU using half the transistors or more and likely bringing the transistor count to more than a billion may be difficult. Using a commodity Cortex-A76 SoC is not so cheap anymore even for the RPi 5 using an older 16nm process that only achieves 2.4GHz. A newer process would have increased the cost but allowed a higher clock speed and lowered the power to save on cooling of the SoC. With an ARM license, we could a la carte using ARM IP design our own single core Cortex-A76 SoC with no GPU that would reduce the area but we still need the expensive process for cooling and our die is still maybe 20-40 times larger than a modernized 68060@1-2GHz SoC using a much cheaper process. Development and production costs may actually be cheaper for the older process and ARM royalties would be avoided giving a production cost advantage. Economies of scale and mass production are required to have any hope of paying for even the older and cheaper licensing and development but keeping costs down is less risky. I suggested the best value route for a quality 68k SoC ASIC. The lowest risk route is to slap an Amiga sticker on ARM hardware for the low end and x86-64 hardware, instead of PPC hardware, for the high end and pretend the facade is real Amiga hardware until the Amiga disappears which is what it looks like A-EonKit intends to do. Jay Miner thought the Amiga had success due to value and quality but then came poor ARM hardware pretending to be 68k Amiga hardware and greedy businesses intent on destroying the 68k Amiga.

@matthey

Quote:

68k and the 68k is the only possible way forward due to the size and popularity of the retro 68k market.

Anything is better then a non existing 680x0 800Mhz / 1Ghz.

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

@matthey

Quote:

Using emulation for a hardware platform is starting with defeat. Emulation can never deliver the value of native performance in the same way that there are no perpetual machines.

No, it's pragmatism in a world where the CPU is dead as a doornail and the only people in the world remotely interested in doing it are all middle aged nerds: us. The native versus emulated performance line is getting tedious. The *real* value a CPU offers is the ability to run software. Emu68 does that. And it does it far more rapidly than all extant 68K CPUs and for much lower cost.

I'm sorry to say it, but your arguments are utterly cringe. You said you don't hate emulation after I said you did, but your post is dripping with thinly veiled derision. You are trapped by a hubris that's denying you the ability to enjoy what we have. There's never been a better time to enjoy a "high end" 68K Amiga experience on the original hardware.

You go on and on and on, at every opportunity, about a 1-2GHz 68060 ASIC, but you cannot accept it's about as likely to happen as me winning the lottery, three consecutive rollovers in a row, despite not actually playing the damn thing.

You remind me of Shaun the Bus Arch Troll, only without the deranged threats of extreme physical violence. He was the same, insisting that Zorro-VII would crush everything. He talked about it as if it was actually real, much like you do with your ASIC.

Could a modern refresh of the 68060 be accomplished? Sure. Can it be accomplished? Extraordinarily unlikely. You can die of old age waiting for it or you can enjoy the fastest 68K compatible accelerator you can put into an Amiga today and make peace with it.

_________________
Doing stupid things for fun...

@Karlos
You say can't before you even tried. I'm surprised you aren't still crawling from saying you can't walk as a baby.

I'm sorry. I walk away with what 68k Amiga hardware is today like hundreds of thousands of Amiga fans. I hope you and a few thousand eternal optimists enjoy your ARM and PPC Frankenmigas. The masses have already voted with their feet. There is nothing to see in Amiga Neverland but a pitiful ending controlled by anti-Jay thinkers.