brostenen wrote on 2020-10-11, 07:25:

Exactly my point. On these SBC/PI machines, emulation run more or less the same.

Not necessarily. As kjliew is constantly trying to tell you guys, these x86 SBCs support hardware-assisted virtualization (Intel vt-x), which means, that if you are running the DOS VM on a proper hypervisor that takes advantage of this now common CPU feature, all unprivileged non-I/O 16-bit And 32-bit instructions in the guest are executed on the physical host CPU natively. No CPU has to be emulated in software, and even dynamic recompilation (as cool as it is) isn't required.

The only part that would still have to be emulated in software are I/O devices and peripherals like register-level VGA emulation and sound cards. But that's still a lot less work for the host system to do than having to emulate an entire PC on top of the peripherals.

Higher resolution VESA video modes wouldn't even need legacy VGA emulation, since VESA already provides a hardware abstraction, so video output can be paravirtualized, leaving only the sound card emulation as the really challenging part to emulate accurately in software.

The current downside of hardware-assisted hyvervisors like QEMU/KVM and VirtualBox is that legacy VGA and vintage sound card emulation is not a high priority for the developers and is therefore of lower quality than the VGA and sound emulation in DOSBox. So it's not a technical limitation.

In addition to kjliew's QEMU OpenGL/Glide passthrough work, you might also want to take a look at the dosemu2 project (a continuation/fork of the old defunct dosemu project).

Dosemu2 leverages KVM for hardware-assisted virtualization, but unlike QEMU it focuses on DOS compatibility. There's still some kinks to be worked out, but all in all it's undergoing active development. Even experimental support for OPL2LPT and OPL3LPT devices has been added to it recently.

Yes.... Experimental, kinks being sorted out, issues remaining. Like. If you guys set your hopes for an MS Dos 6.22 installation with full non masked IRQ/DMA/IO-SoundBlaster and Adlib support on an Atom based PI board. Then I am afraid that you will disappointed. And as an x86 might or might not deliver a better result at emulating an 486dx33 with the use of DosBox as compared to an RaspberryPI. Then there are more to it than just DosBox, when we are dealing with the best board for emulation. Heck. You can even install Munt with MT32 roms on Linux and have DosBox using it for music. Plus you can have GUS going in DosBox on Linux as well. Basically. The only advantage an X86 PI board have over an ARM PI board when emulatinh an 486 or 386, would actually be stability. The speed of an 486 is, well, the speed of an 486.

As I stated. If you want the best and most supported PI/SBC board for those 35 to 55 dollars. Then you have to go with an RaspberryPI. It is just the best supported machine out there for as many software emulated platforms as possible. People make ready configured SD-Card images with thousands of games. You have the biggest choice of various operating systems as well.

The only thing I have no clue about. Is what programs you can install on Windows10, if it is installed on an RaspberryPI.

brostenen wrote on 2020-10-11, 14:54:

And as an x86 might or might not deliver a better result at emulating an 486dx33 with the use of DosBox as compared to an RaspberryPI. Then there are more to it than just DosBox, when we are dealing with the best board for emulation. Heck. You can even install Munt with MT32 roms on Linux and have DosBox using it for music. Plus you can have GUS going in DosBox on Linux as well. Basically. The only advantage an X86 PI board have over an ARM PI board when emulatinh an 486 or 386, would actually be stability. The speed of an 486 is, well, the speed of an 486.

If you actually tried any of that stuff on a raspberry pi you'd see it struggles to get near 486 performance, even without munt/fluidsynth enabled. My gen1 atom 230 machine (with less ram: 1GB) performs 3x better and it's 13 years older than the current atom lineup.

Interesting having both x64 Win and Linux freedom to install compared to the usual arm SBC but beside I don't like the UEFI bios concept, the solution would be nice for a modern light desktop replacement. Maybe not for retrogaming.. as I tested with Win 8.1 even 32bit version with old games it was not a perfect solution imho and even ended up finding linux wine to give better results that I didn't expect and both with an onboard gpu or a discrete one with native drivers.
A thing I don't understand is why they designed the main chip to be on the back of the PCB considering the usual rpi case. All the heat would stay there and with few space for an heatsink.

digger wrote on 2020-10-11, 12:18:

