Zu hohe Hardwaranforderungen für Emulation?

Emulatoren, Virtuelle Maschinen und Source Ports
BluesmanBGM
HELP.COM-Benutzer
Beiträge: 37
Registriert: Fr 10. Aug 2018, 10:46

Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Mo 27. Aug 2018, 09:04

Mal eine generelle Frage: ich habe manchmal den Eindruck, daß die Hardware-Anforderungen von Emulatoren weitaus höher sind, als sie eigentlich sein müssten. Liegt der Eindruck nur an mir, oder ist dem wirklich so? Könnte so mancher Emulator unter DOS bei effizienter Programmierung auch auf älteren PCs bzw. unterhalb der Pentium-Schwelle flüssig(er) laufen?

Damit meine ich jetzt nicht, daß ich von einem 386er erwarte, einen Amiga oder eine Playstation etc. flüssig zu emulieren. Irgendwo muß natürlich eine Grenze sein. Aber sollte es nicht theoretisch möglich sein, mit einem schnellen 486er (66 Mhz oder mehr) einen Großteil der 8-Bit-Rechner und Konsolen akzeptabel zu emulieren, eventuell auch einige 16-Bit-Geräte? In der Praxis geht das ja leider oft nicht.

Mal zwei Beispiele bzw. Denkanregungen: vor einiger Zeit hatte ich nach einem guten Gameboy-Emulator für DOS gesucht. Es finden sich ja auch einige online, manche davon wollen aber mit echtem DOS nicht recht funktionieren oder haben hohe Anforderungen. Bei einem Emulator stand z.B. in der txt, daß er eventuell "auch" noch mit weniger als 400 Mhz funktioniert, wenn man mit den Frameskip-Werten rumspielt. So genau konnte das der Programmierer aber nicht sagen, solche "langsamen" Rechner hatte er nämlich nicht zum Nachprüfen. Alles unter DOS, wohlgemerkt.

Ich habe dann einen gut funktionierenden Emulator namens VGB gefunden, dessen Anforderungen in der txt mit "mindestens 486DX/33, empfohlen 486DX/66" angegeben sind. Läuft auf dem P166 natürlich absolut flüssig. Wie detailliert und komplex die Emulation nun intern funktioniert, weiß ich nicht, aber es haben damit zumindest alle regulären GB-Programme funktioniert, die ich ausprobiert habe. Und das ist für mich die Hauptsache. Wie kann es also sein, daß ein Emulator des selben Systems einen Pentium 2 mit mehr als 400 Mhz "benötigt" und ein anderer mit einem Mittelklasse-486er auskommt? Das Endresultat (GB-Spiel mit Sound und Musik unter DOS) ist bei beiden Programmen nach außen hin das Gleiche.

Zweites Beispiel: auf meinem XT mit weniger als 10 Mhz habe ich einen C64-Emulator, der nur mit Monochrom-Monitor läuft. Das ist zugegeben eine ziemlich unausgereifte Sache, und man kann damit nicht viel mehr machen, als ein wenig in BASIC 2.0 programmieren. Aber in dieser Hinsicht verhält er sich tatsächlich erkennbar wie ein echter C64. Und man kann mit 8088er und weniger als 10 Mhz sogar halbwegs gut damit Programme eintippen. Als dann im Laufe der 90er die ersten "echten" C64-Emulatoren auftauchten, schraubten sich die Anforderungen mit steigender Kompatibilität zum Original aber schnell nach oben, und selbst für DOS-Versionen von z.B. VICE reichte bald ein schneller 486er nicht mehr für originale Geschwindigkeit aus.

Die Frage ist: muß das sein? Ist eine (ausreichend) akkurate Emulation selbst von 8-Bit-Systemen tatsächlich kaum möglich, wenn man nicht mindestens einen Pentium mit 100 Mhz+ zur Verfügung hat? Oder haben sich die Programmierer einfach (stets) darauf verlassen, daß sowieso jeder Anwender einen aktuellen Rechner zur Verfügung hat, und daß effizienter Code gar nicht nötig ist? Und liegt es vielleicht auch daran, daß viele Emulationen einfach zu komplex und überfrachtet geworden sind, nur weil jeder Anwender unbedingt die x-fache Bequemlichkeit und Funktionsumfang wie auf dem Original haben will?

Was ist wichtiger - ein Emulator, der mit relativ wenig Ressourcen dazu in der Lage ist, ein anderes Gerät nach außen glaubhaft nachzubilden? Oder ein Emulator, der gigahertzweise Leistung verbrät, nur weil er intern z.B. ein 100% exaktes Thermalmodell erstellt, und jedes mögliche Staubkorn auf virtuellen Bausteinen einzeln emuliert? Nicht, weil es nötig ist, sondern weil es heutzutage geht.

Zumindest auf meinem P166 habe ich unter DOS eine ordentliche Auswahl von guten Emulatoren gefunden, die darauf flüssig bis annehmbar laufen, einige haben auch "schnieke" Oberflächen und GUIs wie HuGo, ZSNES oder MEKA (letzter siehe hier):

Bild

Und trotzdem frage ich mich manchmal, ob es theoretisch möglich wäre, auch aus z.B. einem 486DX2/66 eine vielseitige und flüssig laufenden Emulationsmaschine zu machen, wenn es effizientere und mehr auf originales DOS und ältere Rechner angepasste Emulatoren gäbe. Nur reines Wunschdenken oder möglich? Meinungen?

Chris

P.S. Sagt mir bitte, wenn ich zuviel rede ;-).
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3636
Registriert: Mi 24. Mai 2006, 20:29

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon Dosenware » Mo 27. Aug 2018, 17:12

Neben der Wirtsplattform (Dos/Windos/Linux/Beos/und wie sie alle heißen) spielen auch die Programmiersprache, die Effizienz der Programmierung (da hängt auch die Programmiersprache mit drin) sowie die Genauigkeit der Emulation eine Rolle.

Man denke nur an den PSXE mit seinen unzähligen Patches für verschiedene Spiele - er Emuliert eben etwas zu ungenau, andere Emulatoren haben bereits Patches für viele Fälle intigriert, ohne dass man sie extra aktivieren muss.
Und das Problem bei der Genauigkeit ist das Timing - teilweise entscheiden Nanosekunden darüber ob etwas funktioniert, oder nicht, das kann man entweder per Patch emulieren, oder durch Genauigkeit - was dann aber massig Leistung frisst (und den Vorteil hat das ALLES funktioniert).

Mal als Bleistift: Versuche mal einen C64 zu Emulieren samt den undokumentierten Befehlen, sowie den undokumentierten Videomodes - am besten noch mit dem "Coprozessor" 1541 und all den anderen Besonderheiten der Systeme.
Je Hardwarenaher und je Trickreicher die Programmierung war, desto schwieriger ist eine Nachbildung die alle Fälle abdeckt.
GMBigB
Norton Commander
Beiträge: 119
Registriert: Fr 5. Mär 2010, 13:30

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Mi 29. Aug 2018, 14:13

Ich kenne die C64-Emulatoren der 1.Stunde (PC64, C64s usw...) und habe selbst auch Emulatoren geschrieben. Die Rechenleistung eines 486DX/66 reicht theoretisch für eine 100%-ige Emulation aus, auch mit Prozessor in der 1541, den illegalen Opcodes und den Eigenheiten des Grafikchips. Allerdings bleibt dann keine Zeit mehr die Grafikdaten über den Bus zu schicken. Mit den Rändern liefert der C64 eine Auflösung von 384 x 272. Wenn du das mit 50fps anzeigen willst, so wie es der C64 macht, benötigst du fast die gesamte Rechenzeit um die Daten über den Bus zu schicken. Das Problem bei der Emulation ist also gar nicht so sehr der Prozessor, der emuliert werden muss, sondern die Grafikausgabe. Daher ist man früher Kompromisse eingegangen und hat dann eben eine 95%-ige Emulation bei reduzierter Framerate gemacht.
BluesmanBGM
HELP.COM-Benutzer
Beiträge: 37
Registriert: Fr 10. Aug 2018, 10:46

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Do 30. Aug 2018, 09:50

Mal aus Interesse - würde es denn spürbar Rechenzeit sparen, wenn man den C64-Rahmen bei der Emulation weglässt? Hätte man dann ausreichend Ressourcen übrig, um sich auf die Feinheiten der restlichen Emulaton zu konzentrieren?

Vom C64s gibt es ja auch eine "low end"-Version namens C64s386. Die läuft nur ohne Rahmen und mit leider doch sehr eingeschränkter Kompatibilität. Komplexere Programme sind damit nicht zu verwenden.

Der normale C64s (ohne Rücksicht auf low end) läuft zur Not übrigens auch auf einem 386SX, setzt also anders als VICE keine FPU voraus. Aktuelle Programme führt er im Prinzip auch aus, siehe hier z.B. "Caren and the Tangled Tentacles" auf 386SX mit 90er-Jahre-C64s. Ich gehe mal davon aus, daß in dem Spiel doch einige Kniffe und Programmiertricks verwendet werden, die einen gewissen Grad an Komplexität in der Emulation voraussetzen. Es geht also "im Prinzip", von einer originalen oder wirklich spielbaren Geschwindigkeit ist man aber ohne 486er weit entfernt.

Bild

Chris
GMBigB
Norton Commander
Beiträge: 119
Registriert: Fr 5. Mär 2010, 13:30

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Do 30. Aug 2018, 12:22

Ich vermute, dass die eingeschränkte Kompatibilität des C64s386 daher rührt, dass die 1541-Emulation weggelassen wird. Dadurch laufen alle Spiele, die einen Turbolader verwenden, nicht mehr. Das ist bereits eine relativ große Einsparung bei der Rechenzeit, denn immerhin läuft in der 1541 eine ähnliche CPU wie im C64. Ich würde hier mal auf 30% tippen. Bei der CPU selbst sehe ich keine Abstufungen bei der Emulation. Was die illegalen Opcodes machen ist gut bekannt. Deren Emulation wegzulassen spart keine Rechenzeit. Wenn C64s386 auf die Rahmen verzichtet, spart das ein kleines bisschen Rechenzeit, da man den Trick mit dem Öffnen der Rahmen für Sprites nicht berücksichtigen muss. Man kann sich sozusagen die zyklengenaue Emulation des VIC (Grafikchip) sparen. Mehr als 10% Einsparungspotential sehe ich da aber nicht. Ich würde diesen Trick bereits zu den "Feinheiten der Emulation" zählen. Beim Soundchip kann man auch beliebig fein oder grob emulieren. Enthusiasten sind der Meinung einen echten SID immer noch von der besten Emulation unterscheiden zu können. Der C64s386 wird sich hier vermutlich auch mit einer sehr einfachen Emulation begnügen.

Ich sehe übrigens nicht, dass "Caren and the Tangled Tentacles" irgendwelche Programmiertricks verwendet, die eine Emulation erschweren würden. Das Spiel ist toll, aber technisch nicht sooo anspruchsvoll. :-)
BluesmanBGM
HELP.COM-Benutzer
Beiträge: 37
Registriert: Fr 10. Aug 2018, 10:46

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Mo 10. Sep 2018, 11:02

Zum Thema (prinzipiell) effiziente und schlanke Emulatoren hier vielleicht noch ein interessantes Beispiel: den NoCashC64-Emulator in der DOS-Version 1.1 von 2005.

http://problemkaputt.de/c64.htm

NoCash war mir bisher nur vom guten GBA-Emulator bekannt (recht effektiv, auf P166 mit Abstrichen spielbar), aber man hatte sich unter dem Namen auch schon an einem Commodore-Emulator versucht, der jede Menge Debugging-Funktionen hat. Und in der einzelnen exe-Datei stecken neben dem C64 sogar (angeblich) ein VC20-, ein C16- und ein Plus-4-Emulator. Der Programmierer ist jedenfalls sehr von seinem Projekt überzeugt, Zitat: "a must-have for professional C64 programmers..."

In der Realität ist der Emulator wohl etwas umständlich zu bedienen, hat keinen Rahmen, keinen Ton und ist auch sonst sehr eingeschränkt kompatibel. Das wichtige d64-Format geht auch nicht. Ich habe jedenfalls beim kurzen Ausprobieren nur ein paar C16-prg-Dateien ohne Ton zum Laufen gebracht. Die Plus4-Emulation scheint mir auch eine Mogelpackung zu sein - es ist bestenfalls ein C16 mit Speichererweiterung.

Was aber trotzdem interessant ist, ist die Vielzahl an Funktionen und theoretischen Möglichkeiten in einer einzigen exe-Datei mit knapp 190 KB. Unter dem Menüpunkt "Fixed Options" gibt es auch Einstellungen wie "Fast on 386" oder "XT/AT Compatibility". Ob das was bringt und wie sich der Emulator auf PCs unterhalb Pentium verhält, habe ich aber noch nicht ausprobiert.

Chris
Benutzeravatar
FGB
DOS-Übermensch
Beiträge: 1878
Registriert: Di 15. Feb 2011, 12:02

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon FGB » Sa 13. Okt 2018, 02:48

Generell ist bei Emulatoren heutzutage die Ineffizienz ein großes Problem, wenn man alte Hardware verwenden möchte. Durch unsauberes Programmieren ist es leicht, Ressourcen zu verschleudern, die dann in älteren Systemen fehlen. Das geht 1:1 zu aktuellen Spielen mit ihren teilweise absurden Hardwareanforderungen.

