mikrocontroller.net

Forum: PC Hard- und Software Läuft HMM3 auf einem Raspi 3B+ ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hat hier schon mal jemand getestet, ob 'Heroes of Might and Magic III' 
auf einem Raspberry 3 B+ mit Raspian läuft?
Oder kennt sich jemand so weit aus um abzuschätzen, ob es 
hochwahrscheinlich laufen bzw. nicht laufen würde?

Hier ist ein Beitrag/Anleitung für Ubuntu-User:
https://wiki.ubuntuusers.de/Spiele/Heroes_of_Might_and_Magic_3/

Und hier noch zwei weitere Links zu HMM3 unter Linux:
https://www.holarse-linuxgaming.de/wiki/heroes_might_and_magic_iii
https://wiki.dotslashplay.it/en/games/heroes-of-might-and-magic-3

Autor: zufaulzumanmelden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird nicht funktionieren, da’s nicht für die ARM-Architektur gebaut 
worden ist.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnelle Antwort! Schade.

zufaulzumanmelden schrieb:
> Wird nicht funktionieren, da’s nicht für die ARM-Architektur gebaut
> worden ist.

Wo hast du diese Info gefunden?

Autor: zufaulzumanmelden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wo hast du diese Info gefunden?
Dass Pi ARM ist? Das ist bekannt. Dass x86-Binaries nicht auf ARM 
laufen? Ist auch bekannt.

Autor: René F. (therfd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist nicht allzuschwer "heroes of might and magic 3 raspberry pi" bei 
Google einzutippen...

https://www.instructables.com/id/Gaming-Beyond-RetroPie-x86-Games-on-Raspberry-Pi/

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke euch beiden für die Infos!

Habe tatsächlich kaum Ahnung von Linux-Systemen.

Das mit "ExaGear Desktop Software" klingt auf jeden Fall 
vielversprechend, Danke für den Link!!!
Wenn ich HMM3 damit zum Laufen bekomme, poste ich es hier.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ExaGear scheint ein proprietärer x86 Emulator zu sein.
Das gleiche solltest du auch mit Qemu erreichen können.

Auf dem Host läuft nach wie vor ein Rasbian oder Debian Linux.
In der emulierten x86 Umgebung mit z.B. Qemu kannst du dann versuchen 
Windows 2k/XP, Win9x/Me oder irgend ein Linux für x86, z.b. wieder 
Debian, laufen zu lassen.
Beachte, QEMU läuft hier dann alls volle Emulation und nicht als 
Virtualisierungslösung, insofern wird das recht viel von deinem 
Raspberry Pi abverlangen.

Bezüglich Spiele die ursprünglich für Windows erschienen sind, wäre es 
am sinnvollsten WinXP als Gastsystem einzurichten, dann hast du eine 
Hürde weniger, da nur die CPU Architektur emuliert werden muss.
Du wirst dafür allerdings eine Windows Lizenz benötigen.
Die Spiele müssen natürlich auch für Windows compiliert worden sein.
Spezielle Linux Versionen der Spiele werden so natürlich nicht 
funktionieren und darum handelt es sich ja bei deinem Link auf 
ubuntuusers.
Diese spezielle Linux Version müsstest du aber extra erwerben, wenn du 
sie noch nicht hast. Eine Lizenz des Spieles für Windows berechtigt 
NICHT für die Linux Version. Falls du die Linux Version schon hast, dann 
kannst du als Gastsystem ein Linux x86 System installieren.
Da die Firma, die dieses Windows Spiel nach Linux portiert hat, vor 
ungefähr über 17 Jahren in die Insolvenz ging, würde ich dir mangels 
zeitgemäßem Support aber abraten, die Linux Version zu erwerben, kauf 
dir stattdessen besser die Windows Version von GOG, denn die Windows 
Version ist die offizielle Version des Hersteller und kein Port einer 
Drittfirma die in die Insolvenz ging.
Für die Windows Version kannst du wie bereits gesagt die obige Variante 
über Windows XP als Gastsystem wählen.

Falls du kein Windows XP oder vergleichbare Windows Linux hast, gäbe es 
noch die Möglichkeit ein x86 Linux als Gastsystem in der x86 QEMU 
Umgebung auszuführen und dann in dieser die Windows Version mittels 
Wine, ein Wrapper für Windows Binaries, versuchen auszuführen.
Hier hast du neben der x86 Emulation aber noch Wine als weitere 
Fehlerquelle. Und eines sei hier gesagt, es ist einfacher eine x86 
Architektur zu emulieren, als einem Windows Binary unter Linux eine 
Windows Umgebung vorzugaukeln.

Ob du auf dem Raspi die x86 CPU schnell genug emuliert kriegst, so das 
Windows als Gastsystem und HOMM3 angemessen läuft, dass wirst du nur 
durch Testen herausfinden. So von den Screenshots scheint HOMM3 keine 3d 
Features zu nutzen, was schon einmal ein gutes Zeichen ist. Denn neben 
der x86 CPU auch noch eine 3d Grafikkarte zu emulieren bzw. deren 
Aufrufe irgendwie auf eine GPU für die Arm Architektur zu wrappen dürfte 
noch einmal deutlich schwieriger sein.
Das ist so, als wollte man Playstation 3 Spiele auf einem PC ausführen. 
Letzteres geht zwar, aber der PS Emulator bekommt auch entsprechenden 
Support und hat die 3d Unterstützung als aktiv supportetes Projekt 
gleich mit drin. Bei Qemu auf ARM wird das eher nicht der Fall sein.
Teil 4 dürfte schon Probleme auf dem Raspberry Pi machen und Teil 5 
kriegst du gewiss nicht zum laufen.

Du hast also 4 Möglichkeiten:

1. Hostsystem: Rasbian oder Debian + QEMU Full X86 Emulation
   Gastsytem: Windows 2k oder XP oder eventuell auch Win9x/Me
   Spiel: Windows Version.
2. Hostsystem: Rasbian oder Debian + QEMU Full X86 Emulation
   Gastsystem: ein beliebiges x86 Linux. z.B. Debian.
   Windows Wrapper Wine, welches dann in deinem Gastsystem läuft und 
eine
   Windows Umgebung unter Linux nachahmt.
   Spiel: Windows Version
3. Hostsystem: Rasbian oder Debian + QEMU Full X86 Emulation
   Gastsystem: ein beliebiges x86 Linux. z.B. Debian.
   Spiel: nativer Linux Port

Die erste Variante dürfte am besten laufen, da nur die x86 CPU emuliert 
werden muss.
Die dritte Variante dürfte, wenn sie läuft, nach der ersten die beste 
Performance bringen. Die Frage ist halt, ob sie läuft. Linux hat sich 
weiterentwickelt, die Linux Binaries des Spiels dürften dagegen seit 
Jahren keinen Patch mehr erhalten haben, das ist das Problem.
Die zweite Variante hat zwei Fehlerquellen, einmal muss die x86 CPU 
emuliert werden und das andere mal muss Wine dem Windows Spiel eine 
funktionstüchtige Windows Umgebung vorgaukeln. Die Fehlerquelle ist hier 
also entsprechend hoch.

Noch ein weiterer Tipp. Alle 3 Varianten könntest du erst einmal auf 
einem normalen x86 Computer testen, dann kannst du hier schon einmal die 
gröbsten Fehlerquellen ausschließen.
Achte dann aber darauf, dass Qemu die x86 CPU vollständig emuliert und 
nicht auf irgendeine Virtualsierung zurückgreift.
Wenn das geht und performancemäßig akzeptabel läuft, kannst du dich an 
den nächsten Schritt wagen.
Erwarte von der x86 Emulation auf ARM aber keine Wunder.


Wenn du DOS Spiele auf dem Rasbperry Pi laufen lassen willst, dann wäre 
die DOSBox die beste Option, da die auf nicht x86 Plattformen ohnehin 
eine x86 CPU emuliert. Du sparst dir also den Schritt über den QEMU x86 
Emulator und einem Gastsystem.

Am besten laufen auf dem Raspberry Pi übrigens die Adventures die die 
ScummVM verwenden können, die läuft nämlich nativ auch auf der ARM CPU.
Alte LucasArts Adventures sollten auf dem Raspi also kein Problem sein.

Die Zweitbeste Option sind DOS Spiele in der DOSBox, weil die am 
wenigsten Performance fressen und der Raspi ausreichend viel Leistung 
dafür haben sollte.

Windows Spiele sind aufwendiger, siehe oben.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Du hast also 4 Möglichkeiten:

Korrektur, es sind natürlich 3.
DOS fällt als 4. Möglichkeit natürlich weg, da HMM3 nie für DOS 
erschien.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Falls du kein Windows XP oder vergleichbare Windows Linux hast

Da hat sich noch ein Fehler eingeschlichen. Ich meinte natürlich 
"vergleichbare Windows Version" und nicht Linux.
So etwas passiert halt, wenn man zigmal den Satz umbaut.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Da die Firma, die dieses Windows Spiel nach Linux portiert hat, vor
> ungefähr über 17 Jahren in die Insolvenz ging, würde ich dir mangels
> zeitgemäßem Support aber abraten, die Linux Version zu erwerben, kauf
> dir stattdessen besser die Windows Version von GOG, denn die Windows
> Version ist die offizielle Version des Hersteller und kein Port einer
> Drittfirma die in die Insolvenz ging.

Und für die gibt es heute noch aktiven Support vom Hersteller?

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> ExaGear scheint ein proprietärer x86 Emulator zu sein.
> Das gleiche solltest du auch mit Qemu erreichen können.
>
> Auf dem Host läuft nach wie vor ein Rasbian oder Debian Linux.
> In der emulierten x86 Umgebung mit z.B. Qemu kannst du dann versuchen
> Windows 2k/XP, Win9x/Me oder irgend ein Linux für x86, z.b. wieder
> Debian, laufen zu lassen.
> Beachte, QEMU läuft hier dann alls volle Emulation und nicht als
> Virtualisierungslösung, insofern wird das recht viel von deinem
> Raspberry Pi abverlangen.

Ich kenne das ExaGear zeug zwar nicht, aber rein von den Bildern im 
Artikel her sieht mir das nicht nach Vollemulation aus. Qemu kann das 
aber auch. Unter debian gibt es da dafür das qemu-user-static Packet, 
darin gibt es das qemu-x86_64-static Programm. Die Verwendung ist jedoch 
nicht ganz trivial und ich weiss auch nicht, wie brauchbar das momentan 
läuft, bisher hab ich das immer nur umgekehrt gemacht, also arm64 auf 
amd64/x86_64 emuliert, und schon dort gab es schon kleine Problemchen 
mit seccomp, umgekehrt wird es nicht besser werden. Eventuell kann ich 
mal einen speziellen x86_64 Docker Container vorbereiten, der auf arm64 
läuft.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Nano schrieb:
>> Da die Firma, die dieses Windows Spiel nach Linux portiert hat, vor
>> ungefähr über 17 Jahren in die Insolvenz ging, würde ich dir mangels
>> zeitgemäßem Support aber abraten, die Linux Version zu erwerben, kauf
>> dir stattdessen besser die Windows Version von GOG, denn die Windows
>> Version ist die offizielle Version des Hersteller und kein Port einer
>> Drittfirma die in die Insolvenz ging.
>
> Und für die gibt es heute noch aktiven Support vom Hersteller?

1.
Die Wahrscheinlichkeit, dass ein Spielhersteller für ein Spiel, dass 
sich unter Windows zigfach verkauft hat, für eine neuere Windows Version 
einen Patch nachrückt, ist deutlich größer, als bei einem Unternehmen, 
dass unter Linux kaum ausreichende Stückzahlen eines für viel Geld von 
einem anderen Hersteller lizenzierten und dann portieren Produkts 
verkauft hat.
Der Linux Portierer kann sich den Support definitiv nicht leisten, der 
richtige Hersteller kann das schon eher, da er auch höhere Stückzahlen 
verkauft hat.

2.
Die Windowsversion ist aus diesen Gründen in der Regel auch weitaus 
besser gepflegt und dürfte auch weitaus runder laufen.


Zu beachten ist hier vor allem, dass das nicht der gleiche Code ist.
An irgendeinem Punkt wurde er vom Linux Portierer übernommen und ab da 
wurde er dahingehend verändert, damit er unter Linux läuft.
Die Änderungen fließen nicht zwingend zum Hauptentwickler zurück.
Änderungen die der Hauptentwickler durchführte, mussten nachträglich, 
vermutlich auch manuell, in den Linuxcode eingepflegt werden.
Und dann hat es nicht lange gedauert und der Linux Portierer ging in die 
Insolvenz und verschwand vom Markt, während der Originalentwickler immer 
noch existierte und für seine Windows Version Patches nachreichen 
konnte, die der Linux Port nun nicht mehr kriegt.

Damit der Linux Port die gleiche Qualität hat, wie der Windows Port, 
muss die Codebasis durchgehend die gleiche sein, also vom gleichen Repo 
stammen und alles vom gleichen Hersteller stammen.
Dann hat man zwar immer noch nicht die Garantie, dass die Linux Version 
genauso gut supported wird, immerhin könnte man diese nachrangig 
behandeln. Z.B: nur 1 Entwickler anstatt 4, die an den 
Systemspezifischen Sachen arbeiten, aber zumindest ist die Codebasis 
durchgehend die gleiche und die Wahrscheinlichkeit somit höher, das auch 
die Linux Version halbwegs gut gepatched wird.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Ich kenne das ExaGear zeug zwar nicht, aber rein von den Bildern im
> Artikel her sieht mir das nicht nach Vollemulation aus.

Es muss eine Vollemulation sein, da der x86 Code nicht auf einer ARM CPU 
läuft, zumal Screenshots darüber ohnehin keine Auskunft geben können, 
was da unter der Haube werkeln  muss.
Oder verstehst du unter Vollemulation etwas anderes?

> Qemu kann das
> aber auch. Unter debian gibt es da dafür das qemu-user-static Packet,
> darin gibt es das qemu-x86_64-static Programm. Die Verwendung ist jedoch
> nicht ganz trivial und ich weiss auch nicht, wie brauchbar das momentan
> läuft, bisher hab ich das immer nur umgekehrt gemacht, also arm64 auf
> amd64/x86_64 emuliert, und schon dort gab es schon kleine Problemchen
> mit seccomp, umgekehrt wird es nicht besser werden.

Für HMM3 wird er nur eine 32 Bit Emulation benötigen.
Qemu ist schon ausreichend gereift und die x86 Plattform bekannt genug, 
so dass ich mir da keine Sorgen machen würde.
Besonders schnell wird die Softwareemulation allerdings nicht sein, das 
ist das größte Problem daran.

Da muss der Raspberry Pi mit seiner puren Taktzahl Schwerarbeit leisten. 
Mit etwas Glück kann Qemu die Multicores des Raspi nutzen, so dass noch 
einmal etwas Leistung gewonnen wird.
Das Spiel erschien im Frühjahr 1999, der Atlhon 500 Mhz erst im Juni 
1999, falls der Raspi mit Vollemulation so schnell sein sollte, wie 
bspw. ein P2 266 MHz, dann dürfte das Spiel darauf noch laufen, denn an 
solche CPUs wird man sich wohl damals orientiert haben.

Autor: zufaulzumanmelden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal vor einiger Zeit die umgekehrte Variante getestet: einen 
ARM via qemu auf einer nicht zu schlechten x86/64-Plattform (Xeon 
E3-1230v3, 4GB RAM). Diese virtuelle Maschine war langsamer, als ein 
nativer Raspberry Pi 1. Daher meine Einschätzung, dass das Spiel auf 
einem Pi einfach nicht sinnvoll zum Laufen zu bringen sein wird. Aber 
vielleicht sind meine Überlegungen auch falsch, und das läuft ganz prima 
damit – ich bin jedenfalls auf den Bericht des TS gespannt :)

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Es muss eine Vollemulation sein, da der x86 Code nicht auf einer ARM CPU
> läuft, zumal Screenshots darüber ohnehin keine Auskunft geben können,
> was da unter der Haube werkeln  muss.
> Oder verstehst du unter Vollemulation etwas anderes?

