cdimauro Quote:

Actually, 68k is the only thing where it makes sense to invest on. First of all, and as you've pointed out, there's nothing from the "successors" (!) which is missing or that can't be backported to the Amiga OS. In fact, they are essentially reimplementations of the same OS / APIs / platform.

Back porting to the 68k would likely be the easiest architecture to port to for MorphOS and AmigaOS 4. This would break compatibility with PPC MorphOS and PPC AmigaOS 4 so API changes could be made. The highest priority API changes would be the ones that increase compatibility with the 68k AmigaOS and software. A return to the 68k would unify MorphOS and AmigaOS 4 as they would need to use the same base for compatibility and modules from both could be used where names were not conflicting. I am not so sure MorphOS and AmigaOS 4 could survive as distinct OSs on the 68k. AROS 68k would add competition and being free would drive down the price that could be charged for a 68k AmigaOS. It would save time to use the best parts of whatever OS modules are available for an official, enhanced, and unified 68k AmigaOS. The only division may be a 68k64 AmigaOS version and the 32-bit 68k AmigaOS should still work on the same hardware.

cdimauro Quote:

Second, and even more important, technology has been slowing down for some time and will stop at some point. The Ghz race is a prime example. The race for IPC is another. Performance is, therefore, destined to flatten out and reach its natural limit. By this I am mainly referring to single core/thread performance, which is by far the most important when it comes to emulation and Amiga in particular. Yes, there will always be more cores available (again, until we saturate the space in which to stack them), but they are of little or no relevance to the Amiga. The implications of it all are that the best performing emulation there can be, at present and in the future, will reach a certain level of performance, and stop (whatever processor is used: x64 or ARM64, it makes no difference at all). And there will be nothing else that can be done. In such a situation the only way to get high performance for Amiga (and thus, by definition, 68k) applications will be to run them... on a modern 68k processor. Which will not suffer from the price to pay of emulation, because... there will be none (no intermediate layer). Even without reaching the current 6Ghz and the 8-10 instructions per clock cycle (theoretical), a discrete implementation of a 68k processor will undoubtedly do much better, and at much lower cost (and consumption). But, of course, it will have to be invested in...

I agree. Some Amiga people think the advantages of an Amiga virtual machine make them an alternative to ASICs but AmigaNOwhere and JAVA byte code are dead. Some Amiga people think the advantages of FPGA and more flexible CPU cores make them an alternative to ASICs but Transmeta, Itanium and Denver(2)/Carmel are dead VLIW code morphing microarchitectures and FPGA CPU cores are only used for low volume low end customized embedded SoCs where performance and power are not priorities. Some Amiga people think "the price to pay of emulation" is acceptable but it is steep with a fraction of the CPU performance and several times the resource/memory usage. PPC was forced into the embedded market as a replacement for the 68k but it was easily beaten by ARM Thumb licensed from Hitachi SuperH and poorly copied from the 68k. The RPi was a success because Thumb(-2) allowed small footprint hardware that was very cheap to produce.

memory | use
0.25MiB 32-bit 68000+OCS+AmigaOS original, RPi Pico with no OS or GUI
0.5MiB 32-bit 68000+OCS+AmigaOS standard, RPi Pico 2 with no OS or GUI
1MiB 32-bit 68000+ECS+AmigaOS standard
2MiB 32-bit 68020+AGA+AmigaOS standard
4MiB
8MiB
16MiB
32MiB
64MiB
128MiB Efika 32-bit PPC+MorphOS
256MiB RPi 32-bit Linux
512MiB
1024MiB RPi 64-bit Linux possible but 32-bit Linux recommended
2048MiB RPi 64-bit Linux

Efika with MorphOS was the cheapest PPC hardware for NG but it was handicapped with such small memory, likely worse than RPi 32-bit Linux with 256MiB and RPi 64-bit Linux with 1024MiB (1GiB). A 128MiB 68k Amiga is far more memory than every 68k Amiga ever made and more than most 68k accelerators. The RPi would likely not exist without the ability to scale down to 256MiB where competition was minimal but the 68k AmigaOS with GUI can scale down lower to a RPi Pico footprint where RPi has no OS or GUI. The 68k AmigaOS has a smaller footprint than 32-bit Linux allowing it to scale lower and ARM is abandoning their standard 32-bit Cortex-A support opening up more opportunities for the 68k Amiga. The 32-bit 68k can impress people down here and there is a large library of 68k software including the best retro 2D gaming in existence. RPi was successful by aggressively pushing down the price of the RPi and a 68k Amiga has cost advantages to push down the production cost and price more. "But, of course, it will have to be invested in...", more so than with easier commodity and a la carte ARM. Producing competitive compatible hardware is a better investment than investing in branding for noncompetitive and less compatible hardware.

#6 Quote:

Additional note for what it's worth: 155,000 views and over 2100 comments on the Commodore vid so far. Reddit and the other sites mentioned continue to gather comments.

Just for comparison purposes.

Can We Save COMMODORE? My Biggest Project Yet
Retro Recipes
https://www.youtube.com/watch?v=lN8r4LRcOXc
158K views 3 days ago
2,205 Comments

68000 - The CPU ahead of its time
https://www.youtube.com/watch?v=njGWWg69B4A
Modern Vintage Gamer
334K views 1 month ago
1,391 Comments

MorphOS Mirari OpenLara HighRes Test 01
https://www.youtube.com/watch?v=ERk7nOWThig
mad skateman
487 views 8 days ago
Comments are turned off.

The Commodore video is not only on a much faster views pace than the 68000 video but the comment ratio is much higher. Personally, I believe the Modern Vintage Gamer video is better but less controversial as he is not trying to resurrect the 68k like Peri is trying to resurrect the Commodore brand. MVG is specifically targeting 68000 gaming where Peri is targeting a wider Commodore audience. The MorphOS Mirari OpenLara/Tomb Raider video shows the interest in retro gaming on what some people consider an affordable PPC board for MorphOS.

Last edited by matthey on 10-Jun-2025 at 09:50 PM.

@matthey

Quote:

matthey wrote: Some Amiga people think the advantages of an Amiga virtual machine make them an alternative to ASICs but AmigaNOwhere and JAVA byte code are dead.

I state these things not as an alternative to a 68k-based SoP/SoC, but as a set of software deliverables achievable with the currently available Amiga-oid developers, and without a major monetary investment.

Growing a development/user community for Amiga-inspired apps using the M68k ISA on software cores is a way to prove a market that would justify the investment in the “68k ASIC�.

A business plan that doesn’t rely on “if you build it, they will come�, rather the reverse with “they’re here, time to build it�.

_________________
All the way, with 68k

@cdimauro

Quote:

cdimauro wrote: @agami There's already Java for something like that. And C#/.NET from Microsoft. People like to reinvent the wheel, but the new wheel should have a significant value, otherwise it's pointless to use it. Then why don't just use WASM for this low-level infrastructure? It's exactly there for what you want to do. If everything is only and all about toolkits, frameworks, and something like that, then we don't need a new one: just pick one of the existing and stick with it, creating an Amiga-like environment.

Outside of J2EE for enterprise web apps, the OG Java is for all intents and purposes abandonware. Yes, Oracle keeps supporting legacy applications with patches and updates to the SDK and JRE, but no one is building new personal computing desktop apps with Java.

WASM too is web apps centric and using it for desktop apps is not ideal as people expect portable apps to behave like 1st class desktop apps.

Java is a concept from the ‘90s. Three decades on I think is a good amount of time to look at reinventing that particular wheel. Specifically for desktop environment apps, so that unlike Electron apps they feel and behave more like native desktop apps.

And when I advocate for a new take on an old concept, I don’t mean to imply that this is written from scratch. Almost nothing in today’s day and age in computing should be written from scratch. Combine as many existing free and licensable systems to achieve the desired outcome. Which in our case provides developers with more freedom and flexibility than Microsoft’s Windows and Apple’s macOS SDKs, as we would need a percentage of those developers to prefer this Amiga-inspired portable app framework. So not re-inventing the wheel, rather modifying wheels for a new class of vehicle.

Amiga compatible systems need a better option for desktop app development, between C on one end and Hollywood on the other end.

_________________
All the way, with 68k

@matthey

Quote:

I agree. Some Amiga people think the advantages of an Amiga virtual machine make them an alternative to ASICs but AmigaNOwhere and JAVA byte code are dead.

Web Assembly (abbreviated as Wasm) is a low-level bytecode format. Google learns from its lesson its legal fight with Oracle/Sun's Java IP.

"The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environment".


Quote:

Some Amiga people think the advantages of FPGA and more flexible CPU cores make them an alternative to ASICs but Transmeta, Itanium and Denver(2)/Carmel are dead VLIW code morphing microarchitectures and FPGA CPU cores are only used for low volume low end customized embedded SoCs where performance and power are not priorities

PC GPUs still has LLVM JIT compiler driver stack. Game consoles avoid these CPU side overheads.

On PC CPU front, DRM protection such as DENUVO virtual instruction set is a software CPU with a virtual instruction set.

A 2017 study by Overlord Gaming found that games using Denuvo had an average 15% reduction in frame rate compared to the same games without Denuvo. It's similar overheads from the best Web Assembly virtual machine.

DENUVO's overheads can be reduced depending on the game developer's DENUVO virtual processor usage.

The PC master race is brute forcing this Denuvo's virtual CPU instruction set. VMprotect is a similar PC DRM product.

Game consoles have a proper walled garden DRM which largely avoids PC's DRM resource overheads.

Gaming PC CPUs with large caches has a significant advantage with brute forcing DENUVO DRM performance.

Windows 11 games from MS Store have adopted hardware virtual machine encryption methods.

https://www.techpowerup.com/238377/cpus-bear-brunt-of-ubisoft-deploying-vmprotect-above-denuvo-for-ac-o?cp=3
Some so-called AAA game developers like Ubisoft combines DENUVO and VMprotect for 2017 era CPU crushing DRMs. This is not a problem with current generation gaming CPUs.

Last edited by Hammer on 11-Jun-2025 at 04:35 AM.
Last edited by Hammer on 11-Jun-2025 at 04:30 AM.
Last edited by Hammer on 11-Jun-2025 at 04:21 AM.
Last edited by Hammer on 11-Jun-2025 at 04:07 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:

matthey wrote: cdimauro Quote: Actually, 68k is the only thing where it makes sense to invest on. First of all, and as you've pointed out, there's nothing from the "successors" (!) which is missing or that can't be backported to the Amiga OS. In fact, they are essentially reimplementations of the same OS / APIs / platform. Back porting to the 68k would likely be the easiest architecture to port to for MorphOS and AmigaOS 4. This would break compatibility with PPC MorphOS and PPC AmigaOS 4 so API changes could be made. The highest priority API changes would be the ones that increase compatibility with the 68k AmigaOS and software. A return to the 68k would unify MorphOS and AmigaOS 4 as they would need to use the same base for compatibility and modules from both could be used where names were not conflicting.

MorphOS, OS4 and AROS introduced new APIs which made the three OSes incompatible each other, since they used the same LVOs for completely different APIs.

However, an Amiga OS could borrow them and make it easy to recompile the existing applications coming from those OSes.

The only and major problem is represented by OS4, which introduced and heavily used the so called interfaces and shared objects, that are far away from the Amiga OS (which never needed them, anyway: libraries were invented since day zero to fully share the code).
Quote:

I am not so sure MorphOS and AmigaOS 4 could survive as distinct OSs on the 68k.

Are they needed on 68k?
Quote:

AROS 68k would add competition and being free would drive down the price that could be charged for a 68k AmigaOS.

You're assuming that you can use the Amiga OS, but actually AROS/68k is the only option for a project like that.
Quote:

It would save time to use the best parts of whatever OS modules are available for an official, enhanced, and unified 68k AmigaOS.

Likely, you can't. With the exception of AROS, which is open source and fully (re)usable, OS4 and MorphOS have different rights holders on parts of the OSes that might not be interested on giving them for a 68k OS.
Quote:

The only division may be a 68k64 AmigaOS version and the 32-bit 68k AmigaOS should still work on the same hardware.

That's very difficult to achieve. The Amiga OS has still large parts in assembly, which would need to be converted to such 68k64. Here, it'd be better to use AROS and port it to 68k64 .

Another important thing is how the 68k64 Amiga OS would work / interact with the existing 68k code base. That's the major problem to solve IMO (IF there's a solution for that).
Quote:

cdimauro Quote: Second, and even more important, technology has been slowing down for some time and will stop at some point. The Ghz race is a prime example. The race for IPC is another. Performance is, therefore, destined to flatten out and reach its natural limit. By this I am mainly referring to single core/thread performance, which is by far the most important when it comes to emulation and Amiga in particular. Yes, there will always be more cores available (again, until we saturate the space in which to stack them), but they are of little or no relevance to the Amiga. The implications of it all are that the best performing emulation there can be, at present and in the future, will reach a certain level of performance, and stop (whatever processor is used: x64 or ARM64, it makes no difference at all). And there will be nothing else that can be done. In such a situation the only way to get high performance for Amiga (and thus, by definition, 68k) applications will be to run them... on a modern 68k processor. Which will not suffer from the price to pay of emulation, because... there will be none (no intermediate layer). Even without reaching the current 6Ghz and the 8-10 instructions per clock cycle (theoretical), a discrete implementation of a 68k processor will undoubtedly do much better, and at much lower cost (and consumption). But, of course, it will have to be invested in... I agree. Some Amiga people think the advantages of an Amiga virtual machine make them an alternative to ASICs but AmigaNOwhere and JAVA byte code are dead. Some Amiga people think the advantages of FPGA and more flexible CPU cores make them an alternative to ASICs but Transmeta, Itanium and Denver(2)/Carmel are dead VLIW code morphing microarchitectures and FPGA CPU cores are only used for low volume low end customized embedded SoCs where performance and power are not priorities. Some Amiga people think "the price to pay of emulation" is acceptable but it is steep with a fraction of the CPU performance and several times the resource/memory usage. PPC was forced into the embedded market as a replacement for the 68k but it was easily beaten by ARM Thumb licensed from Hitachi SuperH and poorly copied from the 68k. The RPi was a success because Thumb(-2) allowed small footprint hardware that was very cheap to produce. memory | use 0.25MiB 32-bit 68000+OCS+AmigaOS original, RPi Pico with no OS or GUI 0.5MiB 32-bit 68000+OCS+AmigaOS standard, RPi Pico 2 with no OS or GUI 1MiB 32-bit 68000+ECS+AmigaOS standard 2MiB 32-bit 68020+AGA+AmigaOS standard 4MiB 8MiB 16MiB 32MiB 64MiB 128MiB Efika 32-bit PPC+MorphOS 256MiB RPi 32-bit Linux 512MiB 1024MiB RPi 64-bit Linux possible but 32-bit Linux recommended 2048MiB RPi 64-bit Linux Efika with MorphOS was the cheapest PPC hardware for NG but it was handicapped with such small memory, likely worse than RPi 32-bit Linux with 256MiB and RPi 64-bit Linux with 1024MiB (1GiB). A 128MiB 68k Amiga is far more memory than every 68k Amiga ever made and more than most 68k accelerators. The RPi would likely not exist without the ability to scale down to 256MiB where competition was minimal but the 68k AmigaOS with GUI can scale down lower to a RPi Pico footprint where RPi has no OS or GUI. The 68k AmigaOS has a smaller footprint than 32-bit Linux allowing it to scale lower and ARM is abandoning their standard 32-bit Cortex-A support opening up more opportunities for the 68k Amiga. The 32-bit 68k can impress people down here and there is a large library of 68k software including the best retro 2D gaming in existence. RPi was successful by aggressively pushing down the price of the RPi and a 68k Amiga has cost advantages to push down the production cost and price more. "But, of course, it will have to be invested in...", more so than with easier commodity and a la carte ARM. Producing competitive compatible hardware is a better investment than investing in branding for noncompetitive and less compatible hardware. #6 Quote: Additional note for what it's worth: 155,000 views and over 2100 comments on the Commodore vid so far. Reddit and the other sites mentioned continue to gather comments. Just for comparison purposes. Can We Save COMMODORE? My Biggest Project Yet Retro Recipes https://www.youtube.com/watch?v=lN8r4LRcOXc 158K views 3 days ago 2,205 Comments 68000 - The CPU ahead of its time https://www.youtube.com/watch?v=njGWWg69B4A Modern Vintage Gamer 334K views 1 month ago 1,391 Comments MorphOS Mirari OpenLara HighRes Test 01 https://www.youtube.com/watch?v=ERk7nOWThig mad skateman 487 views 8 days ago Comments are turned off. The Commodore video is not only on a much faster views pace than the 68000 video but the comment ratio is much higher. Personally, I believe the Modern Vintage Gamer video is better but less controversial as he is not trying to resurrect the 68k like Peri is trying to resurrect the Commodore brand. MVG is specifically targeting 68000 gaming where Peri is targeting a wider Commodore audience. The MorphOS Mirari OpenLara/Tomb Raider video shows the interest in retro gaming on what some people consider an affordable PPC board for MorphOS.

I think that there's market for everything: from FPGA to emulators, from virtualizers to ASICs.

What's clear from those numbers is that people are interested on 68k. No doubt on that. This is our heritage: it's the one we are fond of and is the one we want to use.

The good old games are a good part for that, and they demand a fully retro-compatible platform --> 68000 + perfect chipset.

However, solutions like Apollo 68080 before and PiStorm/Emu68 after show that people want also to have more. Much more.

If it had only been for RTG and AHI, people would have been content with what was already there (FPGAs and emulation), but reality has turned out to be quite different: people want more and are willing to spend, even a lot, to get it.

That's the reason why I see space for an ASIC SoC/platform (which embeds a small FPGA for implementing chipsets for some platforms) with a high performance 68k (united to a 68000 for full backward-compatibility) to give them even much more, that the existing solutions can never give them (for the reasons that I've explained on my previous post).

@agami

Quote:

agami wrote: @cdimauro Quote: cdimauro wrote: @agami There's already Java for something like that. And C#/.NET from Microsoft. People like to reinvent the wheel, but the new wheel should have a significant value, otherwise it's pointless to use it. Then why don't just use WASM for this low-level infrastructure? It's exactly there for what you want to do. If everything is only and all about toolkits, frameworks, and something like that, then we don't need a new one: just pick one of the existing and stick with it, creating an Amiga-like environment. Outside of J2EE for enterprise web apps, the OG Java is for all intents and purposes abandonware. Yes, Oracle keeps supporting legacy applications with patches and updates to the SDK and JRE, but no one is building new personal computing desktop apps with Java.

I agree. Java isn't certainly the technology to use for building a new Amiga platform.
Quote:

WASM too is web apps centric and using it for desktop apps is not ideal as people expect portable apps to behave like 1st class desktop apps.

WASM is also desktop apps.

I really don't like how they have designed the architecture (especially for the encoding of integers), however this is just my personal opinion: the technology is there, it's being used and it's gaining consensus, so it's a valid candidate.
Quote:

Java is a concept from the ‘90s. Three decades on I think is a good amount of time to look at reinventing that particular wheel. Specifically for desktop environment apps, so that unlike Electron apps they feel and behave more like native desktop apps.

Electron isn't so bad. It depends on how it's used. MS Teams made an horrible use of it, whereas Visual Studio Code has shown how a very complex GUI applications can be built on top of it, while keeping everything smooth and performant.

But I think that it's a bit distant from the purpose a new Amiga platform.
Quote:

And when I advocate for a new take on an old concept, I don’t mean to imply that this is written from scratch. Almost nothing in today’s day and age in computing should be written from scratch. Combine as many existing free and licensable systems to achieve the desired outcome. Which in our case provides developers with more freedom and flexibility than Microsoft’s Windows and Apple’s macOS SDKs, as we would need a percentage of those developers to prefer this Amiga-inspired portable app framework. So not re-inventing the wheel, rather modifying wheels for a new class of vehicle.

Then... which wheels should be used?
Quote:

Amiga compatible systems need a better option for desktop app development, between C on one end and Hollywood on the other end.

Hollywood is just a wrapper around Lua and some libraries, which... are written in C.

So, what should really be the next, big (!), Amiga thingy?

@ppcamiga1

Notice how we all are united against you! Success!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

agami Quote:

I state these things not as an alternative to a 68k-based SoP/SoC, but as a set of software deliverables achievable with the currently available Amiga-oid developers, and without a major monetary investment. Growing a development/user community for Amiga-inspired apps using the M68k ISA on software cores is a way to prove a market that would justify the investment in the “68k ASIC�.

I respectfully disagree. The only place the 68k Amiga virtual machine is succeeding is as EOL support for a dead platform. The user base is likely growing somewhat due to the increased accessibility of affordable 68k Amiga virtual machines but there is minimal development beyond compatibility for an EOL and dead platform. In some ways, the 68k Amiga platform is declining. Commodore upgraded the AmigaOS to the 68020 ISA which improves performance and code density on 32-bit CPUs but the Hyperion 68k AmigaOS is back to the 16-bit 68000. I tried to introduce 68k ISA improvements years ago which would have increased performance, improved code density and made compiler development easier but EOL retro guys were not interested and Gunnar wanted a proprietary 68k ISA shooting down my ColdFire addition suggestions only to add them back later. The 68k and Amiga compilers are mostly not getting better as there is no reason to improve them for an EOL virtual machine. There is not much new software for the 68k Amiga either and most is hardware hitting low spec games or quick ports of games like every other platform has. Productivity software is not common and lacking. The 68k Amiga virtual machine is almost as dead as PPC NG but we have retro compatibility and more users do to free and cheap software and hardware. None of the minimal 68k Amiga virtual machine success comes from anything new.

agami Quote:

A business plan that doesn’t rely on “if you build it, they will come�, rather the reverse with “they’re here, time to build it�.

The current problem is more like a store getting lots of floor traffic but few buyers because of noncompetitive products. Most of the hardware buyers open the box, play some games, put it back in the box and store it in a drawer or closet. Everyone knows cheap ARM hardware 68k Amiga virtual machines are EOL nostalgia toys. Other people use a 68k virtual machine on x86-64 hardware to play a few retro games for free. There is not much new, not much growing and nothing sustainable in this market. Contrast this to competitive low end RPi hardware which should have been the 68k Amiga that scales lower in footprint and potentially in production price. The problem is that we have spent 30+ years growing the 68k Amiga virtual machine instead and a 68k Amiga virtual machine footprint is fatter than PPC hardware which failed do to lack of code density compared to ARM Thumb ISAs. Suggesting to stay the course on 68k Amiga virtual machines is like telling the masses we should stay in the desert "growing", despite barely surviving, after 30+ years instead of battling our way into the promised land of small footprint hardware. A giant slaying Amiga user already entered the promised land.