Not necessarily. As kjliew is constantly trying to tell you guys, these x86 SBCs support hardware-assisted virtualization (Intel […]
Show full quote

brostenen wrote on 2020-10-11, 07:25:

Exactly my point. On these SBC/PI machines, emulation run more or less the same.

Not necessarily. As kjliew is constantly trying to tell you guys, these x86 SBCs support hardware-assisted virtualization (Intel vt-x), which means, that if you are running the DOS VM on a proper hypervisor that takes advantage of this now common CPU feature, all unprivileged non-I/O 16-bit And 32-bit instructions in the guest are executed on the physical host CPU natively. No CPU has to be emulated in software, and even dynamic recompilation (as cool as it is) isn't required.

The only part that would still have to be emulated in software are I/O devices and peripherals like register-level VGA emulation and sound cards. But that's still a lot less work for the host system to do than having to emulate an entire PC on top of the peripherals.

Higher resolution VESA video modes wouldn't even need legacy VGA emulation, since VESA already provides a hardware abstraction, so video output can be paravirtualized, leaving only the sound card emulation as the really challenging part to emulate accurately in software.

The current downside of hardware-assisted hyvervisors like QEMU/KVM and VirtualBox is that legacy VGA and vintage sound card emulation is not a high priority for the developers and is therefore of lower quality than the VGA and sound emulation in DOSBox. So it's not a technical limitation.

In addition to kjliew's QEMU OpenGL/Glide passthrough work, you might also want to take a look at the dosemu2 project (a continuation/fork of the old defunct dosemu project).

Dosemu2 leverages KVM for hardware-assisted virtualization, but unlike QEMU it focuses on DOS compatibility. There's still some kinks to be worked out, but all in all it's undergoing active development. Even experimental support for OPL2LPT and OPL3LPT devices has been added to it recently.

Eh, not all of those x86 SBCs expose Intel vmx/ept instructions to the OS in their firmware.
The situation on those x86 SBCs are similar to the RPi since RPi2 - hyp mode is supported in hardware but not exposed by default on their shipping firmware - its pretty much an experimental, niche feature, and you're depending on a smaller user community to enable it. Even if the SoC support virtualization extensions and it's somehow needed, you are still better off running Virtualbox (which emulates instead of hypervises). For latency sensitive applications like games the vm mode switches are a larger performance penalty than hardware emulation on x86/x64.

Like I've said before, there are already plenty of existing x64 devices (older thin clients) with Celeron or AMD SoCs available now at a price cheaper than one of those SBCs, and those devices would work just fine right out of the box.

ragefury32 wrote on 2020-10-12, 00:53:

Eh, not all of those x86 SBCs expose Intel vmx/ept instructions to the OS in their firmware. ... not exposed by default on their shipping firmware - its pretty much an experimental, niche feature

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and widely deployed. VirtualBox does take advantage of VMX/EPT and runs a hypervisor, so do VMware and QEMU, otherwise they run like craps. Having a firmware option to disable Virtualization Extension does not imply that the technology is immature. The VMENTER/VMEXIT latency issues have largely been resolved when the I/O device realization has the correct implementation. The net result is still significantly faster than any form of emulation based on dynamic recompilers.

ragefury32 wrote on 2020-10-12, 00:53:

...there are already plenty of existing x64 devices (older thin clients) available now at a price cheaper than one of those SBCs that would work right out of the box.

It is not quite the same in using old device vs a modern, contemporary x86 SBC. Especially when VMs are fully capable of taking advantages of 3D acceleration, even the Intel HD 600 GPU core in the these Atoms triumphs over any old thin-clients if they even offer any 3D acceleration. And, these Atoms SBCs operate in the power envelop of 6W, compared to 45W/65W of old thin-clients.

kjliew wrote on 2020-10-12, 01:54:

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and wid […]
Show full quote

ragefury32 wrote on 2020-10-12, 00:53:

Eh, not all of those x86 SBCs expose Intel vmx/ept instructions to the OS in their firmware. ... not exposed by default on their shipping firmware - its pretty much an experimental, niche feature

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and widely deployed. VirtualBox does take advantage of VMX/EPT and runs a hypervisor, so do VMware and QEMU, otherwise they run like craps. Having a firmware option to disable Virtualization Extension does not imply that the technology is immature. The VMENTER/VMEXIT latency issues have largely been resolved when the I/O device realization has the correct implementation. The net result is still significantly faster than any form of emulation based on dynamic recompilers.

ragefury32 wrote on 2020-10-12, 00:53:

...there are already plenty of existing x64 devices (older thin clients) available now at a price cheaper than one of those SBCs that would work right out of the box.

It is not quite the same in using old device vs a modern, contemporary x86 SBC. Especially when VMs are fully capable of taking advantages of 3D acceleration, even the Intel HD 600 GPU core in the these Atoms triumphs over any old thin-clients if they even offer any 3D acceleration. And, these Atoms SBCs operate in the power envelop of 6W, compared to 45W/65W of old thin-clients.

First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware features in general - the technology is mature, but it doesn't mean its support in those SBC hardware are solid. In those SBCs either they run CoreBoot or there is some kind of UEFI firmware preloaded (in this case on the RockPi X: AMI Aptio). The hardware features enabled via the firmware is dependent on what modules were bundled - it can be quite numerous or it could be quite limited.
Even the developers themselves admit that the firmware on the RockPi X is derived from one meant for a tablet and some features will simply not work, i.e. like this person asking about PXE boot off the NIC:
https://forum.radxa.com/t/cant-seem-to-pxe-bo … -working/4571/8

PXE boot has been around for nearly 30 years, and it doesn't work on this SBC. Thats not because the tech is new, it's because of the experimental/hobbyist nature of the device. If it's experimental, don't expect niche features (like hardware virtualization) to work, or even if it's listed in the BIOS, for it to run through QA the same way it was on a commercial/volume production product. AFAIK these SBCs are classified as hobbyist, and if things don't work (or don't work reliably...like I remember some guy on their forum complaining about the Windows GPU drivers crashing on the hardware once in a while)...well, tough nuggets. I remember having to argue with Intel over the crapulent I2C support in their Galileo SBC several years ago - when hanging an imaging sensor can crash your device and there are no firmware fixes from the biggest name in the semiconductor business, it doesn't bode well for hobbyist hardware in general.

Second of all, how much you want to bet that vmenter/vmexit performance improvements in the Core CPUs will percolate over to their consumer Atom cousins? Even if the hardware support is there, Intel also had an albatross around its neck called L1TF. Atom CPUs are said to not be affected, but unless code is rewritten to exclude Atoms, the standard mitigation can cut into vmenter/vmexit performance - especially costly if there are numerous state changes. Once again, why run virt code when normal emulation works, and in the case of using an Atom or an AMD APU to run x86, why run virt at all? That's just good old x86. Hardware is cheap, just throw another core at the job, or throw a more powerful core. There's no guarantee that going virt will result in significant performance improvements or code quality improvements. QEMU-KVM/VMWare Player/Virtualbox are all virt platforms with x86, SB16 and Cirrus logic SVGA support, and frankly, all 3 of them run DOS games worse than DOSBox - either glitchy audio, glitchy video or laggy performance. That's due to the developers implementing "good enough" support, which is not focused on supporting retrogamers.

Third, this SBC is based on the Cherry Trail SoC which uses a GPU derived from the Intel Haswell/Broadwell generation. The UHD600 (which is derived from the Skylake and found in Apollo Lake Atoms or newer, and I should know, I have a Dell Wyse 5070 thin client with a J4105 on a shelf) are only found in bigger ITX machines. The Cherry Trail Intel HD graphics is substantially weaker than the UHD600 - even the Radeon R2E graphics on a 4-6w AMD APU will be able to match or beat it.
Even then, the Bay Trail GPU in my 7 year old Lenovo tablet can run Command & Conquer Red Alert on Full screen just fine in DOSBox, so clearly this has nothing to do with GPU prowess - as far as I know, any integrated GPU from Intel or AMD made after 2011 is more than enough to run apps in DOSbox just fine.

Lastly, just how much power do you think is needed to run a thin client? An HP t530 (with an AMD GX215J with dual excavator cores, a Radeon R2E derived from GCN3 and running on 6-10w TDP - commonly selling for 90 USD on eBay with 4GB of RAM (upgradeable) and 16GB SSD (also upgradeable)) only uses about 15w maxed out. I am pretty sure that the t530 runs on the same performance bracket as the Cherry Trail. The Dell Wyse 5070 (base price 99 USD) with a pair of 16GB DIMMs and a 256GB SSD? About 13w. Hell, the most powerful thin client that I have (The 400 dollar HP t740 with Ryzen embedded V1756B) uses about 23 to 45w, and thats with a pair of 32GB DIMMs, a 40GbE dual port fiber NIC and running multiple VMs in Proxmox, and that's more like a server (it compares well to a Xeon-D 1518). Most embedded AMD SoCs run on 6-15w or less, the most powerful ones are 35-45w, and those numbers are rarely reached. I should also mention that the thin clients that I have can all support SVM or VMX out of the box.
So no. modern thin clients are only on the ~15w range, 10w on normal duties - not quite the 45-65w you are claiming. This isn't quite like the Igel Winnet J+ from 1999 that I have for playing old DOS games. Even that one is about 22-24w unless I pop the Voodoo2 back in.

So once again - Why buy one of these SBCs for doing emulation? They are experimental in nature, aren't all that performant, and there are used, battle tested, ex-enterprise thin clients that are available cheaply that can perform just as well.

ragefury32 wrote on 2020-10-12, 03:09:

First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware featu […]
Show full quote

kjliew wrote on 2020-10-12, 01:54:

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and wid […]
Show full quote

ragefury32 wrote on 2020-10-12, 00:53:

Eh, not all of those x86 SBCs expose Intel vmx/ept instructions to the OS in their firmware. ... not exposed by default on their shipping firmware - its pretty much an experimental, niche feature

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and widely deployed. VirtualBox does take advantage of VMX/EPT and runs a hypervisor, so do VMware and QEMU, otherwise they run like craps. Having a firmware option to disable Virtualization Extension does not imply that the technology is immature. The VMENTER/VMEXIT latency issues have largely been resolved when the I/O device realization has the correct implementation. The net result is still significantly faster than any form of emulation based on dynamic recompilers.

ragefury32 wrote on 2020-10-12, 00:53:

...there are already plenty of existing x64 devices (older thin clients) available now at a price cheaper than one of those SBCs that would work right out of the box.

It is not quite the same in using old device vs a modern, contemporary x86 SBC. Especially when VMs are fully capable of taking advantages of 3D acceleration, even the Intel HD 600 GPU core in the these Atoms triumphs over any old thin-clients if they even offer any 3D acceleration. And, these Atoms SBCs operate in the power envelop of 6W, compared to 45W/65W of old thin-clients.

First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware features in general - the technology is mature, but it doesn't mean its support in those SBC hardware are solid. In those SBCs either they run CoreBoot or there is some kind of UEFI firmware preloaded (in this case on the RockPi X: AMI Aptio). The hardware features enabled via the firmware is dependent on what modules were bundled - it can be quite numerous or it could be quite limited.
Even the developers themselves admit that the firmware on the RockPi X is derived from one meant for a tablet and some features will simply not work, i.e. like this person asking about PXE boot off the NIC:
https://forum.radxa.com/t/cant-seem-to-pxe-bo … -working/4571/8

PXE boot has been around for nearly 30 years, and it doesn't work on this SBC. Thats not because the tech is new, it's because of the experimental/hobbyist nature of the device. If it's experimental, don't expect niche features (like hardware virtualization) to work, or even if it's listed in the BIOS, for it to run through QA the same way it was on a commercial/volume production product. AFAIK these SBCs are classified as hobbyist, and if things don't work (or don't work reliably...like I remember some guy on their forum complaining about the Windows GPU drivers crashing on the hardware once in a while)...well, tough nuggets. I remember having to argue with Intel over the crapulent I2C support in their Galileo SBC several years ago - when hanging an imaging sensor can crash your device and there are no firmware fixes from the biggest name in the semiconductor business, it doesn't bode well for hobbyist hardware in general.

Second of all, how much you want to bet that vmenter/vmexit performance improvements in the Core CPUs will percolate over to their consumer Atom cousins? Even if the hardware support is there, Intel also had an albatross around its neck called L1TF. Atom CPUs are said to not be affected, but unless code is rewritten to exclude Atoms, the standard mitigation can cut into vmenter/vmexit performance - especially costly if there are numerous state changes. Once again, why run virt code when normal emulation works, and in the case of using an Atom or an AMD APU to run x86, why run virt at all? That's just good old x86. Hardware is cheap, just throw another core at the job, or throw a more powerful core. There's no guarantee that going virt will result in significant performance improvements or code quality improvements. QEMU-KVM/VMWare Player/Virtualbox are all virt platforms with x86, SB16 and Cirrus logic SVGA support, and frankly, all 3 of them run DOS games worse than DOSBox - either glitchy audio, glitchy video or laggy performance. That's due to the developers implementing "good enough" support, which is not focused on supporting retrogamers.

Third, this SBC is based on the Cherry Trail SoC which uses a GPU derived from the Intel Haswell/Broadwell generation. The UHD600 (which is derived from the Skylake and found in Apollo Lake Atoms or newer, and I should know, I have a Dell Wyse 5070 thin client with a J4105 on a shelf) are only found in bigger ITX machines. The Cherry Trail Intel HD graphics is substantially weaker than the UHD600 - even the Radeon R2E graphics on a 4-6w AMD APU will be able to match or beat it.
Even then, the Bay Trail GPU in my 7 year old Lenovo tablet can run Command & Conquer Red Alert on Full screen just fine in DOSBox, so clearly this has nothing to do with GPU prowess - as far as I know, any integrated GPU from Intel or AMD made after 2011 is more than enough to run apps in DOSbox just fine.

Lastly, just how much power do you think is needed to run a thin client? An HP t530 (with an AMD GX215J with dual excavator cores, a Radeon R2E derived from GCN3 and running on 6-10w TDP - commonly selling for 90 USD on eBay with 4GB of RAM (upgradeable) and 16GB SSD (also upgradeable)) only uses about 15w maxed out. I am pretty sure that the t530 runs on the same performance bracket as the Cherry Trail. The Dell Wyse 5070 (base price 99 USD) with a pair of 16GB DIMMs and a 256GB SSD? About 13w. Hell, the most powerful thin client that I have (The 400 dollar HP t740 with Ryzen embedded V1756B) uses about 23 to 45w, and thats with a pair of 32GB DIMMs, a 40GbE dual port fiber NIC and running multiple VMs in Proxmox, and that's more like a server (it compares well to a Xeon-D 1518). Most embedded AMD SoCs run on 6-15w or less, the most powerful ones are 35-45w, and those numbers are rarely reached. I should also mention that the thin clients that I have can all support SVM or VMX out of the box.
So no. modern thin clients are only on the ~15w range, 10w on normal duties - not quite the 45-65w you are claiming. This isn't quite like the Igel Winnet J+ from 1999 that I have for playing old DOS games. Even that one is about 22-24w unless I pop the Voodoo2 back in.

So once again - Why buy one of these SBCs for doing emulation? They are experimental in nature, aren't all that performant, and there are used, battle tested, ex-enterprise thin clients that are available cheaply that can perform just as well.

Inferring from PXE boot to judge VMX/EPT is completely flawed. PXE boot is a platform feature and it requires special firmware handling from the platform firmware and PXE firmware from ethernet controller. VMX/EPT is a CPU feature, only required to be enabled/disabled during CPU initialization. Intel CPU supports for firmware vendors (AMI/Aptio & UEFI flavors) has always been a drop-in. For non-lockdown platforms such as SBCs, anyone can enable VMX/EPT with root privilege.

Both thin-clients (HP T530 and Dell Wyse) are great PCs indeed if you can get them cheap. They aren't that old either, the AMD GX215J is a 2017 embedded CPU. Spare that Ryzen embedded options. No doubt they are great but they do not target RPi4 priced segment. You would probably acknowledge that x86 SBCs serve the basis for such thin-client form factor. It all comes down to price. Rock Pi X starts from $59 for the 2GB 16GB eMMC option. A $59 machine running Linux/KVM playing all your past DOS/Win9x collection including those with 3D acceleration. 2GB RAM/16GB eMMC is enough to have a basic GNOME GUI with ArchLinux x86_64 and use disk images in the cloud. That is a great value that ARM SBCs have yet to match.

DOSBox is great for DOS games, no doubt. But for more CPU demanding games especially Win9x games with 3D acceleration, you will need QEMU with KVM/WHPX. For weak CPUs, QEMU KVM is better than DOSBox. For eg. I can comfortably run Tomb Raider 1 3Dfx Glide upscaled to 1024x768 at 30FPS on weak CPUs such as AMD Bobcat C60 and Intel Celeron 847, thanks to QEMU KVM. DOSBox will not give you 30FPS gameplay on these CPUs.

kjliew wrote on 2020-10-12, 04:55:

DOSBox is great for DOS games, no doubt. But for more CPU demanding games especially Win9x games with 3D acceleration, you will need QEMU with KVM/WHPX. For weak CPUs, QEMU KVM is better than DOSBox. For eg. I can comfortably run Tomb Raider 1 3Dfx Glide upscaled to 1024x768 at 30FPS on weak CPUs such as AMD Bobcat C60 and Intel Celeron 847, thanks to QEMU KVM. DOSBox will not give you 30FPS gameplay on these CPUs.

Generally speaking, yes. The DOS-based Windows line was pretty much based on the i386 and v86 mode, though.
It uses a programming style of the late 20th century, also. Idle-Loops, lots of 16-32Bit mixed code, et cetera.
And at the moment, it seems that x86 slowly but steady breaks up with its roots. It's likely thus that we will see many compatibility issues arise within the next few years.
That being said, this likely applies more to high-end CPUs than embedded models. Pentium IV, Skylake, Ryzen.. Each generation had introduced some sort of compatibility issue.
At some point, VMs without an advanced emulation layer for backwards compatibility will nolonger be able to boot old Windows versions.

Currently, Hardware Assisted-Virtualization still helps in making virtualization more accurate. But on the long run, it may also cause lots of problems.
Especially, if the main processor itself has lost lots of its backwards compatibility. In such a case, x86 emulation and a dynarec (on an x86 CPU) are more elegant.
Personally, I think that synthetic devices with special Win9x/XP drivers will be more viable solutions than emulating old graphics cards, which soon will nolonger satisfy the user's demands (1080p, 4K, 8K etc).
Virtual Box did this with the Experimental 3D support for Windows XP years ago. The 3D driver consisted of a modified WineD3D that communicated to Virtual Box.
On the side of the Host OS, the 3D drawing commands were then issued to OpenGL.

Edit: This one is interesting, also. Sometimes, a recent CPU is simply too over-engineered. 😉
http://www.os2museum.com/wp/those-win9x-crash … -fast-machines/

kjliew wrote on 2020-10-12, 04:55:

Inferring from PXE boot to judge VMX/EPT is completely flawed. PXE boot is a platform feature and it requires special firmware h […]
Show full quote

ragefury32 wrote on 2020-10-12, 03:09:

First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware featu […]
Show full quote

kjliew wrote on 2020-10-12, 01:54:

You are just being naive to think that VMX/EPT are still experimental. They have been here for the past 10 years, stable and widely deployed. VirtualBox does take advantage of VMX/EPT and runs a hypervisor, so do VMware and QEMU, otherwise they run like craps. Having a firmware option to disable Virtualization Extension does not imply that the technology is immature. The VMENTER/VMEXIT latency issues have largely been resolved when the I/O device realization has the correct implementation. The net result is still significantly faster than any form of emulation based on dynamic recompilers.

It is not quite the same in using old device vs a modern, contemporary x86 SBC. Especially when VMs are fully capable of taking advantages of 3D acceleration, even the Intel HD 600 GPU core in the these Atoms triumphs over any old thin-clients if they even offer any 3D acceleration. And, these Atoms SBCs operate in the power envelop of 6W, compared to 45W/65W of old thin-clients.

First of all, you are conflating the experimental status of svm/vmx/ept support in those SBCs with the use of the hardware features in general - the technology is mature, but it doesn't mean its support in those SBC hardware are solid. In those SBCs either they run CoreBoot or there is some kind of UEFI firmware preloaded (in this case on the RockPi X: AMI Aptio). The hardware features enabled via the firmware is dependent on what modules were bundled - it can be quite numerous or it could be quite limited.
Even the developers themselves admit that the firmware on the RockPi X is derived from one meant for a tablet and some features will simply not work, i.e. like this person asking about PXE boot off the NIC:
https://forum.radxa.com/t/cant-seem-to-pxe-bo … -working/4571/8

PXE boot has been around for nearly 30 years, and it doesn't work on this SBC. Thats not because the tech is new, it's because of the experimental/hobbyist nature of the device. If it's experimental, don't expect niche features (like hardware virtualization) to work, or even if it's listed in the BIOS, for it to run through QA the same way it was on a commercial/volume production product. AFAIK these SBCs are classified as hobbyist, and if things don't work (or don't work reliably...like I remember some guy on their forum complaining about the Windows GPU drivers crashing on the hardware once in a while)...well, tough nuggets. I remember having to argue with Intel over the crapulent I2C support in their Galileo SBC several years ago - when hanging an imaging sensor can crash your device and there are no firmware fixes from the biggest name in the semiconductor business, it doesn't bode well for hobbyist hardware in general.

Second of all, how much you want to bet that vmenter/vmexit performance improvements in the Core CPUs will percolate over to their consumer Atom cousins? Even if the hardware support is there, Intel also had an albatross around its neck called L1TF. Atom CPUs are said to not be affected, but unless code is rewritten to exclude Atoms, the standard mitigation can cut into vmenter/vmexit performance - especially costly if there are numerous state changes. Once again, why run virt code when normal emulation works, and in the case of using an Atom or an AMD APU to run x86, why run virt at all? That's just good old x86. Hardware is cheap, just throw another core at the job, or throw a more powerful core. There's no guarantee that going virt will result in significant performance improvements or code quality improvements. QEMU-KVM/VMWare Player/Virtualbox are all virt platforms with x86, SB16 and Cirrus logic SVGA support, and frankly, all 3 of them run DOS games worse than DOSBox - either glitchy audio, glitchy video or laggy performance. That's due to the developers implementing "good enough" support, which is not focused on supporting retrogamers.

Third, this SBC is based on the Cherry Trail SoC which uses a GPU derived from the Intel Haswell/Broadwell generation. The UHD600 (which is derived from the Skylake and found in Apollo Lake Atoms or newer, and I should know, I have a Dell Wyse 5070 thin client with a J4105 on a shelf) are only found in bigger ITX machines. The Cherry Trail Intel HD graphics is substantially weaker than the UHD600 - even the Radeon R2E graphics on a 4-6w AMD APU will be able to match or beat it.
Even then, the Bay Trail GPU in my 7 year old Lenovo tablet can run Command & Conquer Red Alert on Full screen just fine in DOSBox, so clearly this has nothing to do with GPU prowess - as far as I know, any integrated GPU from Intel or AMD made after 2011 is more than enough to run apps in DOSbox just fine.

Lastly, just how much power do you think is needed to run a thin client? An HP t530 (with an AMD GX215J with dual excavator cores, a Radeon R2E derived from GCN3 and running on 6-10w TDP - commonly selling for 90 USD on eBay with 4GB of RAM (upgradeable) and 16GB SSD (also upgradeable)) only uses about 15w maxed out. I am pretty sure that the t530 runs on the same performance bracket as the Cherry Trail. The Dell Wyse 5070 (base price 99 USD) with a pair of 16GB DIMMs and a 256GB SSD? About 13w. Hell, the most powerful thin client that I have (The 400 dollar HP t740 with Ryzen embedded V1756B) uses about 23 to 45w, and thats with a pair of 32GB DIMMs, a 40GbE dual port fiber NIC and running multiple VMs in Proxmox, and that's more like a server (it compares well to a Xeon-D 1518). Most embedded AMD SoCs run on 6-15w or less, the most powerful ones are 35-45w, and those numbers are rarely reached. I should also mention that the thin clients that I have can all support SVM or VMX out of the box.
So no. modern thin clients are only on the ~15w range, 10w on normal duties - not quite the 45-65w you are claiming. This isn't quite like the Igel Winnet J+ from 1999 that I have for playing old DOS games. Even that one is about 22-24w unless I pop the Voodoo2 back in.

So once again - Why buy one of these SBCs for doing emulation? They are experimental in nature, aren't all that performant, and there are used, battle tested, ex-enterprise thin clients that are available cheaply that can perform just as well.

Inferring from PXE boot to judge VMX/EPT is completely flawed. PXE boot is a platform feature and it requires special firmware handling from the platform firmware and PXE firmware from ethernet controller. VMX/EPT is a CPU feature, only required to be enabled/disabled during CPU initialization. Intel CPU supports for firmware vendors (AMI/Aptio & UEFI flavors) has always been a drop-in. For non-lockdown platforms such as SBCs, anyone can enable VMX/EPT with root privilege.

Both thin-clients (HP T530 and Dell Wyse) are great PCs indeed if you can get them cheap. They aren't that old either, the AMD GX215J is a 2017 embedded CPU. Spare that Ryzen embedded options. No doubt they are great but they do not target RPi4 priced segment. You would probably acknowledge that x86 SBCs serve the basis for such thin-client form factor. It all comes down to price. Rock Pi X starts from $59 for the 2GB 16GB eMMC option. A $59 machine running Linux/KVM playing all your past DOS/Win9x collection including those with 3D acceleration. 2GB RAM/16GB eMMC is enough to have a basic GNOME GUI with ArchLinux x86_64 and use disk images in the cloud. That is a great value that ARM SBCs have yet to match.

DOSBox is great for DOS games, no doubt. But for more CPU demanding games especially Win9x games with 3D acceleration, you will need QEMU with KVM/WHPX. For weak CPUs, QEMU KVM is better than DOSBox. For eg. I can comfortably run Tomb Raider 1 3Dfx Glide upscaled to 1024x768 at 30FPS on weak CPUs such as AMD Bobcat C60 and Intel Celeron 847, thanks to QEMU KVM. DOSBox will not give you 30FPS gameplay on these CPUs.

It's a perfectly valid comparison - if the feature is not implemented or enabled in your shipped firmware, you as an end user simply will not have normal access to it, pure and simple. it's totally possible for the SBC (or any of those other x86 SBCs) to be shipped to you without the VT-x features present and enabled in the firmware.

As for the relatively inexpensive SBCs being the basis for the thin client form factor, eeeeh, no. Thin clients like this have been around for the past 20 years, and even the small, sub ITX x86 machines like the Via Artigo A1000 (300 USD) has been around since around mid-2008, but those are relatively expensive niche devices. That Artigo was introduced to the market months before the first affordable, hobbyist oriented ARM SBC hit the market (the 100 dollar beagleboard which came out in fall '08). Gumstix have been around with ARM SBCs since 2003, but it was never targeted for cheap affordable hobbyist use.

Besides, the thin clients aren't designed to be sold as cheap-as-chips machines - most started out at the 3-400 USD price level. Amortization, oversupply and the lack of a market for pre-owned devices meant that their values plummet fairly quickly - you can easily pick up a t530 for less than 90, and a t520 for often less than 50, and if you are careful reading specs and comparison shop, you can totally land a thin client with 8GB of RAM, 64GB SATA SSD and Win10 IoT x64 entitlement, like this for less than the price of those SBCs (which most people forgot...still needs to pay shipping and for storage) -> https://www.ebay.com/itm/202991476282

Okay, so now in order to play those oldschool Win98 games in an acceptable clip, we'll need, what, now? Windows 10 Pro with Hyper-V? A Qemu build with whqx extensions, a Win98 VM for qemu, and dgvoodoo (which can take the output from the passed VM and use it to render the VM output...?).
And somehow a quadcore cherry trail SoC with soldered RAM and SD storage is adequate for this?

ragefury32 wrote on 2020-10-12, 22:11:

It's a perfectly valid comparison - if the feature is not implemented or enabled in your shipped firmware, you as an end user simply will not have normal access to it, pure and simple.

It is NOT, because VMX/EPT does not require anything from the firmware. If the platform is not locked down, you as an end user can even enable it outside of the firmware. The rest of the software stacks for virtualization have zero dependency on firmware.

ragefury32 wrote on 2020-10-12, 22:11:

Okay, so now in order to play those oldschool Win98 games in an acceptable clip, we'll need, what, now? Windows 10 Pro with Hyper-V? A Qemu build with whqx extensions, a Win98 VM for qemu, and dgvoodoo (which can take the output from the passed VM and use it to render the VM output...?).
And somehow a quadcore cherry trail SoC with soldered RAM and SD storage is adequate for this?

No Windows 10 Pro and dgVoodoo. Basic ArchLinux x86_64 runs fine with 2GB RAM/16GB storage hosting a Win98 VM on QEMU KVM with 384 MB guest RAM and 3D acceleration. Good enough for oldschool Win98 games.

In fact, AMD GX215J has no Win98 driver, too. It is not capable of seamlessly running Win98 games with 3D acceleration, so QEMU KVM will make it better, too. A 1.5GHz AMD dual-core may not get you very far with DOSBox, but QEMU KVM may offer up to the performance of Pentium III 400MHz with GeForce2, my rough estimation.

I have one of those "pack-of-gum" form factor pocket computers lying around with an Intel Bay Trail SoC. It's basically a passively cooled clone of the first generation Intel Compute Stick.

It supports Intel VT-x and it's enabled out-of-the-box.

And this is not "immature" technology. It's been around for years, and even low-end systems like this one support it these days.

Although it has only a 32-bit UEFI, some recent 64-bit Linux distros such as Fedora can still boot from it. I actually have 64-bit Windows 10 running on it under VirtualBox, since it could only run 32-bit Windows natively due to the 32-bit UEFI. The only real performance bottleneck are the limited amount of RAM (2GB) and the slow SD card I've been running the VM in.

The software mitigations against speculative execution attacks, that someone mentioned here would impact vmenter/vmexit performance, can be disabled in Linux on boot through use of a kernel boot parameter. It should never be disabled on a production system that handles sensitive data, but on a single-user gaming system or emulation station, disabling it is fine, and recovers the lost performance.