Ich verstehe darunter die Emultion eines vollständigen Systems, 
inklusive OS und allem. Bei quemu-user emulation ist das nicht der fall, 
der Kernel/das OS wird nicht emuliert, sondern nur die Anwendung. Die 
Syscalls, die die Anwendung nutzt, werden einfach an den bereits 
laufenden Kernel weitergegeben.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Nano schrieb:
>> Es muss eine Vollemulation sein, da der x86 Code nicht auf einer ARM CPU
>> läuft, zumal Screenshots darüber ohnehin keine Auskunft geben können,
>> was da unter der Haube werkeln  muss.
>> Oder verstehst du unter Vollemulation etwas anderes?
>
> Ich verstehe darunter die Emultion eines vollständigen Systems,
> inklusive OS und allem. Bei quemu-user emulation ist das nicht der fall,
> der Kernel/das OS wird nicht emuliert, sondern nur die Anwendung. Die
> Syscalls, die die Anwendung nutzt, werden einfach an den bereits
> laufenden Kernel weitergegeben.

Okay, also eines sei hierzu gesagt.
Wenn die x86 Anwendung einen Syscall macht, dann wird der unter einem 
Kernel, der für ARM gebacken wurde, nicht funktionieren.
So eine Userspace Emulation kann man machen, wenn die CPU Architektur 
die gleiche ist.
Das wird hier aber nicht funktionieren und wenn doch, dann muss da vor 
dem Syscall noch eine Zwischenschicht rein, die darauf achtet und die 
beiden Architekturen kompatibel macht, also Antworten von der ARM 
Umgebung in x86 Antworten umwrappt. Mir ist aber nicht bekannt, das man 
das schon gemacht hat.

Üblich ist da einfach, dass man die Maschine komplett emuliert und 
einfach ein x86 Gast OS darauf laufen lässt.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zufaulzumanmelden schrieb:
> Ich habe mal vor einiger Zeit die umgekehrte Variante getestet:
> einen
> ARM via qemu auf einer nicht zu schlechten x86/64-Plattform (Xeon
> E3-1230v3, 4GB RAM). Diese virtuelle Maschine war langsamer, als ein
> nativer Raspberry Pi 1. Daher meine Einschätzung, dass das Spiel auf
> einem Pi einfach nicht sinnvoll zum Laufen zu bringen sein wird. Aber
> vielleicht sind meine Überlegungen auch falsch, und das läuft ganz prima
> damit – ich bin jedenfalls auf den Bericht des TS gespannt :)

Ich auch.
Er könnte dazu vor allem ein paar CPU spezifischen Benchmarks laufen 
lassen.


Am besten noch mit einem Emulator Vergleich Qemu vs. Bochs.


Hier habe ich noch ein Video zu dem Thema gefunden, angesehen habe ich 
es mir aber noch nicht:
Youtube-Video "How fast can Raspi 3 (ARM) emulate x86 instructions?"

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich gerade gefunden, ein Benchmark von Quake unter der DOSBox 
auf einem Raspberry Pi 2.
Demnach hält der Raspberry Pi 2 nicht einmal mit einem Pentium MMX 200 
Mhz mit. Die Zahlen dürften wohl für die min, average und max Frameraten 
stehen.

Seltsam finde ich allerdings, dass der Pentium MMX 200 MHz bei Quake so 
langsam ist, ich habe Quake auf solchen Systemen als deutlich schneller 
in Erinnerung, schließlich wurde das selbst auf alten Pentium 60 MHz 
Rechnern gespielt.
Es könnte allerdings sein, das hier eine höhere Auflösung genommen 
wurde, als damals üblich war, das könnte die schlechten Frameraten auch 
erklären.
Ebenso wäre es denkbar, dass man eine für 3d Beschleuniger typische 
Funktion in Software emuliert hat, die man damals im Software Modus 
wegen der miesen Performance gar nicht verwendet hat.
Auf der ersten Seite steht dazu sicher genaueres zu den Testsettings.

https://www.vogons.org/viewtopic.php?f=31&t=43280&start=80#p442339

Auf jeden Fall sind die Zahlen bezüglich dem Raspberry Pi 2 vernichtend. 
Der Raspberry Pi 3 ist jetzt nicht unbedingt so viel schneller.
Aber trotzdem möchte ich niemanden entmutigen. HOMM3 ist ein reines 
Strategiespiel und kein Egoshooter im Software Rendering Mode.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Seltsam finde ich allerdings, dass der Pentium MMX 200 MHz bei Quake so
> langsam ist, ich habe Quake auf solchen Systemen als deutlich schneller
> in Erinnerung, schließlich wurde das selbst auf alten Pentium 60 MHz
> Rechnern gespielt.
> Es könnte allerdings sein, das hier eine höhere Auflösung genommen
> wurde, als damals üblich war, das könnte die schlechten Frameraten auch
> erklären.

Vielleicht ist es diese S3-Grafikkarte. Die hatten damals die 
Angewohnheit, mit 3D-"Beschleunigung" auch schon mal langsamer zu sein 
als ohne.
Auf meinem Pentium mit 133 Mhz war es auf jeden Fall rein mit 
Software-Rendering schneller. Ich hatte damals die wildesten Grafikmodi 
ausprobiert, um die Auflösung zu maximieren. Ich meine, entweder bei 
320x400 oder sogar bei 360x480 so um die 13 bis 15 FPS hinbekommen zu 
haben.

> Auf jeden Fall sind die Zahlen bezüglich dem Raspberry Pi 2 vernichtend.

Quake war extrem stark auf genau die Eigenschaften eines Pentium 
zugeschnitten. Man hat Teile der Berechnungen auf die FPU ausgelagert, 
die beim Pentium erstmalig schnell genug dafür war, und der 
Assembler-Code war handoptimiert, um CPU und FPU parallel zu nutzen und 
dabei möglichst immer gleichmäßig auszulasten. Das wird in einer 
Emulation dann vermutlich überhaupt nicht mehr passen.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Vielleicht ist es diese S3-Grafikkarte. Die hatten damals die
> Angewohnheit, mit 3D-"Beschleunigung" auch schon mal langsamer zu sein
> als ohne.

Das könnte es natürlich auch sein, das habe ich ganz vergessen. Aber ja, 
das stimmt, die Hardware 3d Beschleunigung von S3 war einfach grottig. 
:D

Wenn man es genau wissen will, wird man die Antwort aber sicherlich auf 
der ersten Seite des verlinkten Threads finden, aber mir fehlt dazu 
gerade die Zeit das genauer zu recherchieren.

>> Auf jeden Fall sind die Zahlen bezüglich dem Raspberry Pi 2 vernichtend.
>
> Quake war extrem stark auf genau die Eigenschaften eines Pentium
> zugeschnitten. Man hat Teile der Berechnungen auf die FPU ausgelagert,
> die beim Pentium erstmalig schnell genug dafür war, und der
> Assembler-Code war handoptimiert, um CPU und FPU parallel zu nutzen und
> dabei möglichst immer gleichmäßig auszulasten. Das wird in einer
> Emulation dann vermutlich überhaupt nicht mehr passen.

Ja, das könnte sein.