Eben Upton - Show and Tell - Amiga 600 and the Raspberry Pi
https://youtu.be/argxsReuWHw?t=10 Eben Upton Quote:

So I brought a few things in. I thought I would bring a few little toys in. This one is very precious to me, this is my Amiga 600. Shop soiled Amiga 600 from, bought from Lois and Leed's in Christmas of 1992 for 199 pounds. And yea its got ram expansion in the back so 2 MB of chip ram and yea, I learned to program 68000 assembler on this. I couldn't afford any other tools. I couldn't afford any high level languages. The cheapest tool you could buy to program this thing.

Eben has only programmed the Amiga in 68000 assembly. Sadly, he did not bring his 68k Amiga into the promised land but slew giants using ARM Thumb licensed from Hitachi and poorly copied from the 68k. ARM Thumb has similar code density but inferior performance traits to the 68k, the AmigaOS can scale much smaller than the Linux he used and the 68k Amiga has a large library of software including hot retro games for a tiny footprint standard. Maybe he looked at Amiga Neverland and decided it is not possible with the 68k Amiga though.

Last edited by matthey on 11-Jun-2025 at 09:12 PM.
Last edited by matthey on 11-Jun-2025 at 09:07 PM.

@matthey

Quote:

ARM Thumb licensed from Hitachi

You keep saying this, but it's not true.

Thumb was invented quite independently by then Arm Chief Architect Dave Jagger in the early 90s as a way to decrease code size. They probably found some prior art when they went to file patents, and licensed the relevant patents from Hitachi.

How it came about is mentioned in a talk on Youtube just after 27 minutes.

_________________
Whyzzat?

@matthey

Quote:

matthey wrote: The only place the 68k Amiga virtual machine is succeeding is as EOL support for a dead platform.

I'm getting the impression that I'm talking about one thing, and you're talking about UAE.

I'm talking about a NEW software environment supporting the development and portable execution of NEW Amiga-inspired apps, using some friendly language, compiled for a NEW 68k ISA implemented in software, running on a JIT, as a surrogate for a potential new 68k ISA.

What ppcamiga1 was proposing also brakes compatibility. It's his requirement to make something Amiga like that would make it worth for him to move to x64 or ARM64, becasue for some reason as and end user he still cares about the CPU architecture.
What I'm saying is that developing a NEW highly portable OS, outside of the existing developers' capabilities, is a waste. I propose to instead make it so developers are free to make Amiga-inspired apps which are not tied down to the constraints of any OS. Thus taking the OS and the physical hardware out of the immediate equation.

If people would rather not use Word on Windows, or Pages on macOS, or LibreOffice Writer on Linux, macOS or Windows, then a modernised Final Writer running on any OS could be the more palatable option.

Which is the other point I was making: If developers can't dream up better user experiences that the apps on Windows, macOS, Gnome or KDE are already providing, then having an Amiga OS NG 2.0 running on any specific silicon is not going to magically enable that.

It's like drilling a tunnel from both ends. Running two boring machines costs twice as much and completes the tunnel in half the time. But when you only have the single boring machine, and a small crew for a single shift, one has to pick the order in which to drill.
I say get the software going first, then work on the hardware, whereas you appear to favour getting the hardware done first.

_________________
All the way, with 68k

Hammer Quote:

Web Assembly (abbreviated as Wasm) is a low-level bytecode format. Google learns from its lesson its legal fight with Oracle/Sun's Java IP. "The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environment".

WebAssembly is a replacement for JavaScript (JIT) because of the poor performance. Android Dalvik was improved with ART. JAVA was compiled into native code as a replacement for JAVA byte code. At least JAVA permanently solved the problem of inefficient virtual machines. They are an extra unnecessary layer of abstraction. If they have better code density than native, they can come close to native performance and sometimes outperform native code or with interpretation memory can be saved. This is nothing new as the Woz's SWEET16 had 20% code compression compared to the poor 6502 code density (saving memory was often more important than performance back then).

https://en.wikipedia.org/wiki/SWEET16 Quote:

According to Wozniak, the SWEET16 implementation is a model of frugal coding, taking up only about 300 bytes in memory. SWEET16 runs at about one-tenth the speed of the equivalent native 6502 code; however it shaved around 20% off the size of Integer BASIC.

Ideally, native CPU ISAs would have good enough code density that virtual machine code compression would save nothing. Virtual machines should have the best possible code density too, at least taking advantage of a simpler ISA than the native ISA. I could not find any comparisons of WebAssembly code density but there are claims of a "compact code representation". There is a C function example converted to WebAssembly on the Wiki.

https://en.wikipedia.org/wiki/WebAssembly#Code_representation Quote:

int factorial(int n) { if (n == 0) return 1; else return n * factorial(n-1); } ... WebAssembly .wasm binary format 00 61 73 6D 01 00 00 00 01 06 01 60 01 7E 01 7E 03 02 01 00 0A 17 01 15 00 20 00 50 04 7E 42 01 05 20 00 20 00 42 01 7D 10 00 7E 0B 0B

The WebAssembly binary for this function is 45 bytes. We can compare this to 68k assembly with "M68k gcc 15.1.0" and "-O2 -m68020" as arguments.

https://godbolt.org/ Quote:

factorial(int): move.l %d2,-(%sp) ; 2B move.l 8(%sp),%d1 ; 4B moveq #1,%d0 ; 2B tst.l %d1 ; 2B jeq .L1 ; 2B .L2: muls.l %d1,%d0 ; 4B subq.l #1,%d1 ; 2B jne .L2 ; 2B .L1: move.l (%sp)+,%d2 ; 2B rts ; 2B

The 68k code is 24 bytes where WebAssembly binary code is 45 bytes. Maybe 68k code could replace WebAssembly except it is little endian code and the 68k is off the radar as a dead platform. Even if the 68k had a major advantage over WebAssembly, nobody would listen to someone explaining the advantage of code density for an ISA on a dead platform.

Hammer Quote:

PC GPUs still has LLVM JIT compiler driver stack. Game consoles avoid these CPU side overheads. On PC CPU front, DRM protection such as DENUVO virtual instruction set is a software CPU with a virtual instruction set. A 2017 study by Overlord Gaming found that games using Denuvo had an average 15% reduction in frame rate compared to the same games without Denuvo. It's similar overheads from the best Web Assembly virtual machine.

Console standardization allows to avoid GPU JIT compilation of unified shader code and HSA zero copy between GPU and CPU memories? Why can't the 68k Amiga have standard integrated hardware like that instead of EOL "virtual machines"?

cdimauro Quote:

MorphOS, OS4 and AROS introduced new APIs which made the three OSes incompatible each other, since they used the same LVOs for completely different APIs. However, an Amiga OS could borrow them and make it easy to recompile the existing applications coming from those OSes. The only and major problem is represented by OS4, which introduced and heavily used the so called interfaces and shared objects, that are far away from the Amiga OS (which never needed them, anyway: libraries were invented since day zero to fully share the code).

The code of functions and function args would remain the same while LVOs, arg registers and other details would be adapted to the 68k AmigaOS. The library interfaces requires changes for 68k code but programs which support the 68k AmigaOS and AmigaOS 4 have both. Library interfaces were not a good idea for compatibility.

cdimauro Quote:

Are they needed on 68k?

No. But AmigaOS 4 and MorphOS are more advanced in areas than AROS and could bring the 68k AmigaOS forward faster. It would depend on what becomes available though. Neither can survive on PPC alone and only MorphOS looks like it may make it to a new architecture.

cdimauro Quote:

You're assuming that you can use the Amiga OS, but actually AROS/68k is the only option for a project like that.

The 68k AmigaOS may become more open and cheaper after it is no longer held hostage by Hyperion. There may be parts that could not be open sourced and control over the official version may be incompatible with the AROS license. AROS is a valuable resource but using the original AmigaOS would be preferable if it was available.

cdimauro Quote:

I think that there's market for everything: from FPGA to emulators, from virtualizers to ASICs. What's clear from those numbers is that people are interested on 68k. No doubt on that. This is our heritage: it's the one we are fond of and is the one we want to use. The good old games are a good part for that, and they demand a fully retro-compatible platform --> 68000 + perfect chipset. However, solutions like Apollo 68080 before and PiStorm/Emu68 after show that people want also to have more. Much more. If it had only been for RTG and AHI, people would have been content with what was already there (FPGAs and emulation), but reality has turned out to be quite different: people want more and are willing to spend, even a lot, to get it. That's the reason why I see space for an ASIC SoC/platform (which embeds a small FPGA for implementing chipsets for some platforms) with a high performance 68k (united to a 68000 for full backward-compatibility) to give them even much more, that the existing solutions can never give them (for the reasons that I've explained on my previous post).

At least someone understands.

A 68k Amiga virtual machine says to the world that the 68k Amiga is EOL.
A 68k Amiga FPGA machine says to the world that the 68k Amiga is niche but being developed.
A 68k SoC ASIC machine says to the world that the 68k is back to unify the retro masses.

minator Quote:

matthey Quote: ARM Thumb licensed from Hitachi You keep saying this, but it's not true. Thumb was invented quite independently by then Arm Chief Architect Dave Jagger in the early 90s as a way to decrease code size. They probably found some prior art when they went to file patents, and licensed the relevant patents from Hitachi. How it came about is mentioned in a talk on Youtube just after 27 minutes.

The source seems to be the following.

https://lwn.net/Articles/647636/ Jeff Dionne Quote:

ARM even licensed the SuperH patent portfolio to create its Thumb instruction set in the mid-1990s.

Jeff Dionne had research and due diligence performed on SuperH before reviving it as J2. Hitachi was licensing to VLSI Technologies and they had "joint efforts".

Hitachi Licenses SuperH(TM) RISC Engine for Use in VLSI Technology, Inc. ASIC and ASSP Products
- Hitachi and VLSI Extend Technology Sharing Alliance to Cover Embedded Microprocessor Technologies -
https://www.hitachi.com/New/cnews/E/1996/960729B.html Quote:

Technology Agreement Extension Hitachi and VLSI have been cooperating on ASIC technologies since 1988, in a relationship that has yielded significant results in the areas of deep submicron process technology, design tools and cell libraries. By strengthening and expanding the companies' cooperative relationship this latest agreement will help provide customers around the world with new varieties of SH-based products.

The ARM development project was likely saved by VLSI's help so this is a connection.

I expect ARM looked closely at SuperH because it was one of the few good code density RISC ISAs at the time of fat RISC ISAs like Alpha, PA-RISC, MIPS, SPARC, PPC and the original ARM ISA. ARM needed an ISA to work with 16-bit memory for the embedded market and have acceptable performance. SuperH was a 16-bit fixed length encoding ISA and so was the original Thumb while most fat RISC ISAs used 32-bit fixed length encodings. A fixed length 16-bit encoding is not efficient do to increased instructions executed but ARM did not fix it with the much better variable length 16-bit/32-bit encoding until Thumb-2. Thumb could only access 8 GP registers most of the time while SuperH had 16 GP registers to reduce memory traffic. The 68k with a variable length encoding and 16 GP registers executes fewer instructions and has less memory traffic than even Thumb-2 which was a big improvement over Thumb and SuperH.

ARM developers are not going to say they copied SuperH. Since ARM came out the winner, everything they produced has been promoted to magical. The original ARM ISA was mediocre at best with poor code density considering it had about half the GP registers of most other RISC ISAs. The original Thumb ISA was below average with good code density but poor performance from increased instructions executed and increased memory traffic. Thumb-2 is good for a simple VLE, good code density and improved but still below average performance. AArch64 is much better for performance and has good code density for a fixed length 32-bit encoded 64-bit ISA. It sure looks like ARM copied PPC for performance and improved it like they copied SuperH for code density and improved it for Thumb ISAs. The 68k developers likely copied the 16-bit PDP-11 and improved it into the 32-bit 68k. The influence is rarely talked about as it is enough different and improved from the PDP-11 to get away with it. ARM Thumb is not as much improved from SuperH but it was different and improved more later with Thumb-2.

Last edited by matthey on 12-Jun-2025 at 12:22 PM.
Last edited by matthey on 12-Jun-2025 at 05:51 AM.

@matthey

Quote:

WebAssembly is a replacement for JavaScript (JIT) because of the poor performance.

WebAssembly (Wasm) defines a portable binary-code format.

WebAssembly replacing JavaScript (JIT) is a part of it. Java is an IP landmine e.g. Google vs Oracle.

Quote:

Android Dalvik was improved with ART. JAVA was compiled into native code as a replacement for JAVA byte code. At least JAVA permanently solved the problem of inefficient virtual machines. They are an extra unnecessary layer of abstraction. If they have better code density than native, they can come close to native performance and sometimes outperform native code or with interpretation memory can be saved. This is nothing new as the Woz's SWEET16 had 20% code compression compared to the poor 6502 code density (saving memory was often more important than performance back then).

Google officially supports Android games for Windows. https://play.google.com/googleplaygames

Google Play Games on PC utilizes a standard Android Runtime (ART) environment.

Quote:

Console standardization allows to avoid GPU JIT compilation of unified shader code and HSA zero copy between GPU and CPU memories?

ReBAR (Resizable BAR) allows the CPU to directly access the GPU's full video RAM.

Quote:

Why can't the 68k Amiga have standard integrated hardware like that instead of EOL "virtual machines"?

Primary 68K IP owner has transferred to PPC with 16-bit ISA extensions.

NXP hasn't "open-sourced" the 68060 design. I don't recall a soft 68K FPGA with 68K MMU since many would-be CPU designers would rather design a soft MMU for RISC-V instead.

FPGA AO486 has an MMU, hence able to run Windows 95 and full Linux.

Last edited by Hammer on 12-Jun-2025 at 06:40 AM.
Last edited by Hammer on 12-Jun-2025 at 06:32 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

@agami

Quote:

agami wrote: @matthey Quote: matthey wrote: The only place the 68k Amiga virtual machine is succeeding is as EOL support for a dead platform. I'm getting the impression that I'm talking about one thing, and you're talking about UAE. I'm talking about a NEW software environment supporting the development and portable execution of NEW Amiga-inspired apps, using some friendly language, compiled for a NEW 68k ISA implemented in software, running on a JIT, as a surrogate for a potential new 68k ISA.

Is this "new 68k ISA":
- binary-compatible with the existing one
or
- assembly-level compatible (100% or very close)
or
- strongly inspired (e.g.: very similar in many aspects, but a distinct, new ISA)?

Each decision has pros and cons, of course, but at the very end it strictly depends on the final goal of this new Amiga-inspired (?) platform.
Quote:

What ppcamiga1 was proposing also brakes compatibility. It's his requirement to make something Amiga like that would make it worth for him to move to x64 or ARM64,

He only proposes shitty "solutions". In fact, he wants to have everything Unix-based, which is pure shit.

Since he's the only one here that likes that shit, then it's up to him to work on it, leaving other people out to much more interesting things (not shitty stuff, for sure).
Quote:

becasue for some reason as and end user he still cares about the CPU architecture.

He only cares about the UnderPoweredPCs which are already buried. So, he is a necrophiliac.
Quote:

What I'm saying is that developing a NEW highly portable OS, outside of the existing developers' capabilities, is a waste. I propose to instead make it so developers are free to make Amiga-inspired apps which are not tied down to the constraints of any OS. Thus taking the OS and the physical hardware out of the immediate equation.

OK, but what are the foundations & specs of this new Amiga-inspired platform?

What you're talking about is so abstract that it's not useful, at all.

@matthey

Quote:

matthey wrote: Hammer Quote: Web Assembly (abbreviated as Wasm) is a low-level bytecode format. Google learns from its lesson its legal fight with Oracle/Sun's Java IP. "The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environment". WebAssembly is a replacement for JavaScript (JIT) because of the poor performance. Android Dalvik was improved with ART. JAVA was compiled into native code as a replacement for JAVA byte code. At least JAVA permanently solved the problem of inefficient virtual machines. They are an extra unnecessary layer of abstraction. If they have better code density than native, they can come close to native performance and sometimes outperform native code or with interpretation memory can be saved. This is nothing new as the Woz's SWEET16 had 20% code compression compared to the poor 6502 code density (saving memory was often more important than performance back then). https://en.wikipedia.org/wiki/SWEET16 Quote: According to Wozniak, the SWEET16 implementation is a model of frugal coding, taking up only about 300 bytes in memory. SWEET16 runs at about one-tenth the speed of the equivalent native 6502 code; however it shaved around 20% off the size of Integer BASIC. Ideally, native CPU ISAs would have good enough code density that virtual machine code compression would save nothing. Virtual machines should have the best possible code density too, at least taking advantage of a simpler ISA than the native ISA. I could not find any comparisons of WebAssembly code density but there are claims of a "compact code representation". There is a C function example converted to WebAssembly on the Wiki. https://en.wikipedia.org/wiki/WebAssembly#Code_representation Quote: int factorial(int n) { if (n == 0) return 1; else return n * factorial(n-1); } ... WebAssembly .wasm binary format 00 61 73 6D 01 00 00 00 01 06 01 60 01 7E 01 7E 03 02 01 00 0A 17 01 15 00 20 00 50 04 7E 42 01 05 20 00 20 00 42 01 7D 10 00 7E 0B 0B The WebAssembly binary for this function is 45 bytes. We can compare this to 68k assembly with "M68k gcc 15.1.0" and "-O2 -m68020" as arguments. https://godbolt.org/ Quote: factorial(int): move.l %d2,-(%sp) ; 2B move.l 8(%sp),%d1 ; 4B moveq #1,%d0 ; 2B tst.l %d1 ; 2B jeq .L1 ; 2B .L2: muls.l %d1,%d0 ; 4B subq.l #1,%d1 ; 2B jne .L2 ; 2B .L1: move.l (%sp)+,%d2 ; 2B rts ; 2B The 68k code is 24 bytes where WebAssembly binary code is 45 bytes. Maybe 68k code could replace WebAssembly except it is little endian code and the 68k is off the radar as a dead platform. Even if the 68k had a major advantage over WebAssembly, nobody would listen to someone explaining the advantage of code density for an ISA on a dead platform.

Yes, but unfortunately they can't be compared.

As I've said before, I don't like as WASM was designed, and what you've reported is a clear proof of that.

However, WASM is not like a regular ISA, because... it lacks "jumps". For security reasons, there's another mechanism implemented for controlling how the code execution "flows", which isn't and can't be as efficient as a regular ISA which have the usual jumps (conditional and unconditional. Or predication).

That's also the reason why there's no GNU/GCC backend for it: because "goto-like" instructions are required by this platform, which WASM can't provide. LLVM had no such constraints, so WASM has an LLVM backend (that's another reason why it's better to take a look at it, instead of GNU/GCC).

@matthey

Quote:

matthey wrote: cdimauro Quote: Are they needed on 68k? No. But AmigaOS 4 and MorphOS are more advanced in areas than AROS and could bring the 68k AmigaOS forward faster. It would depend on what becomes available though.

That's exactly the problem, since parts of those OSes are owned by different people, as I've said before.

Specifically, MUI5 is a big question mark.
Quote:

Neither can survive on PPC alone and only MorphOS looks like it may make it to a new architecture.

PowerPC is dead since around 15 years, as I've already reported at the time here and on my articles. Only people which don't follow and understand technologies like microprocessors weren't able to so see it (whereas even an idiot could have taken a look at the roadmaps and figure it out).

Anyway, MorphOS has shown an x64 version when, 10 years ago? I don't recall now if it was at the Amiga30 in Germany, where I've attended. But after that there was no other demo, AFAIK: everything is in the Limbo.

Likely, the promised full execution transparency between x64 and PowerPC applications wasn't so easy to achieve, and without a recompilation to x64 of all existing PowerPC applications I don't see any value on the OS running on this new architecture. Not even talking about the transparent Amiga (68k, of course) applications execution.

Let's see if there'd be something at the Amiga40: I'll be there...
Quote:

cdimauro Quote: You're assuming that you can use the Amiga OS, but actually AROS/68k is the only option for a project like that. The 68k AmigaOS may become more open and cheaper after it is no longer held hostage by Hyperion. There may be parts that could not be open sourced and control over the official version may be incompatible with the AROS license.

It entirely depends on which license Michele will use for the Amiga OS source. AROS' APL would be the natural and most conveniente choice, IMO (not viral as GPL, but still forcing contributions back to the source).
Quote:

AROS is a valuable resource but using the original AmigaOS would be preferable if it was available.

Sure, but it's still using a lot of ASM code. The original sources are much better as a reference on how it works (internally).

@cdimauro

Quote:

cdimauro wrote: @agami What you're talking about is so abstract that it's not useful, at all.

Of course it's abstract. It is a proposed strategy/direction using business pragmatism, offered as a more achievable goal than the pipe-dream with which ppcamiga1 started this thread.

At this high level it is only useful as a "north star" guiding principle.
Were I to have the funds, I would be assembling several small advisory teams who agree with the direction, to help answer questions such as:

Quote:

Is this "new 68k ISA": - binary-compatible with the existing one or - assembly-level compatible (100% or very close) or - strongly inspired (e.g.: very similar in many aspects, but a distinct, new ISA)?

and

Quote:

OK, but what are the foundations & specs of this new Amiga-inspired platform?

Last edited by agami on 13-Jun-2025 at 03:18 AM.
Last edited by agami on 13-Jun-2025 at 03:02 AM.

_________________
All the way, with 68k

mattay agami hammer di mauro
stop trolling start working on mui
you had it written on first page of this thread what to do

@agami

Quote:

agami wrote: @cdimauro Quote: cdimauro wrote: @agami What you're talking about is so abstract that it's not useful, at all. Of course it's abstract. It is a proposed strategy/direction using business pragmatism, offered as a more achievable goal than the pipe-dream with which ppcamiga1 started this thread.

Well, everything is much better than the non-sense of THE Hamster / Parrot.
Quote:

At this high level it is only useful as a "north star" guiding principle. Were I to have the funds,

Where to get the funds? Do you have some already, and/or do you plan to ask for some?
Quote:

I would be assembling several small advisory teams who agree with the direction, to help answer questions such as: Quote: Is this "new 68k ISA": - binary-compatible with the existing one or - assembly-level compatible (100% or very close) or - strongly inspired (e.g.: very similar in many aspects, but a distinct, new ISA)? and Quote: OK, but what are the foundations & specs of this new Amiga-inspired platform?

The three architectures scenarios are already so much different that it'll take ages to reach a consensus.

I can't imagine what'd happen when defining the rest of the platform...