Nocash ist ein Beispiel für ressourceneffizientes Programmieren. Das Programm ist einfach toll und vor allem sehr flexibel einsetzbar.
Meine Sammlung zeige ich in meiner Hardware Gallery: AmoRetro.de.
BluesmanBGM
HELP.COM-Benutzer
Beiträge: 37
Registriert: Fr 10. Aug 2018, 10:46

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Mi 7. Nov 2018, 13:50

Noch ein kurzer Nachtrag: ich hatte mir gestern noch die ganz aktuelle Version vom Nocash-GBA geholt (exe-Datei vom 30.09.2018). Der läuft auch weiterhin auf P166 mit DOS 6.20, sogar mit Sound von der ISA-Soundkarte. So gefällt mir das.

Wie mir erst jetzt aufgefallen ist, soll der nocash-GBA ja auch das neuere Nintendo DS (mitsamt den zwei Bildschirmen?) emulieren können. Hat das schon mal jemand unter DOS versucht? Ich vermute jetzt mal, mit einem P166 kommt man da geschwindigkeitsmäßig nicht weit, oder?

Chris
DOSferatu
DOS-Übermensch
Beiträge: 1159
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon DOSferatu » Sa 29. Dez 2018, 09:23

Ich habe den Thread hier lange in einem Tab offengelassen, weil ich auch noch meinen Senf dazugeben wollte.
Und - JA! - meiner Meinung nach sind die Hardwareanforderungen (nicht nur für Emulatoren) heutzutage bei allem wesentlich höher als sie sein müßten.

Von der industriellen Seite her ist das Ganze wahrscheinlich eine Zeit/Kosten-Frage, denn Dinge in Skripten zu "programmieren" geht schneller/einfacher als in Interpreter(hoch)sprachen, was schneller/einfacher als in Compiler(hoch)sprachen geht und das schneller/einfacher als in Assembler/Maschinencode.

Assembler/Maschinencode ist die einzige Form, in der man wirklich ALLE Fähigkeiten eines Systems optimal ausnutzen kann. Ja, natürlich sind die Algorithmen, die man verwendet, wichtig und entscheidend für gute Performance - aber wenn man seine Algorithmen von Anfang an gleich an die Fähigkeiten und Gegebenheiten der CPU/CPU-Familie anpaßt, erhält man das optimalste Ergebnis. (Manche Register/-kombinationen können manches schneller. Manche Register können manches gar nicht oder nur über Stack-Umwege. Dann das ganze Verhalten bei bedingten Sprüngen usw. usf.)

Und ja, an dieser Stelle hört man dann oft so C-Programmierer schreien, daß die heutigen Compiler dermaßen toll sind und dermaßen gut optimieren, daß sie jede manuell erzeugte Arbeit in Assembler in den Schatten stellen würden. Die Realität hat bereits oft bewiesen, daß dem nicht so ist. (Beispiel: Best-/Worst-Case-Szenarien kann ein Compiler z.B. gar nicht erkennen, weil er ja nicht "sieht", was das Endprodukt eigentlich tun soll.)

Bei manchen Emulatoren hatte man z.B. bereits schnelle effiziente Assembler-Subroutinen(!) und hat sie (durch Leute, die das in Folge "weiterentwickelt" haben, durch Hochsprache (in dem Fall C) ersetzt - was den Emulator fühlbar deutlich langsamer gemacht hatte. (ja, ZSNES)

Die Entscheidung für den Einsatz einer systemübergreifend funktionierenden Compilersprache basiert eher auf Dingen wie Zeit, Kosten oder - im nichtkommerziellen Bereich - wahrscheinlich auch öfter mal Faulheit. Mit dem gleichen Code verschiedene Systeme zu bedienen, ist natürlich ein großes Plus für den Entwickler. Andererseits kann so nie auf die Besonderheiten des entsprechenden Systems bis in's letzte Bit eingegangen werden.

Der Nachteil von Assembler ist natürlich, daß man für jedes System (bzw. jede CPU-Familie) eigenen Code schreiben muß. Hier wäre ein "Mittelweg" wahrscheinlich auch nicht die schlechteste Idee: Bedienung der (Emulator-) GUI und ähnlichen "systemfernen" Kram könnte man in Hochsprache oder sogar Skripten abwickeln - dafür die sogenannten "inneren Schleifen" des wirklichen Emulators dann eiskalt in reinem Assembler dreinhacken - damit würde man einen Teil des Codes (nämlich den nicht performance-relevanten) portierbar halten, aber die zeitkritischen Dinge weiterhin an das System anpassen. (Nur eine persönliche Meinung.)

Manche "Experten" und "IT-Fachleute" und wasweißich, welche selbsternannten Programmiergötter sind heutzutage schon mit kleinsten Dingen überfordert, wenn nicht mindestens Quadcore 4 GHz und 1 TB RAM zur Verfügung stehen, sowie diverse von anderen fertiggestellte "Frameworks". Da heißt es dann einfach "geht nicht". (Für jemanden, der sich stolz "Programmierer" und "IT-Fachmann" nennt, sowie so stolz auf seine abgeschlossenen Studiengänge in entsprechenden Branchen ist, ist so etwas meiner persönlichen Meinung nach ein Armutszeugnis.) Und ja - ich habe einen Kumpel (befreundeten Computerfreak der "alten Schule"), der - u.a. berufsbedingt - öfter mit solchen Leuten zu tun hat. Er hatte da letztens mal wieder mit so einem Menschen gesprochen, da sollten irgend eine netzwerkbasierte Auswertung von gesendeten Parameterdaten einer Maschine ausgewertet werden. Und derjenige kam dann auch gleich mit: Da bräuchte man Paket X und Framework Y usw... und als mein Kumpel anmerkte, daß das Ganze aber live auf einem Microcontroller laufen soll, mit Speicher im kByte-Bereich und Leistung im ein-/zweistelligen MHz-Bereich, hieß es auch gleich: "geht dann nicht..."
Ging dann aber doch. (Nur eben ohne GB-große und performancefressende Programmpakete, die im Normalfall 90% der vorhandenen Leistung/Speicher für sich selbst beanspruchen.)

Letztens haben die im Coding-Board mal wieder einen kleinen "Wettbewerb" gemacht (nichts schlimmes, nichts zu gewinnen oder so). Es ging um ein Programm, das Sudokus löst. Eigentlich hatte ich gar nicht mitmachen wollen, aber zufällig war es etwas, das ich sowieso schonmal machen wollte, da bot sich das an.
Meine Lösung war in Turbo-Pascal (war nur eine Machbarkeitsstudie meinerseits) und brauchte je nach "Schwierigkeit" des Sudokus zwischen 0.x und 4 Sekunden auf meinem 486er. Die Leute mit den Skriptsprachen haben entweder gar keine Lösung oder eine verbuggte angeboten (also eine, die teilweise falsche Ergebnisse liefert) ODER Lösungen, die zum Lösen eines Sudoku mehrere TAGE benötigt (und zwar auf dem für den Wettbewerb benutzten Zielsystem - also einem modernen Rechner). - Aber dafür sah deren Programmcode wahrscheinlich "elegant aus"...

Vielleicht setze ich meinen Sudoku-Löser nochmal in Assembler um (meine Herangehensweise wäre leicht in ASM umzusetzen) und baue eine schicke Eingabemaske dafür, sobald ich mal die Zeit dafür erübrige. Momentan hat das keine Priorität, weil ich mit anderen Dingen beschäftigt bin, die mich viel mehr interessieren - und ich komme sowieso schon zu nichts.

Allerdings hat man früher auf 8-Bit und frühen 16-Bit-Systemen auch schonmal alles komplett in Assembler programmiert (alles "ernstzunehmende auf 8-Bit war ausschließlich in Assembler). Das ist nichts Schlimmes oder Böses und auch nichts, was "nicht geht". Daran ist also auch nichts lächerliches. - So etwas würde aber heute niemand mehr machen? - Ach ja? Dann schaut mal hier:
https://www.youtube.com/watch?v=szhv6fwx7GY
https://www.youtube.com/watch?v=QUzVesdY6OU
https://www.youtube.com/watch?v=BdhvIfmRtvQ
https://www.youtube.com/watch?v=-dvpMVJ7WGA
(Man beachte vor allem das anvisierte Zielsystem!)
(oder, das Ganze für C64, hier: https://www.youtube.com/watch?v=NB_VBl7ut9Y )

Anm.: Mein vor über 12 Jahren selbstgebauter C64-Emulator läuft auf meinem 486er eigentlich recht gut - und da ist viel Pascal drin. Die innere Schleife ist natürlich in 100% Assembler, allerdings hatte ich damals noch weniger Erfahrung in x86-Assembler - hier ginge wohl inzwischen noch einiges mehr. Das würde ich dann eher komplett neu machen.

So, das soll erstmal mein Senf dazu gewesen sein. Kam vielleicht etwas spät - aber wollte das mal loswerden.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast