@Hammer

Quote:

Hammer wrote: @agami My argument was about units sold.

I know, which is why I used your argument about units sold as an opportunity to highlight that market penetration is more important than units sold.

_________________
All the way, with 68k

@kolla

Quote:

kolla wrote: @agami Quote: I want developers to switch away from directly banging hardware and ASM code to developing applications for Amiga OS using C or other higher level languages and let the compiler compile it for 68k+ or 68k+ hybrid with ARM64. Good luck with that. For many, asm (and hardware banging) is the reason why they code software for Amiga at all.

Yes, there will always be those who are in it for that reason. They can have the diminishing pool of functioning OG 68k Amigas and FPGA systems.

My clarion call is aimed at those who desire a true NG Amiga.
People like ppcamiga1 place PowerPC on a pedestal, yet they are not banging the hardware. For them it is a philosophical argument, bordering on religious.

The choice of a virtual 68k CPU is for compatibility with existing games, applications, and subsystems. The virtual 68k CPU, operating with orders of magnitude increase in performance over the physical 68k, should allow for more useful software.
It serves as the bridge to leverage the past to move into the future. Where the same C code, or other language can be compiled for a native ARM64 or x64 system.
A virtual 68k CPU running atop ARM64 or x64 is cheaper than equally performing PowerPC silicon.
Even if we never compile for new non-68k hardware, at least we got developers developing new or porting existing software to make a more useful Amiga computing experience. And maybe we reduce ecosystem fragmentation along the way.

_________________
All the way, with 68k

agami Quote:

These are not similar-enough scenarios to benefit from comparison. The C64U is a nostalgia device. The OG C64 era predated the mainstream adoption of WIMP computing conventions, and so in its compatibility computing play can only have a purely retro context. Here. the authentic UX trumps everything else.

The boundaries are not so well defined. It is surprising what is possible with C64 upgrades. Recall that Commodore upper management did not like that the C65 had a more advanced chipset than the OCS/ECS Amiga, at least in some ways. The MEGA65 with GEOS shows the MEGA65 can handle a mouse driven GUI with ease and at higher resolution than OCS/ECS Amigas.

Is the MEGA 65 worth $666? Full playtest! (where Christian "Peri" Simpson shows GEOS)
https://youtu.be/iWsKpG3fuGg?t=2069

Peri: "It's very Mac like isn't it?" (after switching to 80 column mode)
https://youtu.be/iWsKpG3fuGg?t=2120

Peri: "So now I'm basically using an Amiga, right?" (playing solitaire with a mouse)
https://youtu.be/iWsKpG3fuGg?t=2489

The high resolution 800x600 mode did not work on his 1084S monitor or the MEGA65 would have had higher resolution than an OCS/ECS Amiga. The GEOS desktop is not using many colors because the C64 and C128 GEOS could not use many colors. The solitaire game shows that more colors are not only possible but usable with a mouse driven GUI. There are certainly way more limitations under the hood than the Amiga has but modern technology can bring hardware forward a lot and faithful retro hardware like this and the C64u are much more appealing to retro fans than a C64x. The same is true for the Amiga where 99% of Amiga users rejected the PPC AmigaNOne although it was rejected not just for not being compatible enough but for being much too expensive, nowhere close to competitive and borderline being a scam with false promises like SMP support which is still being worked on after more than a decade. The MEGA65 has a limited ability to be cost reduced with a not so small FPGA, disk drive and spare no expense keyboard and case in comparison to the C64u so it may not be the upgrade for the C64u. A cheaper upgrade path is needed and while an ASIC could lower the price, moving the technology forward further while retaining compatibility becomes difficult. The 68k Amiga tech can be moved much further forward while retaining more compatibility because the 68k Amiga uses the AmigaOS providing abstraction, timing more often uses timers and display timing than CPU loops, WHDLoad with patching fixes problematic software, the 68k makes patching easier, etc. The further forward the tech can move while retaining compatibility, the better value the hardware provides.

agami Quote:

For some, the Amiga is only about nostalgia, But the Amiga legacy also has within it the potential for a revival. Much wasted potential as we all know and as we've watched company after company squander their opportunity. Not to mention the seemingly unending legal drama. For the record, I do not support the original Amiga hardware. I support standardisation as a key underpinning to reincarnating the Amiga spirit. I covet elements of the Amiga UX which I am convinced can be recontextualised into a modern computing paradigm to rival what's on offer from Windows and macOS.

The Amiga goes nowhere without going back to the roots and rebuilding a proper foundation in hardware. The 68k Amiga on foreign hardware with virtual machines is no home for the Amiga masses. Compatibility, price and performance in that order of importance are the keys to an Amiga revival. Of course moving forward is needed too but it is necessary to go back and bring the masses forward or, like PPC AmigaNOne, the Amiga market is left behind.

agami Quote:

I do not care about brands and trademarks. I care more about how a device can augment human abilities than what it's called. I'm not a hardware purist either. While like yourself I think there is also untapped potential in the 68k ISA, and were I to have gazillions of dollars I would throw money at righting that particular wrong, but it's not a hill on my horizon. I'm fine with x64, ARM64, RISC-V, and really anything that is produced in readily available volumes at marketable prices. Can it be part of the solution? Can the solution cost less than the problem?

The 68k has a moderate cost advantage over "x64, ARM64, RISC-V" which need 20%-40% more memory. It was a similar cost advantage with Thumb-2 which allowed RPi to create a market that has sold over 50 million units. This is for native code where a JIT virtual machine to retain compatibility may need 400% more memory judging by the A600GS+ (A600GS+ 4GiB of system memory provides 1GiB for Amiga). ARM is dropping 32-bit Thumb-2 ISA support from application processors which RPi used to gain their market share which creates an opportunity. Also, ARM royalties are a cost disadvantage.

agami Quote:

I'm all stocked up on member berries. I'm not just looking for an alternative to Windows, macOS, Gnome, KDE. I'm yearning for a piece of tech to reignite in me the fire that burned when I was an A1200 user. Which is why I frequent this forum. If I abandoned this last refuge, the computing world of marginally upgraded smartphone clones of clones, and of plateauing desktop operating systems looking to A.I. models for relevance, I fear it will swallow me whole and extinguish the pilot light within.

I understand. It is frustrating to watch incompetent people miss more opportunities than Commodore. Unlike small children, they have been trying to stick a square peg though a round hole for more than a decade. We must have mental problems too even though we appear more sane than most of the remaining Amiga fans on this forum. We stick around as painful as it is to watch the Amiga hopes slip away due to con men. I guess they have been so busy plotting and fighting that they did not notice the ghost town they created for the Amiga 40th anniversary.

@agami

Quote:

agami wrote: @Hammer I know, which is why I used your argument about units sold as an opportunity to highlight that market penetration is more important than units sold.

So, everyone is like you then?

_________________

@matthey

Quote:

The boundaries are not so well defined. It is surprising what is possible with C64 upgrades. Recall that Commodore upper management did not like that the C65 had a more advanced chipset than the OCS/ECS Amiga, at least in some ways. The MEGA65 with GEOS shows the MEGA65 can handle a mouse driven GUI with ease and at higher resolution than OCS/ECS Amigas.

C65 reveal caused AGA R&D to start in 1989. We're not supposed to have AGA.

In early 1983, the system engineering group focused on Unix clone C900 (with Z8001 CPU and Z8010 MMU) and obtained a second source license for the Zilog Z8000 family. The system engineering group's C900 focus has effectively suppressed the real C64 follow-on R&D graphics chipset. The system engineering group has departed from Commodore's core strengths. Note why the CSG LSI team has hidden C65 R&D from the system engineering group's upper management.

Cancelling the C900 Unix adventure didn't remove pro-commercial Unix workstation advocates within the system engineering group. C900's advocates steered the Amiga business towards the C900 mk2 attempt, away from Commodore's core strengths.

Focusing on C900 with its Zilog 8000 family, CSG's 65xx CPU family didn't properly evolve into a 16-bit and 32-bit CPU with MMU, nor did it create a path for the C64's VIC-II graphics chipset successor. The same story is repeated for the Amiga business.

CSG LSI team's VIC-20 and C64 have sustained the bulk of Commodore International's revenue stream.

The system engineering group's administrators didn't properly plan after A500 business and "bet the farm" on A3000 ECS and AT&T Unix-licensed workstations such as A2500UX and A3000UX, coupled with TiGA-based A2410 256-color productivity display card. The system engineering group delivered A2500UX and A3000UX on the market, and it flopped hard. The system engineering group has departed from Commodore's core strengths.

Due to C65's 256 color display chipset reveal and the resulting Henri Rubin's allowing AGA R&D to start in 1989, the CSG LSI team designed AA Lisa and modified ECS Agnus into AA Alice.

During the 1988 Cebit show, Commodore was an active participant in promoting ATI's new VGA+ graphics chipsets over a flicker-free A500 demo. In 1986, Henri Rubin issued a management directive for monochrome high-resolution Denise.

ATI's new graphics chipsets in 1988 were VGA Wonder 256 and VGA Wonder 512.
https://dosdays.co.uk/topics/Manufacturers/ati/ati_vga_wonder_16.php

My info is from the Commodore - The Final Years book.

Quote:

The 68k has a moderate cost advantage over "x64, ARM64, RISC-V" which need 20%-40% more memory. It was a similar cost advantage with Thumb-2 which allowed RPi to create a market that has sold over 50 million units. This is for native code where a JIT virtual machine to retain compatibility may need 400% more memory judging by the A600GS+ (A600GS+ 4GiB of system memory provides 1GiB for Amiga). ARM is dropping 32-bit Thumb-2 ISA support from application processors which RPi used to gain their market share which creates an opportunity. Also, ARM royalties are a cost disadvantage.

In modern times, 68040 doesn't have a cost advantage over "x64, ARM64, RISC-V" when the actual licensed 68040 has a massive performance vs value disadvantage.

Last edited by Hammer on 14-Aug-2025 at 04:22 AM.
Last edited by Hammer on 14-Aug-2025 at 04:16 AM.

_________________

@matthey

Quote:

This is for native code where a JIT virtual machine to retain compatibility may need 400% more memory judging by the A600GS+ (A600GS+ 4GiB of system memory provides 1GiB for Amiga).

It is easy to take a system which support your claim and not mention a system which doesn't:

- A600GS+ with 4GB provides 1GB for Amiga
- Emu68 on Pi with 2GB provides about 1.9GB for Amiga

Or do you mean the fact that A600GS+ is a linux machine with full Amiga emulation (UAE similar or UAE based)? If this is the case then you may add an FPGA providing legacy chipset for compatibility at zero RAM cost.

Last edited by michalsc on 14-Aug-2025 at 05:49 AM.

@agami

Quote:

People like ppcamiga1 place PowerPC on a pedestal, yet they are not banging the hardware. For them it is a philosophical argument, bordering on religious.

And that's why nobody takes ppcamiga1 seriously, including genuine PPC Amiga users. I wonder why people around here still bother replying to his drivel?

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@agami

there are no virtual 68k
emulator is emulator and nothing more than emulator
you were fooled by szulc
use winuae it is cheaper and better

hardware banging it was explained to you many times but you are too stupid to get it
my first amiga was 1200
I started from 256 colors on Amiga
so I don't care about things like sprites, playfields, blitter that was not upgraded to 256 colors

cpu other than these in pc
for pc I have windows tmp since 2001
and ppc allows integration with 68k somethign that x86 and arm not

@Trixie

stop trollin do something usefull

@matthey

68k die 30 years ago
and it will not return
want cheap amiga
stop trolling start working on zune

@ppcamiga1

Ha ha ha!



I guess you don't have many friends, just subjects and underlings! Dr Evil is that you?

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

Hammer Quote:

C65 reveal caused AGA R&D to start in 1989. We're not supposed to have AGA.

Instead of the new Commodore logo "The future we were promised", the logo should be "the future Commodore tried to kill". The C64x is actually closer to the future Commodore's brain dead upper management wanted but maybe some of them changed their minds when commodity PC profit margins turned negative. Medhi Ali was taking credit for his "major operational turnaround" like it was a good thing to cancel unique diversified hardware development and bet the Commodore farm on commodity PC hardware.

Hammer Quote:

In modern times, 68040 doesn't have a cost advantage over "x64, ARM64, RISC-V" when the actual licensed 68040 has a massive performance vs value disadvantage.

I do not know why you say 68040 instead of 68060 but even a scalar 68040 core will outperform an in-order ARM core using JIT emulation of the 68k with the same clock frequency, same caches and the same chip process. It would be underpowered compared to more modern in-order superscalar cores but the original RPi ARM11 core and likely the newer Vortex86 cores use scalar in-order cores. The superscalar 68060 is a better design with more performance potential while not dissipating much more power than the 68040V. With the performance advantage of CISC for integer code, I believe the 68060 could be competitive with RISC superscalar in-order cores for native vs native code after modernization and has the potential to surpass the ARM Cortex-A55 and SiFive 7-series cores in performance. The in-order superscalar Cortex-A510 offers more performance than the Cortex-A55 but the area increase with disappointing power efficiency (performance/W) makes it not a worthwhile upgrade unless newer E-cores are required as companions for newer P-cores in DynamIQ/big.LITTLE configurations. The Cortex-A520 upgrade dropped support for 32-bit ARM ISAs which increases memory footprints and system costs without Thumb-2 which has similar code density to the 68k. Most embedded users want a cheap power efficient in-order superscalar core and that remains the Cortex-A55 for ARM. The SiFive 7-series cores have a better CISC/68060 like design than the Cortex-A55 and has code compression but the RISC-V ISA is weaker.

michalsc Quote:

It is easy to take a system which support your claim and not mention a system which doesn't: - A600GS+ with 4GB provides 1GB for Amiga - Emu68 on Pi with 2GB provides about 1.9GB for Amiga Or do you mean the fact that A600GS+ is a linux machine with full Amiga emulation (UAE similar or UAE based)? If this is the case then you may add an FPGA providing legacy chipset for compatibility at zero RAM cost.

My point is that the system memory footprint requirements are increased by several times with JIT. Sure, if the memory is not used, most remains available. Fill up the memory by using it, and it does not go nearly as far with JIT. I have seen the conversion of Emu68 68k code to AArch64 code and the code size in JIT buffers expands far more than the code density difference which is substantial (AArch64 code can be 50% larger than 68k code). I expect the code size is closer to doubling on average and the original 68k program is likely kept in memory as well. JIT buffers can be decreased to a minimum but this reduces performance and reduced performance is a major problem of emulation too. Someone once talked about emulation having 20% of the core performance of native (80% of the performance is lost). It was described as paying for a 200km/hour Ferrari and receiving a 40km/hour moped. The value of CPU cores using JIT is gone much like with a 40km/hour Ferrari that nobody would buy and the larger memory footprint increases the cost/price further decreasing the value. Emulation is EOL support when more competitive hardware with better value is needed to enlarge the Amiga user base.