Das Quake die FPU des Pentium intensiv nutze, ist mir auch bekannt.
Die Leute, die sich einen 486er DX4 100 MHz gekauft haben, weil der in 
manchen Spielen schneller als ein Pentium 60 MHz war, haben dann 
spätestens bei Quake in die Röhre geschaut.

Aber John Carmack ist auch ansonsten ein genialer Entwickler:
https://en.wikipedia.org/wiki/Fast_inverse_square_root

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> DPA schrieb:
>> Nano schrieb:
>>> Es muss eine Vollemulation sein, da der x86 Code nicht auf einer ARM CPU
>>> läuft, zumal Screenshots darüber ohnehin keine Auskunft geben können,
>>> was da unter der Haube werkeln  muss.
>>> Oder verstehst du unter Vollemulation etwas anderes?
>>
>> Ich verstehe darunter die Emultion eines vollständigen Systems,
>> inklusive OS und allem. Bei quemu-user emulation ist das nicht der fall,
>> der Kernel/das OS wird nicht emuliert, sondern nur die Anwendung. Die
>> Syscalls, die die Anwendung nutzt, werden einfach an den bereits
>> laufenden Kernel weitergegeben.
>
> Okay, also eines sei hierzu gesagt.
> Wenn die x86 Anwendung einen Syscall macht, dann wird der unter einem
> Kernel, der für ARM gebacken wurde, nicht funktionieren.
> So eine Userspace Emulation kann man machen, wenn die CPU Architektur
> die gleiche ist.
> Das wird hier aber nicht funktionieren und wenn doch, dann muss da vor
> dem Syscall noch eine Zwischenschicht rein, die darauf achtet und die
> beiden Architekturen kompatibel macht, also Antworten von der ARM
> Umgebung in x86 Antworten umwrappt. Mir ist aber nicht bekannt, das man
> das schon gemacht hat.

qemu-user erledigt das bereits. qemu-system ist eine Vollemulation, aber 
qemu-user emuliert nur die Anwendung. In der regel verwendet man es 
zusammen mit binfmt-misc, damit der Emulator beim Aufruf einer 
Userspaceanwendung anderere Architektur sofort verwendet wird.

Lies doch einfach mal die Dokumentation zu qemu-user, wenn du das nicht 
glauben willst, stat immer wieder zu behaupten das könne nicht gehen:
https://wiki.debian.org/QemuUserEmulation
https://qemu.weilnetz.de/doc/qemu-doc.html#QEMU-User-space-emulator
Es ist sogar auf der Startseite erwähnt! https://www.qemu.org/

Das Packet gibt es für arm*. 
https://packages.debian.org/stretch/qemu-user-static
Darin sind jeweils user-mode emulatoren für viele Architekturen, 
inklusive qemu-x86_64-static und qemu-i386-static.

Ich weiss nur nicht, wie stabil das läuft. Bisher hab ich eben nur die 
andere Richtung gebraucht, also arm64 Anwendungen auf x86-64. Genauer 
gesagt verwende ich das momentan in meinem librem5 image builder, um die 
second stage vom bootstrapping eines arm64 systems auf einem x86_64 PC 
durchführen zu können:
https://github.com/Daniel-Abrecht/librem5-image-builder

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, vielen Dank für die vielen Antworten, die in der Zwischenzeit 
noch gekommen sind!
Ich hatte gestern endlich Zeit, mal wieder den Faden aufzunehmen und 
wollte Exegear wie hier beschrieben ausprobieren:

https://www.instructables.com/id/Gaming-Beyond-RetroPie-x86-Games-on-Raspberry-Pi/


Dabei ist aufgefallen, dass Exegear vor kurzer Zeit komplett "vom Netz 
gegangen" und nicht mehr verfügbar ist.

Nano schrieb:
> 1. Hostsystem: Rasbian oder Debian + QEMU Full X86 Emulation
>    Gastsytem: Windows 2k oder XP oder eventuell auch Win9x/Me
>    Spiel: Windows Version.

Danke Nano für die umfangreiche Antwort. Werde das unter 1. nach deiner 
Empfehlung als nächstes testen...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.