When can we see native Apple Silicon support? Both DOSBOX and DOSBOX-X run with transcoding (as long as you don't use dynamic core - and that's being fixed), and I expect that other emulators in use such as ScummVM will ultimately work fine as well.

Probably at that point when the M1 Apple userbase gets bigger.

Was it so that in those M1 Apples by default you can buy applications and games only from Apple's store, but there is an option to allow installation from other sources as well? A bit like you can allow 3rd party software with Android phones and tablets, but you have to enable it manually yourself?

If Apple M1 users are restricted only to Apple store, then naturally GOG can't sell games to them.

In general I am not interested in Apple, but frankly it does seem this move from Intel to ARM might make sense to them in the long run, as the performance (per watt) seems so much better with these M1 Apples, and the x86 emulation actually seems to be quite usable and surprisingly fast.

https://www.youtube.com/watch?v=BUBYO591Fo8#t=165

(a 3D benchmark running on emulated x86 M1 as fast as on real x86 silicon? I wonder how fast it would run if it was ported properly to ARM/M1?)

I know Microsoft has also already released some ARM-based Windows PCs, but if I've understood right, they are restricted to Microsoft Store only so I am not really interested in them either (EDIT: Or are they? Now I am actually unsure because I recall seeing some video someone testing how well x86 Steam games run on such ARM Windows laptop)... but all this does make me wonder if we will see more and more non-x86 compatible PCs in the future that CAN run also our current x86 applications (including games) through emulation? Based on e.g. ARM or RISC-V architecture or such?

This is the first time I see that even PC might slowly be moving away from x86 architecture, if the other options offer much better performance ratio natively, and still offer quite usable x86 emulation.

You can install 32 and 64 bit apps outside of the the store but as of now only 32 ones can be run at least AFAIK.

It probably depends on the game itself and whether it's worth GoG offering support for ARM/RISC hardware. If there's a RISC compatible build of DosBox, then I'd expect it shouldn't be too hard to repackage the DOS games (assuming the userbase is there). However, the Windows games on the list will come down to whether there's effective X86 and X86-64 emulation built into the Apple OS. Even then, the extra calls on support might not make supporting this worth it, unless there's a significant Apple userbase using ARM silicon.

This is one of the unintended consequences of Apple's u-turn on the x86-64 architecture.

That's been the case for years. No, it's a simple preference button to change that, which again has been the case for years. Running unidentified apps is also possible, though more hidden.

Anyway, the X64 emulation appears to be as fast or faster than running on a real Intel chip, so I don't think there's much urgency for native apps yet. There is, but that's not how it works. Nobody writes assembly language, so the CPU architecture isn't particularly relevant as long as certain technical aspects are the same (e.g. endianness, floating point format), which they are in this case. It's not like the PPC/Intel transition.

When you port a game, you recompile your C++ code if you're doing everything yourself, or else republish from Unity/Unreal/etc. What actually matters is the APIs, and traditionally the biggest hurdle has been Direct3D vs. OpenGL. If you're using a third-party engine you don't have to worry about that, otherwise you'd use Metal these days, though you can still use OpenGL for now. But the point is that you're not coding for a CPU, so the M1 doesn't really change anything as far as porting games. (Although the integrated graphics seem to be actually semi-usable for gaming, which is an improvement over typical Intel integrated graphics.) No. You can't run 32-bit apps.

No, you can't.

You can only run specific x86 apps that have been released for the Mac OS. Compatibility is sketchy and Bootcamp ofc won't run.

The M1's performance per watt is certainly astounding and its GPU performance is probably in the 1050/1050 ti category, which is remarkable for a IGP.

It's almost too good to be true, even for TSMC 5nm. I'm curious to see what comes out of it when someone does a die-level introspection - I suspect some ASICs/accelerator blocks have been thrown in for good measure to provide at least part of the performance gain.

I would say not for a while because there will be a time where Apple has to support both Intel based Macs and the M1 based macs just like they did with Power PC and Intel back in 2006.

Interesting - so what happens for processor extensions? I'm thinking about things like MMX or 3dNOW (I know they're not really used much anymore, but imagine there are some newer ones). I'm guessing that you have to replace the call with software?

Software is one way to do it, but it's very inefficient. IMHO, if ARM on desktop is ever going to have a go at x86 it will have to come with dedicated hardware logic for x86 to ARMv8 translation. Apple might have included some acceleration blocks already within the M1.

We'll see if Apple keeps up this compatibility. Given their past history...I'd start counting the days and have an exile plan handy.

Apple has been designing ASICs for a while now and and I'd love to see an in-depth analysis as well. Emulation typically requires significantly more powerful hardware, and the way Apple has been emulating 86 is like magic. There's definitely some sort of unaccounted for hardware acceleration here or something akin. I suppose that I might consider it for a workstation cum casual gaming rig then. This or a good windows 2 in 1.

Timppu was asking whether MS allows it, at least that's what I got, and you can: on Windows ARM you can install and run 32bit x86 apps but you can't run 64bit x64 apps now, the new emulation is available trough Windows insider for developers but isn't to public because is still being worked on.