@Karlos

Quote:

If you can accept that a bunch of commodity PC hardware installed on some exotic, expensive PPC board that has zero legacy hardware is an Amiga because of the lineage of it's OS, then you have no sensible reason to suggest that a solution like Amithlon running 3.x is any different.

I believe that was the point. In the final Amiga days there was PowerPC and Mediators. The chipset was replaced by cheap PC cards plugged into expensive boards. The AmigaOne took an updated CPU used in the CyberStormPPC, the PCI slots of the Mediator and produced a machine that was cheaper than both combined and faster. Good going I'd say. Redesigning an Amiga chipset to make it official was just not practical, even if desired, and would have cost a fortune not considering it was ten years too late by then.

Not to futher the PPC argument, but just wanted mention a few things. I think the point being made is that PPC, being big endian, can emullate the 68k more efficiently. Because it doesn't have to convert endian on memory reads/writes. x86/64 has to do some extra work. Now, obviously why x86/64 wins in this department, is simply because of speed. But there is more. The GPR count of x64 is about the same as 68K, 16 main registers. So it would need to store them in memory or store half. PPC has 32 registers, so it can keep emulated 68K registers in real CPU registers. With enough left over for overhead. This is a way better way of working. So, technically I think PPC is a superior design to emulate 68K more efficiently, but of course x64 still wins without these technical advantages because it simply runs faster than the PPC models we are comparing it with. Or brute force as it is sometimes called.

Futhermore, we shouldn't even be discussing Amithlon now, what happened to AROS? Now days, AROS should be compatible enough with AmigaOS, that it could replace and whip it's ass ten times over. Why can not AROS load x86 Amithlon programs? It runs on x86! Also, why cannot AROS support 68k executables? It should provide the best of both words here. For some reason, even though it's still not technically AmigaOS, it still cannot run Amithlon binaries nor emulate 68K binaires directly. It would blow everything away!

But, back to PPC, and OS4. Yes, any modern x86/64 can emulate 68K faster than an X1000, even when emulating the chipset underneath. But one thing I haven't seen yet is being able emulate OS4 fast, or at least on the level of my X1000. The thing, and I don't see this mentioned, is that 68K apps emulated on OS4 make use of the native OS and interface. I can run 68k stuff faster on my i5 lsaptop, yes, but in UAE they look old and crap! In OS4 they look so much better than I don't want to go back.

And, by comparison opposite to Amithlon. Such as with the native x86 binaries AmigaOS is being emulated. But on OS4, 68K is emulated while OS calls are native. And obviously native apps run full speed.

Yes, I know this probably doesn't mean much any more, but I like form as well as function. And I hear arguments a lot, like I've got Amithlon running on my i9 now, and it runs my Amiga software so much faster than your X1000. You know what I would say to that next? I would say there is sometihng called Windows, designed for your i9 and runs out of the box, that runs native and has all these natve apps, so much faster than your old emulation so why are you using modern computers to run old obsolete software?

Last edited by Hypex on 29-Apr-2022 at 08:14 PM.

@Hypex

There's that misconception again. Emulated. Once you're in JIT territory, it's a misnomer, really. Unless it's a hybrid model that only recompiles hot code paths and interprets the rest, there's no emulation per se. It's all native. It doesn't matter that much about endianness or register counts. FWIW I don't believe that Petunia does fixed register mapping (I could be wrong). This is something you might do in an interpreter model but JIT just look at your binary as another higher level code to be compiled and it will do it's own register allocation as it sees fit.

I mentioned Amithlon rather than AROS because of how it works. The model promised by Umilator was brilliant. I've nothing against AROS at all, but as a continuation of the Amiga experience, Amithlon (aside from getting it working in the first place) was peerless. Unless you stopped to remind yourself it was running on an x86/64 there was just nothing to remind you. Want to put in a new disk? Put an actual disk in and set it up with HDToolBox. Same with expansion cards. Other than the otherworldly speed of execution, it just felt exactly like using the real thing. Completely different than UAE. No alien user interface popping up because you hit F12 by accident.

From a UI perspective, face it. If there was a modern 68K emulation solution along the above lines, it could run a 68K backport of OS4 no problem.

Last edited by Karlos on 29-Apr-2022 at 11:48 PM.

_________________
Doing stupid things for fun...

@Karlos

Amithlon still relied on an underlying "HAL" known as Linux, though, for video, audio and whatnot (USB?). From what I recall, Amithlon came with a few tools to poke through the emulation layer and access the underlying filesystem and even run software on the Linux side?

Emu68 doesn't even have that, it is loaded as a kernel on the raspberry pi, so you essentially get a 68k raspberry pi. And so all drivers have to be written for 68k as well.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

Don't think of it as an emulation.

I don't. I think of it more as a quasi CPU microcode running further up in the OS kernel.

I used the term "emulation" for thread context and conversation consistency.

_________________
All the way, with 68k

@kolla

Quote:

And so all drivers have to be written for 68k as well.

On a narrow target such as the Pi that might be OK, but on a diverse HW platform such as PC motherboards, having the Linuix/QNX HAL was an advantage.

_________________
All the way, with 68k

@Hypex

Quote:

They designed the ARM CPU? That went into the Acorn? To my knowledge they took an existing ARM CPU and customised the core for their purposes.

To go back to your original gripe of Apple branding it as "Apple Silicon", you should have no qualms. ARM is an architecture and does not produce ARM-based silicon.

Now, if you're going to say that only fabs can use the moniker of "silicon" on their products, and the fabless should abstain, then there is a whole slew of labels all of us in contemporary society accept that would need to be re-evaluated because they don't fit your if-this-then-that literal interpretation of the world.

Also, you refer to things in such binary terms. There are many shades of grey between black and white, and most things in life fall under the Theseus' Ship paradox.

The fact of today is that neither Nvidia, nor AMD, nor Intel, nor Qualcomm, nor ARM, are designing CPUs. Just like the team at Apple, the teams at these other companies are evolving "customising" the designs of previous engineers, who for the most part did the same.


Quote:

No one is going to beat Intel engineers anymore.

Here's another of Theseus' Ships. How many intel engineers have to leave intel and join the likes of Apple or AMD before whatever the contingent remaining at intel can be beat? Johny Srouji is formerly of intel. If Apple's engineering team has greater than 50% former intel engineers, is their team effectively an intel engineering team? Are people born as intel engineers, or are they also plucked from competing firms?


Quote:

But they already were fabless with Intel.

Incorrect. They were not a licensee of x86 and were therefore not designing their own "customised" versions. They had even less influence with intel than they did with Motorola and IBM as part of AIM.


Quote:

They stole some core functions from the P.A.Semi PPC design and put it in their chips.

All large companies grow through acquisition. It's a key vector for gaining new IP and growing the talent pool. So when a company such as Apple acquires P.A. Semi, it is not considered "stealing" when they implement something that team of engineers developed.

_________________
All the way, with 68k

@kolla

Quote:

Amithlon still relied on an underlying "HAL" known as Linux, though, for video, audio and whatnot (USB?).

It did. But that's not necessarily a bad thing. In fact, it's a good thing. You can use existing code to abstract access to the menagerie of available hardware and simplify access from the "68K box", reducing complexity on driver requirements for the latter. As long as the kernel is out of the way providing support I don't see any conceptual difference between it and Quark on MorphOS for example.

Also, a point of clarification, Amithlon allows the use of pure 68K drivers for any supported hardware attached over the PCI bus. It's not all virtualised by the HAL in that sense. An interesting aside is that this tends to work for PCIe too since the 68K PCI drivers don't see any difference there.

Last edited by Karlos on 30-Apr-2022 at 06:54 AM.

_________________
Doing stupid things for fun...

Another benefit of the Amithlon model, in common with PPC NG platforms is that 68K code can call native code and vice versa. This is especially useful on a target like x64 for optimised libraries that can then make use of vectorisation and other features of the CPU that aren't readily used by the recompiled 68K code.

_________________
Doing stupid things for fun...

@Hypex

Quote:

I would say there is sometihng called Windows, designed for your i9 and runs out of the box, that runs native and has all these natve apps, so much faster than your old emulation so why are you using modern computers to run old obsolete software?

I think you are missing the point of my suggestion maybe. The point is not to simply reduce a modern PC to a turbocharged museum piece. The point to decouple AmigaOS from any specific hardware requirements and to provide a means for universal software distribution as 68K binaries that will still run on real 68K, FPGA, Emu68K, OS4, MOS and finally also on commodity PC hardware as close to the metal as is practical while retaining full binary compatibility.

Since PPC is dead and more obsolete today than 68K was when it was first introduced, having the Amithlon/Umilator model provides a path out of total obsolescence for the ongoing development of AmigaOS, new applications for it and the emerging hardware 68K ecosystem around it.

The whole thing comes full circle. Perhaps the Amithlon style solution could evolve to better support JIT PPC code too and in the process allow PPC binaries to be supported later down the line, preserving access to software that won't get backported to 68K for whatever reason.

_________________
Doing stupid things for fun...

While I'm in full flight of fancy mode...

The Amithlon/Umilator approach, with its Linux kernel based HAL (let's call this the L Box) is in a position to use more than one CPU core. The 68K box, as seen from the L Box is essentially a single process, but there's no reason why the sorts of operation that are synchronous and single threaded in the classic UAE emulation need apply here.

Consider graphics operations. AmigaOS graphics libraries were from day zero designed to work with asynchronous hardware like the blitter. The L Box can use multiple threads that in turn can spread over multiple cores to provide that same asynchronous behaviour as seen from the 68K box, even in the case when there is no explicit hardware acceleration for some feature. The benefit of this is that any time consuming operations that would otherwise slow down the core running the 68K box are offloaded, minimising the performance impact and equally ensuring the operations in the L Box don't drag on. This is good because you'd probably want a fully software fallback solution for just about every device layer you can think of that may not have suitable drivers on day 1.

Provided the L Box and 68K box were open source, there's no reason why it would have to remain x64 exclusive either. It could be ported to PPC allowing users of multicore systems to get the same benefit: utilising more than one CPU core.

Last edited by Karlos on 30-Apr-2022 at 11:08 AM.

_________________
Doing stupid things for fun...

@Karlos

Tread lightly, friend Karlos,

you are making sense on Amigaworld.net.




/m

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@OneTimer1

Quote:

So you can only vote for he 'Pancake' Option, because your system is not listed on the poll.

Every AmigaOne can be configured the same way as the Pegasos 2 in my possession. This morning I played one world in Populous II The Challenge Games (via RunInUAE and WHDLoad) and Master of Orion 2 (directly by double-click on icon from WB - via DosBox).

@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote: @Karlos Tread lightly, friend Karlos, you are making sense on Amigaworld.net.

Unlikely I'll be accused of that. However I'm speaking with the benefit now of 30 years of hindsight as an Amiga enthusiast and developer. As I said somewhere else here, 68K is part of the Amiga DNA. From the first Hi Torro prototype, to every commodore model, to the first hardware clones (remember the Draco?), to UAE and the first emulation, to first the PPC expansion era, to the PPC only era with the Pegasos / AmigaOne, to x64 with Amithlon and XL, to the current FPGA and ARM/Emu68 based expansions. The one and only consistent feature among every iteration has been the ability to run AmigaOS 68K binaries.

If you embrace this, provide standards for it (minimum ISA specification, ABI behaviour, expected minimum library and device API set, etc) you can develop new applications that can run anywhere in that zoo of exotic implementations. Rebuild AmigaOS itself to support those same standards and you can run your Amiga anywhere also. And all without displacing existing PPC iterations which can live out their pasture until the inevitable failure of their aging components. Finally, the whole Umilator style L Box / 68K Box solution ensures that no matter what ultimately happens in the PPC, FPGA, classic HW scene, the Amiga as a system and user experience can live on, running on commodity hardware that is always upgradable without the sometimes jarring dislocated feeling of being just an emulator application that UAE (great as it is) often gives you.

Last edited by Karlos on 01-May-2022 at 04:28 AM.

_________________
Doing stupid things for fun...

Karlos Quote:

Unlikely I'll be accused of that. However I'm speaking with the benefit now of 30 years of hindsight as an Amiga enthusiast and developer now. As I said somewhere else here, 68K is part of the Amiga DNA. From the first Hi Torro prototype, to every commodore model, to the first hardware clones (remember the Draco?), to UAE and the first emulation, to first the PPC expansion era, to the PPC only era with the Pegasos / AmigaOne, to x64 with Amithlon and XL, to the current FPGA and ARM/Emu68 based expansions. The one and only consistent feature among every iteration has been the ability to run AmigaOS 68K binaries.

Correct conclusion about the importance of the 68k CPU. The reason is compatibility of which the chipset is important too. There is minimal new Amiga attraction with most of it being retro requiring Amiga compatibility.

Karlos Quote:

If you embrace this, provide standards for it (minimum ISA specification, ABI behaviour, expected minimum library and device API set, etc) you can develop new applications that can run anywhere in that zoo of exotic implementations. Rebuild AmigaOS itself to support those same standards and you can run your Amiga anywhere also. And all without displacing existing PPC iterations which can live out their pasture until the inevitable failure of their aging components. Finally, the whole Umilator style L Box / 68K Box solution ensures that no matter what ultimately happens in the PPC, FPGA, classic HW scene, the Amiga as a system and user experience can live on, running on commodity hardware that is always upgradable without the sometimes jarring dislocated feeling of being just an emulator application that UAE (great as it is) often gives you.

You can build emulation standards but it won't be adopted on a large scale. It will run inefficiently anywhere but will suffer the same fate as AmigaNowhere. AmigaForever/UAE and THEA500Mini have been successful because they retain retro Amiga compatibility and because they are affordable. Other Amiga non-solutions have failed to create a healthy user base and attract outside developers. Few emulation environments have been successful as evolving development targets. Java as bytecode was but it died due to emulation inefficiency and Android's Dalvik/ART VM was/is due to ARM smart phone incompatibility before AArch64. AOT compilation is utilized in places but that is often with relatively small downloaded modules which are reasonably expected to be executed soon. It is wasteful compared to downloading an efficient pre-compiled executable and doesn't work well in a general purpose computing environment. The most common compilers used are based on LLVM which needs so many resources that even so called AmigaNG machines don't have LLVM compilers. JIT is even more wasteful of CPU performance and memory. AOT adds latency and JIT adds jitter to programs even on systems with adequate performance and resources. Popular high performance systems are becoming increasingly oppressive closed systems for security reasons making them less appealing as emulator hosts and emulation increases security risks.

Attempts have been made for more efficient generic configurable hardware but have largely failed. There was VLIW Transmeta and Intel Itanium code morphing with a software firmware layer that more efficiently translated existing architectures to the internal VLIW architecture on the fly. It's not even dead today with the Nvidia Denver/Carmel cores.

https://en.wikichip.org/wiki/nvidia/microarchitectures/denver
https://en.wikichip.org/wiki/nvidia/microarchitectures/carmel

Nvidia was originally going to code morph x86 but licensing fell through so they used ARM AArch64 instead. The 68k could be supported also and there are recent SoCs with GPUs based on these cores. This would be a more ideal hardware target for the 68k than emulation. The big advantage is the low power of VLIW but the disadvantages are less general purpose due to reduced branch performance, significant time and cost to develop morphing firmware for a target and 128MiB of memory used for an optimization cache. A 68k Amiga can easily operate on the amount of memory wasted by the optimization cache. Still not efficient, especially for low end systems.

Enter the Raspberry Pi. Why doesn't the Raspberry Pi Foundation just make a Raspberry Pi emulator and stop producing hardware? It would be suicide and they are too smart for that. The idea is not to compete in performance. The original Raspberry Pi could easily be emulated by an average x86-64 PC yet they sold millions of units. The idea is to make as useful of general purpose hardware as possible for the lowest price. It is also important that the hardware is mostly open, small and low power. This is an old school back to basics mentality similar to the original Amiga success, as computing has developed toward bloated closed systems. This had been hugely successful as sales are roughly 50 million units. The only emulation necessary is the Amiga emulation of the Raspberry Pi Foundation. The Raspberry Pi Foundation has tried to make smaller footprint computers by doing their own fabless SoC development which only saves $1 (Pi Pico @$4 vs Pi Zero @$5) but even their first $1 SoC chip has been a success with buyers like Adafruit, Pimoroni, Arduino and SparkFun. There is a market for cheap small footprint systems and the 68k AmigaOS is a nice standard graphical GUI based multitasking OS that can scale down into a footprint between the Rasperry Pi Pico and Zero, where there is no standard OS with a GUI and software like the Amiga. The Amiga has some very interesting retro software that is usable at these small footprints. If the Amiga could sell a half million or more units for retro, hobbyist and embedded use, Amiga would be back in business.

@matthey

I genuinely don't think arguments about "inefficiency" of JIT emulation of 68K on commodity x64 apply. How many orders of magnitude faster than any physical implementation of the 68K that has ever existed and ever will exist is enough? You mention UAE and Amiga Forever as being a success because they are cheap. I'm not advocating for anything different with an open source Umilator/Amithlon inspired system that runs on modern commodity x64 hardware. The only software you'd be paying for is a 68K operating system to run on it (and if that's AROS 68K, not even that). The hardware would be whatever PC you want to build for it*, not what some exotic systems vendor thinks you should have for it.

*At the very least, using hardware that has Linux support. You can then export virtual RTG / AHI / SANA devices from the L Box to the 68K box for hardware that does not (yet) have a more suitable driver available in the 68K box.

Last edited by Karlos on 01-May-2022 at 04:21 AM.

_________________
Doing stupid things for fun...

@matthey

I think we all generally agree in principle, though not all of us are on the same page when it comes to GTM strategy.

We don't have the luxury of large sums of capital, nor the luxury of time. So we shouldn't aim to solve all problems at once.

If the Amiga, or the philosophy of Amiga, has a chance of being resurrected as part of a move to bring to market a viable computing platform, being an alternative to Windows PCs and Macs, most of us agree that 68k will form one of its pillars.

Efficiency should definitely be a goal, but not in the onset. @matthey, you are right in terms of loss of efficiencies during translation, but it doesn't mean that support for execution of 68k binaries via software layers on non-68k hardware is not a viable stepping stone.

Four-stroke internal combustion engines are notoriously inefficient at converting the energy stored in hydrocarbon bonds into kinetic energy. They hovered in the 20%+ range for decades, and only in recent decades have achieved efficiencies in the 30%+ range.

We accepted the inherent inefficiencies of the internal combustion engine because of many other economy factors.

@Karlos lays out a decent first move into a performant 68k-focused ecosystem with an aim to improve and standardise a development environment that is critical in moving to the next step.

The goal can't be to just have a 68k-based SoC/SoP hobby board to play in the same space as Raspberry Pi. Theirs [RPi] is just a hardware play. Ours is a legacy software + hardware + new software play.

Last edited by agami on 01-May-2022 at 04:56 AM.
Last edited by agami on 01-May-2022 at 04:56 AM.
Last edited by agami on 01-May-2022 at 04:43 AM.

_________________
All the way, with 68k

@Karlos

Quote:

30 years of hindsight as an Amiga enthusiast and developer. As I said somewhere else here, 68K is part of the Amiga DNA. From the first Hi Torro prototype, to every commodore model, to the first hardware clones (remember the Draco?), to UAE and the first emulation, to first the PPC expansion era, to the PPC only era with the Pegasos / AmigaOne, to x64 with Amithlon and XL, to the current FPGA and ARM/Emu68 based expansions. The one and only consistent feature among every iteration has been the ability to run AmigaOS 68K binaries. If you embrace this, provide standards for it (minimum ISA specification, ABI behaviour, expected minimum library and device API set, etc) you can develop new applications that can run anywhere in that zoo of exotic implementations. Rebuild AmigaOS itself to support those same standards and you can run your Amiga anywhere also

I couldn't agree more,
friend Karlos.

68k is Amiga's DNA, period. It's not just part of it, it is it.
Or perhaps, shall we call it an even more primordial DNA? RNA?

You were right on the money when you pointed out that JIT can't even be considered mere emulation. Performance is near-native, and with abstraction on top of it, all kind of dark enchantments can be conjured in order for some form of SMT, isolation etc. to happen at a higher level.

JIT packaged this way, is closer to what Windows did with WOW16 and WOW32 for years before users even started wondering what that joyfully named process might even be.

The 68k instruction set and architecture is now just another Virtual Machine, not unlike Javascript's V8, or the JVM. And this particular virtual machine has lots of legacy software written for it. Software SO INBUED WITH LOVE, SO DRIPPING WITH LOVE, that people can't let it go 30 years on.

Truly (©®™ Robert Bernardo 2006 - 2022),
people scoff at emulation because they do not realized they're silently using it every day, seamlessly, elegantly integrated in their familiar Windowses, Linuxes and MacOSes.


VVVOOOORRR ON, friend Karlos,
VVVOORRR ON.












/mega!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@matthey

Quote:

... into a footprint between the Rasperry Pi Pico and Zero ... If the Amiga could sell a half million or more units for retro, hobbyist and embedded use, Amiga would be back in business.

At $5 a pop, it wouldn't even make its money back. At $10, maybe it makes its money back.

To be considered "back in business", it would at the very least need to sell 500k units annually for about 5 years. At $5 - $10 per unit, the only way to make the kind of profit that can be used for the v2 and v3 products, is through quantity.

_________________
All the way, with 68k

@agami

Quote:

Four-stroke internal combustion engines are notoriously inefficient at converting the energy stored in hydrocarbon bonds into kinetic energy. They hovered in the 20%+ range for decades, and only in recent decades have achieved efficiencies in the 30%+ range.

It's an interesting analogy, but 20% efficiency is the order you'd get from a particularly efficient bytecode type interpreter (10% is more typical in my experience). JIT implemetations, taking into consideration the overhead of translation cache management, path analysis, etc. are typically 80% or better. Even if some hypothetical JIT only managed 50% of the ideal single thread native performance of a modern x64, that's more 68K MIPs than any existing software would know what to do with.

Speaking about JIT for a moment. The assumption is always that JIT is still slower than true native. Let me recount for you an amusing story from the labs at Hewlett Packard, back in the mid to late 1990's...

HP were investigating JIT. They chose to implement a JIT "emulation" of a CPU they knew very well: their own PA-8000. They designed the JIT, which they named Dynamo, to perform what is now considered the standard approach for hot code path analysis and optimisation.

They built and ran this JIT on the PA-8000 and found that many benchmarks showed the code to execute faster on Dynamo than it did when ran directly on the PA-8000. This was attributed to the hot path optimisation effectively folding our branches, unreachable code and other optimisations that are only manifest at runtime and not at compile time.

The moral of the story here is, don't assume that some native binary is going to be better in native execution just because one is compiled directly for the other. Decisions the code makes at runtime are just as important (which is why software needs profiling in the first place) and sometimes impossible to plan for given no two runs are necessarily the same.

_________________
Doing stupid things for fun...

@Karlos

Call me nuts, but I find the “Amithlon model” rather cumbersome compared to just using fs-uae. Amithlon seems stuck to an ancient kernel built with ancient toolkits and only gets limited updates in form of backports, and I much rather use native Linux driver stacks for just about everything than relying on “amiga drivers” of often questionable quality and lacking maintenance. One can still expose hardware to AmigaOS through resource libraries etc, even easier today with name spaces and a lot more virtualization possibilities… so how about the qemu-system-m68k and amiga drivers for everything virtio?

Last edited by kolla on 01-May-2022 at 10:21 AM.
Last edited by kolla on 01-May-2022 at 10:13 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC