@matthey

Quote:

PPC601 instruction fetch: 32 bytes/cycle 68060 instruction fetch: 4 bytes/cycle

Isn't that 16 bytes for 68060? It transfers cache lines too.

Quote:

PPC603 16kiB L1 caches 68060 16kiB L1 caches

IIRC, 68060 has 8K data and 8K instruction caches while the 603e has 16K data and 16K instruction caches.

_________________
Doing stupid things for fun...

Amiga 68k software runs just about everywhere, kinda like java. That’s why it’s "the future", doesn’t imply there is a future in 68k CPU chip.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

BigD Quote:

I thought MorphOS on PPC was cool when it allowed Amigans to play the Amiga version of WipEout2097! But now I can run the Playstation version on THEA500 Mini, why bother even with that? Blender, Candy Factory, Spencer, Tower57... I've run out...

PPC wasn't necessarily a bad choice at the time it was adopted for NG Amiga use. It was big endian which was more compatible with the Amiga, had good performance for a RISC like architecture and had a product pipeline of high performance CPUs that was receiving lots of development investment from multiple businesses. Without licensing the 68k from Motorola like CBM investigated, it would have been difficult to continue with the 68k. There were embedded 68k CPUs available for decades but Motorola never made a higher performance 68k CPU than the 68060 likely because of their loyalty to the AIM alliance and PPC. PPC was dead on the desktop after the IBM G5 disappointment followed by Apple switching to x86. PPC maintained a niche for high end embedded use like engine control and communications that required more performance than ARM. PPC had trouble scaling lower to compete with ARM and bastardized the ISA (opposite of standardization) to reduce resources but this made it less appealing for general purpose use. Finally ARM AArch64 came out, and despite it using more resources than PPC, it was more standard and offered a performance improvement over PPC by one upping it at being less RISCy. AArch64 won't scale any lower than PPC but ARM has Thumb2 for low end embedded, a good reputation for embedded so customers don't question their fat embedded CPU cores and they have easy a la carte CPU cores available for embedded use SoCs. Despite AArch64 using more resources than PPC, ARM went back to in order CPUs to save resources where almost all PPC CPUs are OoO. OoO CPU cores usually start at about twice the transistors/area of in order cores and go up from there. Many embedded customers want the 64 bit AArch64 compatibility, standardization and features for the future but choose the smallest in order cores available to reduce resources which is the original AArch64 compatible Cortex-A53 (RPi 3, RPi Zero 2W). RISC in order CPUs have horrible performance likely worse than low end PPC OoO CPU cores, at least for integer performance. It was definitely a marketing coup by ARM and sneaky of them to use two architectures to scale from low end embedded to workstations that the 68k once spanned with one architecture. The 68k was a great resource miser often with surprising performance like the 68060 demonstrated. AArch64 killed PPC but PPC never killed the 68k. Motorola killed the 68k to promote PPC. AArch64 is a good hybrid RISC ISA for performance but it is a resource hog and the lack of a variable length encoding leaves room for significant code density improvements. Where could we find a challenger with the code density and resource usage of Thumb2 with better CISC like performance than AArch64? Where could we find a challenger that has a huge software library of retro games and performance for modern games?

Oral History Panel on the Development and Promotion of the Motorola 68000 Quote:

Gunter: But my favorite story that I will take to my true retirement is Bob Galvin—but in the same way that you guys respect Noyce and Moore, all of us that were, particularly that were corporate officers have this fundamental respect for Bob Galvin. He pulled me aside one day and he said, "Tom," he said, "I want to tell you something." He said, "One of the," he didn't have to come up with this, he said, "One of the proudest day I ever had with Motorola…" He was traveling to China; that's when we tried to open up China. He got off the plane to talk to a bunch of youngsters. What happened, they saw him off and he was introduced as the head of Motorola, and they started chanting, "68000, 68000, 68000."

@kolla

but so does the MOS 6510/8500

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

Karlos Quote:

Isn't that 16 bytes for 68060? It transfers cache lines too.

No. The 68060 instruction (pre)fetch is only 4 bytes/cycle (32 bits/cycle).

https://www.academia.edu/64300961/The_superscalar_architecture_of_the_MC68060?from_sitemaps=true&version=2 Quote:

We used dynamic code analysis of existing 68K applications to determine the instruction-fetch bandwidth necessary to support the superscalar operand-execution pipelines. The chip’s instruction-set architecture contains 16-bit and larger instructions, with a measured average instruction length of less than 3 bytes. Simulations based on trace data indicated that, holding the rest of the architecture constant, with the combination of a branch-prediction driven prefetch and an instruction buffer, a 64-bit instruction prefetch would be only marginally faster than a 32-bit instruction prefetch. Based on this analysis, the instruction cache to the instruction-fetch pipeline interface has separate 32-bit address and data buses. All instruction fetches are 32-bit aligned fetches. The instruction cache supports a continuous one instruction fetch per cycle rate.

The term prefetch is used because there is an Instruction Fetch Pipeline (IFP) and an instruction buffer before the execution pipelines. The decoupled IFP allows instructions to be fetched, predecoded and placed in the instruction buffer during stalls and multicycle instruction execution. The average instruction length is less than 3 bytes on average and the prefetch is 4 bytes/cycle which is greater. The instruction prefetch is the pulling of instructions from the I cache which is normally just called instruction fetch where there is no instruction buffer. The IFP works especially well with the variable length ISA and leverages the advantage of the tiny average instruction size of the 68k. Most RISC architects would probably do a double take seeing a 4 byte instruction fetch as well. After all, most RISC CPU designs would not be superscalar with such a small fetch but both ISA and CPU design matter.

Karlos Quote:

IIRC, 68060 has 8K data and 8K instruction caches while the 603e has 16K data and 16K instruction caches.

You are correct. The PPC 603 has the same sized L1 I+D caches as the 68060 while the 603e doubled them. The PPC 603 8kiB L1 I cache performs roughly like a 2kiB 68060 L1 I cache because of the code density difference.

The RISC-V Compressed Instruction Set Manual Quote:

The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.

The 68k has ~50% better code density than PPC which is like quadrupling the L1 I cache size in comparison to a PPC L1 I cache. The PPC 603 CPU only uses 1.6 million transistors which is less than the 68060 2.5 million transistors but the memory bandwidth is used up for instruction fetches (the famous RISC instruction fetch bottleneck). Doubling the L1 caches with the PPC 603e now uses 2.6 million transistors and the resulting I cache is still half the performance of the 68060 L1 I cache but the larger L1 D cache reduces memory bandwidth too. Larger caches take more cycles to access reducing performance and max clock speeds. The PPC 603e received a die shrink to compensate but this is an expensive race that RISC can't win and that the 68060 should have won with its deeper pipeline and more efficient caches increasing clock increase potential.

Last edited by matthey on 24-Sep-2022 at 01:41 AM.

@Karlos

Quote:

We were talking about raw processing power, which is not subjective.

No, you were talking about raw processing power... after asking me what I meant.

Quote:

Speaking subjectively, however, if all the UX related features you love from OS4 were recompiled for 68K and ran on the fastest 68K emulations available, I put it to you that you would not be able to tell the difference.

UX and functionality (e.g., Warp3D Nova, va.library).


@matthey
Quote:

You sound like Dr. Evil asking for one million dollars ransom.

???? So, after insulting me multiple times you're now comparing me to Dr Evil and a black mailer holding you to ransom.

I'm stating a simple fact: this kind of development is very expensive, and you're probably underestimating the cost, time & effort required significantly. Ignore at your own peril. Calling people Dr Evil won't lower the cost or make the economic viability any better.

Quote:

A few million dollars is cheap considering the alternatives are continued subsidizing of noncompetitive PPC AmigaOS 4 hardware that has only resulted in about 5k users after about 2 decades or becoming a software only business [/quote[ Looking at the hardware pricing, I don't think anyone is subsiziding them... [quote]spending hundreds of thousands of dollars to port the AmigaOS to ARM and millions of dollars to make it competitive on the desktop where it will be competing against more mature free OSs with much larger software libraries.

AmigaOS is effectively "competing" with all other OSes regardless of the hardware it's running on. Or, should i say, "not competing," or "competing very badly." I don't buy the "you need different hardware or you'll be competing with Windows and MacOS" argument any more. Linux runs on all AmigaOS hardware, an nobody who needs/wants Windows is going to use AmigaOS because they accidentally bought a PowerPC/68K machine.

The advantage of avoiding custom hardware, is leveraging the work of thousands of engineers rather than having to finance it all yourself. Of course, this assumes that you actually do use available source-code (e.g., Linux driver source code) rather than trying to do it all yourself. This isn't about just the initial work to get the system running, but also ongoing maintenance and future work. You get to cooperate with talented companies that have much larger markets supporting their R&D. Apart from reducing the cost, it opens up opportunities that simply wouldn't be economically feasible.

And, if you're still worried about competing because you're on the same platform, you can always take an open-source ARM motherboard design, create your own custom variant, slap an Amiga logo on it, and target just that.

The question is, what do people want? A retro machine for nostalgia? FPGA implementations are more than good enough for that. A "noveau retro" machine with modern functionality? Both x64/ARM and your ASIC could provide, although the ASIC route is more expensive. Or, are people's heart set on creating "the modern Amiga they think would exist if Commodore hadn't gone bust?" In that case, an ASIC would be the only option. Well, maybe. IIRC, Dave Haynie is on record as saying that they would have switched to PCI (because they like standards), and he would have gone x86 instead of PowerPC when 68K started lagging behind.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@matthey

Quote:

matthey wrote: PPC wasn't necessarily a bad choice at the time it was adopted for NG Amiga use. It was big endian which was more compatible with the Amiga, had good performance for a RISC like architecture and had a product pipeline of high performance CPUs that was receiving lots of development investment from multiple businesses.

Perhaps more importantly, Intel did not see a future in (32-bit) x86 and developed Itanium as its 64-bit replacement.

Also, ARM had zero market share at the time. Nobody could have foreseen what it would eventually become.

Quote:

There were embedded 68k CPUs available for decades but Motorola never made a higher performance 68k CPU than the 68060 likely because of their loyalty to the AIM alliance and PPC. (...) Motorola killed the 68k to promote PPC.

68K-derived ColdFire CPUs scaled well beyond the performance of the 68060.

Quote:

Where could we find a challenger with the code density and resource usage of Thumb2 with better CISC like performance than AArch64? Where could we find a challenger that has a huge software library of retro games and performance for modern games?

As long as they run perfectly well via emulation, why would anybody possibly care what CPU retro games would run on?

As for modern games, outstanding performance is a crucial reason why AMD64 is to the go-to-choice for high-end game consoles. (Apple Silicon is quite competitive but obviously not available to third-parties.)

@Hans

Quote:

Hans wrote: Regarding the ASIC, I simply don't see a big enough market. Yes, there are "plenty" of classic 68K Amiga Fans, but I doubt there's enough to create a fancy new ASIC. People are having more than enough fun with FPGA based implementations.

Quote:

OlafS25 wrote: @Hans But yes I also doubt that the market is big enough to finance a ASIC version of a new 68k processor.

And others who don't care to go back and read what people actually said on the topic.

Now to be perfectly clear, I am not saying that the ONLY way forward is a new 68k ASIC, but I will say this again in the hopes to make the viability point clear:

For any new 68k ASIC to have even a small chance of success, at least 90% of ROI (Return on Investment) would have to come from markets OTHER THAN small retro initiatives (Amiga, Atari St, etc).

Because yes, the retro initiatives market is not large enough to justify the millions in upfront investment.

Which is why the challenge for any possible new 68k ASIC is to find other markets which are, for whatever reason, under-served by current ARM offerings.

Whilst this is not an insurmountable challenge, which is why it gives people like @matthey and myself a small spark of energy to postulate and calculate potential, it is nevertheless not a challenge that will be met by anyone, any time soon.

The 68k JIT kernel on x86-64 HW, of which @Karlos and several others are proponents (myself included), is the most practical way forward for high performance Amiga scene computing, with excellent backward compatibility, and a very favourable cost-to-performance ratio.


Quote:

NutsAboutAmiga wrote: @Karlos That makes absolutely no sense. 68K was outdated when PowerPC came to market, PowerPC is outdated, so 68K is relevant again?

I understand that English is not your first language and therefore @Karlos' concise statement can be a challenge to reconcile. Here's the extended concept:

The Power ISA (PowerPC) as implemented by Acube and A-EON, and even as being "supported" by the likes of NXP, maintains a desktop computing relevance to that of 2005, or if we want to be generous, 2010 for some of the higher end SKUs, but the lower 1.1GHz SKU of the 460EX is more relevant to the desktop computing context of 2003.

When compared to today's (2022) desktop computing context, the PowerPC desktop computing capabilities are on AVERAGE 17 years behind.

When PowerPC was introduced as an add-on for the Amiga line of computers in 1998 or even if we allow for the Hyperion/Eyetech era of AmigaOne from 2000-2006, that was only AT MAXIMUM 12 years after the release of 68060 in 1994, but on AVERAGE 8 years after the last 68k desktop computing relevant CPU.

So PPC today (2022) is (17 years) less relevant to desktop computing, than 68k (8 years) was when PPC (for AmigaOS 4) was launched.

@Karlos is merely pointing out that Power ISA in an Amiga context, is not an example of MODERN computing, by any stretch.

Of course, 68k as designed and released in 1994 is 28 years behind, but so is our beloved retro platform. Given the amount of power/$ a 68k JIT can extract on a modern x86-64 platform, it represents the most logical and most practical vector for extending 68k development into contemporary computing.

A lot more performance potential in 2022 than someone running AmigaOS 4.x on a SAM 460LE @1.1GHz for €962.58 ($935 USD). The price of a very respectable 1080p gaming PC system (sans monitor).

Last edited by agami on 24-Sep-2022 at 04:28 AM.
Last edited by agami on 24-Sep-2022 at 04:17 AM.
Last edited by agami on 24-Sep-2022 at 04:14 AM.
Last edited by agami on 24-Sep-2022 at 04:14 AM.
Last edited by agami on 24-Sep-2022 at 04:05 AM.
Last edited by agami on 24-Sep-2022 at 04:04 AM.
Last edited by agami on 24-Sep-2022 at 04:04 AM.
Last edited by agami on 24-Sep-2022 at 04:03 AM.

_________________
All the way, with 68k

@Hans

Quote:

Hans wrote: The question is, what do people want? A retro machine for nostalgia?

Yes. Or more accurately - continuing to use a favorite machine that is now retro, in a modern environment.

Quote:

FPGA implementations are more than good enough for that.

Yes.

Quote:

A "noveau retro" machine with modern functionality? ...Dave Haynie is on record as saying that they would have switched to PCI (because they like standards), and he would have gone x86 instead of PowerPC when 68K started lagging behind.

IOW 'Amiga' would have become merely an OS on top of PC hardware. But Amiga OS is ill-suited to such hardware. And what did it offer that Windows didn't?

Amiga fans howled in anguish when Commodore went bankrupt in 1994. "Commodore killed the Amiga!", they wailed. But in fact Commodore preserved the Amiga, because what would come next would not have been an Amiga.

In 1995 Microsoft released Windows 95 and the Amiga was done, but the computing market had already gone all-in on PCs years before. So at best the Amiga only had a few more years of relevance. I think everybody was disappointed that Commodore didn't last a little longer. It would have been nice to get more AGA machines out and keep support going for existing users. But development of 'next generation' hardware would have just muddied the waters.

Unfortunately some Amiga fans couldn't accept the Amiga's fate, so they tried to keep it alive by infecting it with PPC. But as everyone knows, trying to cheat death by becoming undead just turns you into an inhuman creature. PPC and OS4's promise of immortality has failed, while it has mesmerized users into serving it and drained life out of classic Amiga development.

Fortunately, 25 years later some of us discovered that the Amiga wasn't dead, it was just retired. I too will be retired on Nov 1st this year, and I intend to live out the rest of my days enjoying familiar things like my Amiga. I don't want to see the Amiga dragged out of retirement anymore than I want to myself.

@ASiegel

Quote:

Perhaps more importantly, Intel did not see a future in (32-bit) x86 and developed Itanium as its 64-bit replacement.

Itanium can run IA-32 software at lower performance. With Itanium ISA, it removes direct non-Intel X86 competitors such as AMD. Itanium was Intel's MCA moment.

It's not in Microsoft's self-interest to degrade IA-32 performance.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hans

Quote:

You're kidding, right? 68K Amiga emulation can *NOT* compete with PowerPC Amiga hardware at all. 68K emulation only compares well to old classic Amiga hardware.

FYI, Wazp3D has 97 functions from Warp3D v5, StormMesa, and MiniGL compatibility and it's 3D accelerated under WinUAE.

Quake III 68K runs pretty well on WinUAE 4.9.1/Coffin R58/AmigaOS 3.2 ROM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

I was discussing market expectations in the 1990s when people were evaluating the PowerPC architecture against alternatives.

Clearly, things developed very differently than many industry insiders would have guessed.


Quote:

It's not in Microsoft's self-interest to degrade IA-32 performance.

If you say so. They do sell Microsoft-branded ARM-based hardware with x86 software emulation.

@Hans

In my defence, it's pretty difficult to interpret your original statement to be a critique of experience rather than one of processing power.

Let's say you want the OS4 experience. Given that the vast majority of the OS components are written in C, purely from a technical perspective, what prevents it being ported to 68K to be executed in a modern emulation?

As for Nova, I can't think of anyone more qualified than yourself to answer how much effort is needed to recompile that, but unless it's chock full of assembler and altivec optimisation, I'd hazard a guess, not that much.

In any hypothetical JIT 68K platform, you'd probably want to go the extra distance and make such libraries hooks into host native subsystems where the full performance of native SIMD etc can be brought to bare on the problem.

Last edited by Karlos on 24-Sep-2022 at 07:56 AM.

_________________
Doing stupid things for fun...

@Karlos

I would compare WinUAE with a virtual machine. You can emulate and integrate a lot but there are limits. Lowlevel stuff like Hans does is not possible, you cannot access the host environment. So for him it is of course a step back. I already mentioned 3D games. There are cerainly other things not possible that rely on direct hardware access.

You talk about raw processing power and I tested that too, there WinUAE defeated most PPC systems even on older PCs. On 68k many users are happy with it because main interest is playing the old games. And even old 3D games run well on such a configuration. So it certainly depends on interest and expectation if such a kind of VM is sufficient to you or not.

In my view you both are right

As I wrote I think 68k can and will survive. In the current sad world retro is a new trend, I could imagine that you can even attract younger users if you have interesting offers. I read that some active users even are in 20s. And I think the market can grow. But in my view as part of the retro market and for that the FPGA based hardware (like V4) is more than enough. Additionally there is something like emu68 that might end in a amithlon like ARM based solution. Interesting projects will lead to new users for sure.

For me there are potentially two branches. What I would call "real NG", that would be Aros combined with Linux and MorphOS after ISA change certainly also modernized technically. The other branch retro based on 68k with its countless hardware. And both sold under the "Amiga" brand. That would be interesting again in my view. But I personally see no room for a new 68k ASIC. A ASIC only would make sense if you really want to compete with the big players. I do not see the chance there and it will be difficult to find investors that are willing to take that high risks. Of course a much faster 68k ASIC combined with faster Chipset is interesting but hardly justifying the financial risks. But that is my personal view. Such a platform would make is possible to port more demanding games (currently the ports are from around 1997/1998) but even then it would not play on same level as modern game consoles or PCs. And for game developers earning their living the market is too small.

"In any hypothetical JIT 68K platform, you'd probably want to go the extra distance and make such libraries hooks into host native subsystems where the full performance of native SIMD etc can be brought to bare on the problem."

At least Toni Wilen will not be interested in that. He wants to conserve the old hardware in the emulation, not doing a new super 68k platform. Because of that he certainly is not interested in emulation of V4 either. Perhaps money could motivate him like with PPC emulation. But that can only answered by him.

Last edited by OlafS25 on 24-Sep-2022 at 08:57 AM.
Last edited by OlafS25 on 24-Sep-2022 at 08:53 AM.
Last edited by OlafS25 on 24-Sep-2022 at 08:50 AM.
Last edited by OlafS25 on 24-Sep-2022 at 08:42 AM.

@ASiegel

The situation today certainly is very different. I don't begrudge the move to PowerPC from 68K. Commodore was gone, their plans to go PA-RISC gone with them. While a few people at the time suggested that x86 was the way to go but it wasn't a truly viable proposition at the time. PowerPC came along courtesy of PowerUp and whatever objections people had suddenly seemed less relevant. Apple had moved to PowerPC. They pulled it off with the 601, the lowest spec we had to contend with was 603.

I was an early adopter. I could've upgraded to an 060 but I decided to go for the BlizzardPPC, with the same spec 040 I already had because the writing was already on the wall.

@thread

I appreciate my current sentiments may make me sound like some PPC hater. However my current opinion is based on what is true today, just as being an early adopter of PPC was driven by what was true then. It appeared to have a bright future and was even fun to write code for (not as easy on the eye as writing 68K assembler but it still had some neat tricks).

The truth today is that PPC has been in stagnation longer than the 68K had been when PPC came out. So what are you going to do about that? Apple mastered this problem and successfully migrated from 68K to PPC, then to x64 and then to ARM. Logically then, AROS ought to be the platform everyone rushed to since it runs on almost everything already, but we didn't. The reasons are many and we probably don't need to analyse them. If it was what people wanted, they'd have gone that way.

As I see it, there is more interest in 68K than there is PPC, even if you lump all OS4 and MOS users into a single architecture camp. One thing that is different today is that the vast majority of the software written for this camp is written in languages that are less of a challenge to migrate to a different architecture. So while the architecture may be a dead end and expensive cul-de-sac, it's one that's fairly easy to reverse out of.

Where to go from there? You can go fully x64 native. Or fully Arm native. Or fully 68K to run on some fancy ASIC (once you cross the frozen lake where he'll proper used to be), or more realistically under an emulation (in the multitude of forms that can take). There are many possibilities here. Whatever you do with your host platform, you have the challenge of ongoing software compatibility. This is where 68K brings a genuine solution. You define a set of API that are standardised and your host exports, irrespective of what that host ends up being. Your application binary becomes a bonafide 68K binary, able to run on any host (real or emulated) with the required API available. You don't necessarily have to make everything open and support a multitude of slightly different operating systems and architectures or hope someone else forks it for that reason.

I'm less interested in trying to get everyone running the same OS or platform because it's cat herding. However, if something decides to stick doggedly to PPC it's going to die completely. And when it does, people will still be interested in 68K.

Last edited by Karlos on 24-Sep-2022 at 08:56 AM.

_________________
Doing stupid things for fun...

@Karlos

PPC as desktop processor is dead. There is no doubt about that. PPC will survive in embedded market and at least for now in IBM workstations. That is it.

Like you said question is where to go. Everyone propably also agrees that there is growing market in retro based on 68k with even new hardware developed. In my view this market will grow in future. But as I wrote I see not the need of a ASIC 68k hardware for that and I do not see a big chance to find investors for it except you find additional big markets outside retro for that.

To get interest by new users we need new and modern products outside 68k or PPC. And in my view custom hadware is much too expensive for that. And even if you f.e. port AmigaOS to RPi you still have a small user and software base compared to mainstream systems like Linux or Windows. That is the reason why I am so excited about a merge of Aros and Linux. That is first project that in my view really makes new possible. About the concept behind MorphOS ISA change I cannot say much but certainly the chance to easy port stuff from linux will be important there too.

Last edited by OlafS25 on 24-Sep-2022 at 09:14 AM.

@OlafS25

WinUAE is not the only possible solution for x64, it's just the easiest. If I were to have my perfect system it was either be:

1. Completely x64 native kernel, drivers and OS components, with transparent JIT 68K running on top for running those sweet cross amigoid application binaries.

2. x64 native kernel with integrated JIT 68K service / support for native x64 code calls with a pure 68K OS and userland on top (i.e. something a bit closer to umilator) using low level native calls only for the most performance critical or otherwise metal level tasks.

I find 2 a more attractive possibility as an Amiga nerd, and there's much less to port to ARM or whatever else to support a new CPU.

_________________
Doing stupid things for fun...

@Karlos

I like 68k and did (and currently do) a lot with it but the software base is partly old. Much of it was from 90s, lots of acitivity until about 1997/1998 and then it collapsed. Of course the software base is much bigger than all PPC combined but even with that it is small and outdated compared to mainstream platforms. So even with your proposed super UAE platform you will struggle to advance.

Last edited by OlafS25 on 24-Sep-2022 at 09:18 AM.

@OlafS25

That depends. I think the biggest challenge here is not the ISA. It's leveraging the resources of the host. Consider multicore. Porting the existing OS to x64 or ARM has the problem that if utilising multicore was simple it would've happened already. How long have we had multicore PPC?

That isn't to say emulated m68k makes this any easier. It doesn't. However it might be simpler to run multiple emulation processes on a low level native kernel that does work on multicore, and sort out how they are supposed to communicate effectively than it is to do a native multicore full OS from the ground up.

_________________
Doing stupid things for fun...

@OlafS25

Quote:

I would compare WinUAE with a virtual machine. You can emulate and integrate a lot but there are limits. Lowlevel stuff like Hans does is not possible, you cannot access the host environment. So for him it is of course a step back. I already mentioned 3D games. There are cerainly other things not possible that rely on direct hardware access.

In WinUAE maybe. But there are other platforms to virtualize systems.
Not being able to access GPU directly is a limitation in WinUAE, not a limitation in virtualization itself.

In QEMU for example is absolutely possible to provide direct and exclusive access from a guest to a GPU. Direct access and direct ownership.
There are entire subsystems and API within QEMU to make this possible, because in particular for GPUs it is desireable to allow a guest to have 100% direct control and access to GPU HW in quite many usecases.

Maybe just port what JIT stuff is missing from WinUAE to QEMU instead and all your dreams will come true.

The low-level stuff that Hans does could absolutely be done from a QEMU guest. With 100% of the native performance since there are no layers and no translations. It is direct access from Hans code poking and prodding registers in the physical GPU directly without any host involvement. Performance is 100% like native performance.

Last edited by V8 on 24-Sep-2022 at 10:25 AM.