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?
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.
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.
> 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.
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?
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.
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.
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.
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 :)
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.
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.
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:
https://www.youtube.com/watch?v=hw7gvrTDaco
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.
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.
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
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/QemuUserEmulationhttps://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
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...
