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
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?
> Wo hast du diese Info gefunden? Dass Pi ARM ist? Das ist bekannt. Dass x86-Binaries nicht auf ARM laufen? Ist auch bekannt.
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/
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.
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.
> 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/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
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.