An early C64 slogan was "You can't buy a better computer at twice the price". Commodore used to be about value. AmigaNOne hardware could have had a slogan of "You can buy twice the computer at half the price, elsewhere" but it is much worse than that today. The AmigaNOne value has become so absurd that JIT emulation on RPi hardware actually competes with AmigaNOne hardware. This does not mean that JIT is competitive with commodity hardware in an open market. It just means that the Amiga market is not open and AmigaNOne hardware is becoming extinct or rare for bastard Amiga hardware elite collectors as "Computers for the classes, not the masses." RPi produces the "computers for the masses, not the classes" today. Eben Upton was a Commodore Amiga user and understood value enough to aggressively reduce RPi product prices while Trevor produced expensive pie in the sky "desktop" bastard Amiga hardware. Ironically, 68k Amiga hardware is much more like RPi hardware than Trevor's AmigaNOne "desktop" hardware. Eben sold ~50 million units to Trevor's ~5000 units but never give up on a decade old failed business model when there are more unsold AmigaNOne computers and another lost Trevor decade underway.

Last edited by matthey on 14-Aug-2025 at 08:00 PM.

@matthey

Quote:

matthey wrote: ... even a scalar 68040 core will outperform an in-order ARM core using JIT emulation....

All this hardware babbling is useless, you can't buy new 68040.
And a Vampire/Apollo is much more expensive than a ARM system.

And Perifractic or the "Let's Buy Commodore" Project won't change that

Last edited by OneTimer1 on 14-Aug-2025 at 08:17 PM.

@ppcamiga1

Quote:

emulator is emulator and nothing more than emulator you were fooled by szulc

I think he is just much more smarter than you and can clearly see that you are the liar here. All you say about emu68 are lies - everyone who looks at emu68 source codes sees that you are just a liar, nothing more.

@matthey

Quote:

JIT buffers can be decreased to a minimum but this reduces performance and reduced performance is a major problem of emulation too.

Please do me a favor and find m68k application which causes emu68 JIT cache to be filled more than by 20%, then we will talk.

I don't know if you ever saw emu68 in action but it provides performance counters - some of them tell you in real time how often the JIT translator is triggered. And, guess what, for most of the time this counter stays at...

0 translations per second

... meaning, all the code that is running is already translated to aarch64. And the Emu68 JIT cache is filled maybe in 10%. The rest of the JIT cache is EMPTY. Meaning, I could eventually give another 32 megabytes of RAM or so to AmigaOS.

So, forgive me my ignorance, I have no idea what you were trying to say there...

OneTimer1 Quote:

All this hardware babbling is useless, you can't buy new 68040. And a Vampire/Apollo is much more expensive than a ARM system.

Large FPGAs can not compete against ASICs. I realized this long before PiStorms were killing Vamp/AC sales. An ASIC is required to compete and it would cost millions of dollars but then the market is no longer 10,000 units at the much lower price with much higher performance. Eben Upton only planned for 1,000 units for the first RPi production run.

'We thought we'd sell 1,000': The inside story of the Raspberry Pi
https://www.zdnet.com/article/we-thought-wed-sell-1000-the-inside-story-of-the-raspberry-pi/ Quote:

The 34-year-old chip architect is genuinely taken aback that demand for the Raspberry Pi proved to be orders of magnitude larger than a small pool of aspiring UK computer engineers. "We honestly did think we would sell about 1,000, maybe 10,000 in our wildest dreams. We thought we would make a small number and give them out to people who might want to come and read computer science at Cambridge," he told ZDNet. The first inkling of the fervour the credit card-sized board would create came in May 2011, when the first public outing of the Pi in a BBC video generated some 600,000 views on YouTube. Upton and his colleagues revised their initial run of boards up to 10,000, thinking that would be more than enough to meet demand. It wasn't. The 10,000 boards sold out within hours of going on sale in February last year, with an incredible 100,000 boards ordered on that first day.

The single scalar ARM11@700MHz CPU core with 256MiB memory and a low power GPU barely surpassed a high end 68060 Amiga specs other than the much better 40nm chip process and tens of millions more transistors. It was good enough to compete due to the low price and created a market of 50+ million units though. It was easier to use off the shelf commodity SoCs but then they had to compete with others using the same chips. It would have been better to have a more unique SoC than competitors. Commodore thought commodity PC hardware was better too until they realized they had no pricing control and found out their own custom ASICs had better margin. The grass is always greener on the other side of the fence, right?

OneTimer1 Quote:

And Perifractic or the "Let's Buy Commodore" Project won't change that

I am not so sure. Peri is bold and shaking things up. He has been successful at raising money, making deals and selling products he promotes (some of his videos have reached 1 million views which is more than original RPi videos before selling 100,000 units on day one but price is very important). Commodore should have sold off their fab to become a fabless semiconductor developer. Peri could partner with Western Design Center and produce Arduino style Commodore 8-bit ASIC MCUs with retro features. Everyone thinks the 8-bits are dead end but they may actually go further than the 32-bit 68k Amiga with the right leadership and deals vs the sabotage of the 68k Amiga market. The 68k Amiga has much more potential but it would cost more to realize the potential. The 68k Amiga was the future for Commodore and a modern Amiga would feel modern.

@michalsc
The memory footprint of the 68k Amiga is tiny so the system memory could be decreased to reduce the SBC price, but only so far with JIT. You may look at the RPi you use and think it is cheap enough with the memory it has but reducing the memory and knocking $10€ off the price of the SBC will boost sales. A 1GiB A1200 with case and keyboard that sells for under $100€ may sell hundreds of thousands more units than a 2GiB A1200 that costs over $100€. The factors that increase memory requirements add up. JIT, 64-bit ISA, 64-bit OS, Linux, two OSs at once, etc., increase memory by more than a little bit. Many SBCs with 64-bit CPUs that use 64-bit Linux require 4GiB for full performance and some come with 8GiB making it challenging for just the SBC to be priced under $100€. A 1GiB 68k Amiga SBC should be able to be priced in the $30€ to $50€ range with mass production which should leave room for an A1200 to be mass produced for around $100€ (RPi 400 is $70 USD but uses a cheaper keyboard). Do not underestimate the magic price points and Christmas toy pricing.

Last edited by matthey on 14-Aug-2025 at 10:39 PM.
Last edited by matthey on 14-Aug-2025 at 08:56 PM.
Last edited by matthey on 14-Aug-2025 at 08:39 PM.

@OneTimer1

Quote:

OneTimer1 wrote: All this hardware babbling is useless, you can't buy new 68040. And a Vampire/Apollo is much more expensive than a ARM system. And Perifractic or the "Let's Buy Commodore" Project won't change that

1. For $268.24, a legal entity can buy a licensed 25 MHz 68040 from Rochester Electronics. https://www.rocelec.com/part/01t4w00000PPjCOAA1-MC68040RC25A

For $301.23, a legal entity can buy a licensed 33 MHz 68040 from Rochester Electronics.
https://www.rocelec.com/part/01t4w00000PPjCRAA1-MC68040RC33A

A legal entity can buy a new 68040 from Rochester Electronics.

Rochester Electronics was founded by a former long-time Motorola employee. He passed away, and his sons are running the company.


2. TheA500mini's Amiga IP is licensed from Cloanto. My point, the new CIC can obtain a license from Cloanto/Amiga Corp.

Last edited by Hammer on 15-Aug-2025 at 03:32 AM.
Last edited by Hammer on 15-Aug-2025 at 12:11 AM.
Last edited by Hammer on 15-Aug-2025 at 12:10 AM.
Last edited by Hammer on 15-Aug-2025 at 12:10 AM.

_________________

@matthey

Quote:

Instead of the new Commodore logo "The future we were promised", the logo should be "the future Commodore tried to kill". The C64x is actually closer to the future Commodore's brain dead upper management wanted but maybe some of them changed their minds when commodity PC profit margins turned negative. Medhi Ali was taking credit for his "major operational turnaround" like it was a good thing to cancel unique diversified hardware development and bet the Commodore farm on commodity PC hardware.

Reminder, the original CIC doesn't own Motorola's IP. CIC is free to purchase 68K CPUs from other vendors.

Note that C64 has Microsoft's "Basic" IP as its CLI. The value added was CSG's 65xx CPU, VIC-II, and SID chips, and the large-scale buying strength of CIC, which benefits the customer.


Quote:

I do not know why you say 68040 instead of 68060 but even a scalar 68040 core will outperform an in-order ARM core using JIT emulation of the 68k with the same clock frequency,

That's not a real situation. High clock speed is a designed feature.


Quote:

It would be underpowered compared to more modern in-order superscalar cores but the original RPi ARM11 core and likely the newer Vortex86 cores use scalar in-order cores

DMP Electronics Inc. sells a range of Vortex86 models, which include SIMD extensions e.g. Vortex86DX3 (1Ghz, SMP dual core, H.264 1080p video decode), including MMX and SSE CPU SIMD extensions. https://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=63347

Unlike the 68060 situation, there's a proper corporate R&D backing for the Vortex86 series.

NXP and STM added 16-bit instructions for the PPC 200 series, hence they wouldn't be returning to 68K.

Quote:

I believe the 68060 could be competitive with RISC superscalar in-order cores for native vs native code after modernization and has the potential to surpass the ARM Cortex-A55 and SiFive 7-series cores in performance

ARM and SiFive are not bound by your artificial comparison limitation.


Quote:

he in-order superscalar Cortex-A510 offers more performance than the Cortex-A55 but the area increase with disappointing power efficiency (performance/W) makes it not a worthwhile upgrade unless newer E-cores are required as companions for newer P-cores in DynamIQ/big.LITTLE configurations. The Cortex-A520 upgrade dropped support for 32-bit ARM ISAs which increases memory footprints and system costs without Thumb-2 which has similar code density to the 68k. Most embedded users want a cheap power efficient in-order superscalar core and that remains the Cortex-A55 for ARM. The SiFive 7-series cores have a better CISC/68060 like design than the Cortex-A55 and has code compression but the RISC-V ISA is weaker.

68060 has a complex design when compared to RISC-V.

SiFive U74 supports fused multiply-add (FMA) while 68060 does not support it.

68060 supports fused (implied) data load with math operations, while SiFive U74 does not support it.

SiFive U74 supports RV64FD 64-bit ISA, while 68060 does not support 64-bit ISA.

ARM Cortex-A55 supports fused multiply-add (FMA) and NEON SIMD. SIMD is effectively arithmetic instruction compression i.e. one instruction with 4 or 8 math data operations vs 68060's four scalar or eight scalar math operations.

68060's unimplemented integer instructions (notably 64-bit MUL/DIV) needed to be emulated.

SiFive has P550 microarchitecture, not just U74.

Other companies, such as NVIDIA and Western Digital have implemented in-house RISC-V MPU microarchitectures, not 68060.

Western Digital's SweRV (RV32) core is open source, while 68060 is not open source.

Last edited by Hammer on 15-Aug-2025 at 07:41 AM.
Last edited by Hammer on 15-Aug-2025 at 07:40 AM.
Last edited by Hammer on 15-Aug-2025 at 07:35 AM.
Last edited by Hammer on 15-Aug-2025 at 07:27 AM.

_________________

I hope the new owners of Commodore will let the MEGA65 team use the Commodore 65 name

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@ppcamiga1

Quote:

there are no virtual 68k emulator is emulator and nothing more than emulator you were fooled by szulc

Firmware-based translators with CPUs have existed, such as Transmeta CPUs.

AMD's K5 processor's execution core is based on Am29000 (29k) RISC processor architecture. The K5 combined an x86 decoder front-end with this RISC-based execution core, allowing it to translate x86 instructions into RISC-like instructions for processing.

Prior to 68040, 68K heavily used firmware microcode ROM with a simple CPU core.

Quote:

use winuae it is cheaper and better

WinUAE is just software.

_________________