Seite 1 von 2

Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mo 27. Aug 2018, 09:04
von BluesmanBGM
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 ;-).

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mo 27. Aug 2018, 17:12
von Dosenware
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.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mi 29. Aug 2018, 14:13
von GMBigB
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.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Do 30. Aug 2018, 09:50
von BluesmanBGM
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

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Do 30. Aug 2018, 12:22
von GMBigB
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. :-)

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mo 10. Sep 2018, 11:02
von BluesmanBGM
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

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Sa 13. Okt 2018, 02:48
von FGB
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.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mi 7. Nov 2018, 13:50
von BluesmanBGM
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

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Sa 29. Dez 2018, 09:23
von DOSferatu
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.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Mi 23. Jan 2019, 21:21
von GMBigB
DOSferatu hat geschrieben:
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.
Die heutigen Compiler sind schon sehr gut. Auf einer x86-Platform wirst du für einfache Programme, dazu zähle ich mal den erwähnten Sudoku-Löser, große Schwierigkeiten haben mit Assembler-Code einen C-Compiler zu schlagen. Das liegt daran, dass die Prozessoren sehr komplex geworden sind, und Compiler so etwas wie Pipelining, Branchprediction oder Cache Hits berücksichtigen. Wenn du auf einem modernen Prozessor in Assembler so programmierst, wie du es von einem 6502 oder 68000er gewohnt bist, dann stellt ein Compiler deine Arbeit tatsächlich locker in den Schatten.

Natürlich schlägt der beste Assembler-Code auch heute noch C-Code, aber der Abstand ist doch sehr gering. Hier sei Stockfish erwähnt, das aktuell beste Schachprogramm. Jemand hat sich vor ein paar Jahren mal die Mühe gemacht und die Engine komplett in Assembler programmiert. Ergebnis: 25% schneller. Das ist ungefähr auch das, was man auch in anderen Bereichen, in denen Assembler noch eine Rolle spielt (z.B. Videodekodierung), rausholen kann.

Ein Teil des Geschwindigkeitsgewinns rührt übrigens daher, dass die Hochsprachen es versäumt haben, neue Datentypen einzuführen, die moderne Prozessorfeatures nutzen. Mit Erweiterungen a la SSE oder SSE2 kann man viele Rechenoperationen parallel ausführen. Dazu gibt es 128 Bit-Register, die vier 32-Bit-Zahlen enthalten. Doof nur, dass mir die Hochsprache keinen 4x32Bit-Datentyp anbietet - und der Compiler kann nur bedingt erkennen, dass man Rechenoperationen auf diese Art bündeln kann. Gleiches gilt für viele Bitoperationen, die z.B. BMI mitbringt, aber die keine Hochsprache unterstüzt.

Dass Softwareentwickler heute nicht mehr schlanke und resourcenschonende Programme schreiben können, liegt daran, dass sie es nie gelernt haben - ganz einfach weil diese Fähigkeit heute kaum noch gebraucht wird. Ich habe selbst schon bei Projekten mitgearbeitet, wo man lieber zwei Dutzend Server gekauft hat, obwohl mit Optimierung des Codes und Umstieg auf eine andere Programmiersprache ein einziger Server ausgereicht hätte. Und so haben zwei Dutzend Server rund um die Uhr Javascript-Code interpretiert - ganz einfach weil es günstiger so war. Wem will man diese Entscheidung verübeln?

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Sa 26. Jan 2019, 08:44
von DOSferatu
GMBigB hat geschrieben:Die heutigen Compiler sind schon sehr gut. Auf einer x86-Platform wirst du für einfache Programme, dazu zähle ich mal den erwähnten Sudoku-Löser, große Schwierigkeiten haben mit Assembler-Code einen C-Compiler zu schlagen.
Ja, wie erwähnt - den Roman kenn ich schon auswendig. Man muß dazu trotzdem sagen, daß ein Compiler nur das machen kann, was der Programmierer eingibt.
GMBigB hat geschrieben:Das liegt daran, dass die Prozessoren sehr komplex geworden sind, und Compiler so etwas wie Pipelining, Branchprediction oder Cache Hits berücksichtigen.
Solange Dinge wie diese vorhanden sind. Das bedeutet, daß so etwas erst einmal vorausgesetzt sein muß.
Also: Wenn es auf einem 386er oder 486er laufen soll (siehe Thread-Topic: Es ging um Emulation alter Systeme), dann kann man von solchen Dingen schon wieder nicht ausgehen. Und meiner Meinung nach reicht ein mittelguter 486er dicke aus, um alte 8bit und frühe 16bit Konsolen gescheit und spielbar zu emulieren (wenn auch vielleicht nicht mit 100% voller Framerate).
GMBigB hat geschrieben:Wenn du auf einem modernen Prozessor in Assembler so programmierst, wie du es von einem 6502 oder 68000er gewohnt bist, dann stellt ein Compiler deine Arbeit tatsächlich locker in den Schatten.
Das mag sein - aber das ist ja genau das Thema hier: "Zu hohe Hardwareanforderungen..."
Auf einer 4 GHz Octocore Maschine mit 1 TB RAM oder so kann wahrscheinlich jedes noch so dämliche Skriptkiddie ein ruckeliges Tetris oder TicTacToe hinzaubern... Aber es geht ja hier darum, nur die Systemleistung/-ressourcen zu benutzen, die wirklich nötig sind - und eben NICHT mit überkandidelten "Standheizungen" Dinge zu tun, die Leute in den 80ern mit Systemen geschafft haben, die nicht mal eine Passivkühlung brauchten...
GMBigB hat geschrieben:Natürlich schlägt der beste Assembler-Code auch heute noch C-Code, aber der Abstand ist doch sehr gering. Hier sei Stockfish erwähnt, das aktuell beste Schachprogramm. Jemand hat sich vor ein paar Jahren mal die Mühe gemacht und die Engine komplett in Assembler programmiert. Ergebnis: 25% schneller. Das ist ungefähr auch das, was man auch in anderen Bereichen, in denen Assembler noch eine Rolle spielt (z.B. Videodekodierung), rausholen kann.
25% ist aber schon eine ziemliche Hausnummer!
Und: Alleine die "systemübergreifende" Programmierung verhindert, daß man sich direkt auf die Maschine einläßt. Manche Programme/Algorithmen sind für bestimmte CPU-Architekturen super geeignet und erzeugen auf der anderen ein Worst-Case-Szenario. Daran kann auch ein Cross-Compiler nicht wirklich etwas ändern - weil er ja im Kern immer noch das umsetzen soll, was der Programmierer da eingegeben hat. Wenn man aber um die Stärken und Schwächen des jeweiligen Systems weiß, programmiert man gleich ganz anders. (Das ist wie beim Autofahren: Wer weiß, wie die Kiste funktioniert, fährt mit weniger Systemverschleiß. Thema "Wer laut schaltet, braucht nicht hupen"...)
Und ja, das klingt so wie "keine systemübergreifende Programmierung, sondern für jedes Hostsystem getrennt entwickeln" (zumindest die "Inneren Schleifen"). Und ja, genau das - und nur das! - bringt die Performance mit, von der ich rede. Ja, das ist mehr Aufwand. Aber es geht ja in diesem Thread um dieses Thema.
Systemferne Programmierung (ohne Kenntnis/Berücksichtigung des Hostsystems) wird niemals an die Performance heranreichen, die systembezogene Programmierung erreichen kann.
GMBigB hat geschrieben: [...]moderne Prozessorfeatures nutzen [...] SSE oder SSE2 [...] 128 Bit-Register [...]
Zählt alles zu "zu hohe Hardwareanforderungen".
GMBigB hat geschrieben:Dass Softwareentwickler heute nicht mehr schlanke und resourcenschonende Programme schreiben können, liegt daran, dass sie es nie gelernt haben - ganz einfach weil diese Fähigkeit heute kaum noch gebraucht wird.
Mag sein. Und das ist auch der Grund für "zu hohe Hardwareanforderungen" für quasi alles und jedes.
Und ja - genau solche Sachen sind die Gründe für viele "schlimme Software".

Bei "Programmierern", die an die Benutzung untypisierter Variablen (ich sag nur: "VARIANT") gewöhnt sind (die größte Sch**** unter der Sonne!)... da braucht man sich nicht zu wundern, wieso alles so speicherfressend und lahm ist. Bei untypisierten Variablen muß bei jedem Zugriff (egal ob bei Zuweisungen, ob sie in einer Formel auftreten oder ein Parameter sind) geprüft werden, was sie "denn heute gerade wieder sind": Fließkomma/Integer? Vorzeichen oder nicht? Vielleicht ein String? (ASCII? Unicode? Irgendwas proprietäres?) Eine Menge? Ein Feld aus all dem? Ein verschachteltes Feld? Ein Record? Gar ein Pointer? Ein Pointer auf einen Pointer?
Dann den Wert herauskratzen, umwandeln, wo möglich. Fehler generieren, wenn unmöglich - ODER (was noch öfter benutzt wird), "fehlertolerant" auf irgendetwas plausibles setzen... und das bei jedem Zugriff. Falls jemand ein ... naja, Idiot ist (wie soll ich es anders ausdrücken?), benutzt er aus Bequemlichkeit und weil er es nicht anders gelernt hat, weil er es aus (Web-)Skripts kennt oder was weiß ich, so VARIANT-Variablen für alles und jedes - also auch für Schleifenvariablen und wasweißich. Achja - und natürlich ist die Wertebereichsprüfung auch die ganze Zeit angeschaltet - wenn man zu dusslig ist, wenigstens seine internen, selbst gesetzten und geänderten Variablen durch Programmierung im plausiblen Wertebereich zu lassen, muß das bei jedem Zugriff durch eine Bilbiothek geprüft werden... und so weiter... Und das Ganze wird dann natürlich nicht compiliert - ist ja viel praktischer, wenn man's im Entwicklungssystem jeweils live sehen kann, also ist da ein Interpreter drunter, der selbst ebenfalls nicht auf dem nativen System, sondern auf 'ner VM läuft, die in irgend einem Web-Dialekt-Skript geschrieben ist...

Wenn wenn so jemand ein Programm (Spiel, Anwendung, wasauchimmer) baut und die läuft auf der aktuellsten 4 GHz Octocore 1TB RAM Atomrakete von Computer noch gerade so einigermaßen ruckelfrei (auch wenn sein Tic-Tac-Toe in Multitask-Systemen jeweils 95% der Rechenleistung für sich beansprucht...) --- und ihm dafür dann auch noch jeder auf die Schulter klopft: "Haste fein gemacht"... bzw. sowas dann schon als "IT-Experte" zählt (oder er sich zumindest so fühlt)... Dann wird er nie erfahren, was er eigentlich im Computer "damit anrichtet" oder wieso die Raumtemperatur jedesmal steigt wenn jemand sein Spiel spielt.
Und dann lernt der auch nie vernünftig programmieren.
GMBigB hat geschrieben:Ich habe selbst schon bei Projekten mitgearbeitet, wo man lieber zwei Dutzend Server gekauft hat, obwohl mit Optimierung des Codes und Umstieg auf eine andere Programmiersprache ein einziger Server ausgereicht hätte. Und so haben zwei Dutzend Server rund um die Uhr Javascript-Code interpretiert - ganz einfach weil es günstiger so war. Wem will man diese Entscheidung verübeln?
Niemand verübelt hier irgend etwas. Aber in diesem Thread geht es eben genau darum - daß heutzutage lieber "mit Kanonen auf Spatzen geschossen wird", anstatt etwas mehr Mühe in die Software zu stecken.

Ich sag's mal so: Ich habe noch keine modernen Compiler zerpflückt oder entsprechend erzeugten Code analysiert, um zu sehen, was diese können und wie diese optimieren, um sowohl Rechenpower, Speicher oder beides zu sparen.
Aber ich wage zu bezweifeln, daß sie:
1) komischen Anfänger-Spaghetticode, der sich über 1000 Zeilen erstreckt, entzerren, die hin-/her-Sprünge selbständig entfernen, Subroutinen, die nur 1x im ganzen Programm aufgerufen werden, gleich ins ""Hauptprogramm" einbauen...
2) komische IF-Kaskaden/Sprungsequenzen, die ein mittelmäßiger Programmierer fabriziert hat, automatisch umwandeln würden z.B. in einen einzelnen statusabhängigen Sprungbefehl plus Sprungtabelle (Look-Up-Table).
3) Anstatt Funktions-/Subroutinen-/-Parameter langsamer über den Stack zu übergeben, diese per Register zu übergeben (ja, ich weiß, daß C-Compiler inzwischen auch, wenn man es ANGIBT, manche Variablen über Register lösen)
4) Anstatt für "stackartig" gespeicherte Bytes/Nybbles o.ä. den Stack zu benutzen, stattdessen ein Register als schnellen "Pseudo-Stack" benutzen (wie ich es z.B. mal gemacht habe, für meine über 10 Jahre alte 4-Ebenen-8-Richtungen-Scroll-Levels-Engine)
5) Verschiedene Sub-Bereiche z.B. eines 32bit-Registers als einzelne Adder/Flags zu benutzen, bzw z.B. das gleiche Register als Adder/Subtractor, um Abfragen in Schleifen zu minimieren
6) Sprünge in Schleifen so umgestalten, daß manche nicht mehr gebraucht werden, weil der Sprung gleich durch den normalen Programmablauf von allein passiert (ähnelt Punkt 1) bzw. aufeinanderfolgende Rücksprünge aus mehreren Subroutinen ersetzen durch vorherige Stackmanipulation und Ersetzen von CALLs durch JMPs
7) Direkt auf Bits des Statusregisters reagiert und diese wieder für Operationen "zweckentfremdet", wo es sich anbietet, um so Sprünge zu vermeiden
8) Programmspeicher sparen und gleichzeitig "innere schnelle Schleifen" zu optimieren, indem man selbstmodifizierenden Code benutzt, der sowohl Befehle, Mod-R/M, SIB- Bytes, Präfixbytes und/oder Parameter ersetzt oder durch "Quereinsprünge" aus Befehlen andere Befehle macht, wo es sich anbietet
... und vieles mehr ... (Das sind nur einige Beispiele der leichter verständlichen Dinge. In Assembler/Maschinencode kann man extrem tief abgehen ... je nachdem, wie nötig man es findet.)

All diese - teilweise "schmutzigen" - Dinge können Speicher und Rechenpower sparen, müssen aber von einem Programmierer berücksichtigt werden. Und, wann und wie oft z.B. ein Sprung/Aufruf in einem Programm statistisch gesehen erfolgt, weiß der Programmierer - weil er weiß, welche Art von Daten das Programm am Ende im Schnitt zu erwarten hat. Der Compiler kann es aber nicht wissen.

Und ja - ich benutze viel mein altes Turbo-Pascal 7 (von Borland), weil es Programmabschnitte gibt, wo eine Umsetzung in Assembler die Zeit und Mühe kaum Wert ist, weil der Speichergewinn und Performancegewinn demgegenüber minimal wäre. Aber gerade z.B. bei Dingen wie Grafikroutinen - gerade, wenn sie z.B. alte "Grafikmodi" irgendwelcher Fremdsysteme emulieren sollen oder vielleicht Sprites mit ihren vielen Parametern... oder vielleicht Digitalsound synthetisieren sollen... da halte ich es durchaus für sinnvoll, die sogenannten "inneren Schleifen" auch gerne mal zu 100% in Assembler umzusetzen und dies entsprechend zu optimieren.

Ich optimiere sowieso nur auf 386er (für meine "besseren"/"größeren" Projekte meine Mindestanforderung, obwohl Optimum dann eher 486er wären), und daher schaue ich wirllich auch nach, wieviele Zyklen welcher Opcode verbraucht oder ob man Geschwindigkeit gewinnt, wenn man Parameter intern in anderer Form vorhält. Wie ein sogenannter "moderner" Compiler überhaupt optimieren kann, ist mir sowieso ein Rätsel. Seit es so viele "Spezialoptionen" gibt, die eine CPU haben kann oder nicht, oder wenn, dann entweder gut oder schlecht supportet, das Gleiche für Grafikkarten usw... Da weiß man nicht, in welche Richtung so ein Compiler überhaupt optimieren will - was auf der einen CPU-Generation vielleicht total performt, schafft auf der anderen ein Worst-Case-Szenario.
(Achja: Ich werde dann immer wieder gefragt: Wieso kein Protected Mode? Naja - zunächst erst einmal ist die CPU in Protected Mode genauso schnell getaktet wie im Real Mode, also ist Protected Mode nicht "automatisch schneller" oder so. Es hängt immer von der Aufgabenstellung ab und wie man programmiert. Und manche Dinge sind in PM z.B. so kompliziert gelöst, daß manche Sachen damit sogar langsamer sind als im RM. Das segmentierte Speichermodell hat nicht nur Nachteile.)

Und ja - es ist natürlich schlimm, daß ich z.B. für meine VGA/SB-Spiele 80386er voraussetze (weil ich zwar Realmode/V86Mode, aber 32bit-Register und die erweiterten Segmentregister benutze) und so läuft es dann nicht auf 80286er, 80186er oder 8086/8088er. Aber wenn ein Emulator, der ein 30 Jahre altes System emulieren soll, schon streikt, wenn er keine 64bit-CPU und kein SSE und keine 3D-fähige Grafikkarte vorfindet - das finde ich dann wirklich schon mehr als arm.

Aber ich will meine 386er-Voraussetzung hier keinesfalls schönreden - es ist schlimm, und für 2D-Arcade muß meiner Meinung nach auch weniger ausreichen! Aber wenn man das (wie ich) einsieht, kann man auch an sich arbeiten. Vielleicht hätten auf 286er meine Sprites keine Option für Halbtransparenz mehr oder sich in 256 Stufen drehen zu können - möglicherweise auch nicht einmal mehr Skalierung. Aber nicht jedes Spiel benötigt diese Optionen - also könnte man hier auch tiefer ansetzen.

Ich bin aber auch nur eine einzelne Person - habe einen Job und das bißchen Freizeit nach der Arbeit (wenn man müde ist) und am Wochenende (wo es auch nicht immer besser ist) ist alles, was ich habe. Und im Gegensatz zu anderen (die z.B. Emulatoren bauen) habe ich auch kein "Team", sondern entwickle den ganzen Kram alleine - und ohne Benutzung fremder Bibliotheken. Deshalb bin ich natürlich SEHR langsam.

Aber ich wäre eben nicht stolz darauf und würde mich nicht mehr (Hobby-)Programmierer nennen, wenn ich mit irgend einem Game-Maker und vorgefertigten Tiles, Images, Effekten usw. ein 2D-Spiel zusammengeschlunzt hätte, was dann eine 1 GHz-Maschine mit 3D-Karte braucht, um überhaupt zu starten. Mir wäre das irgendwie peinlich...

Irgendwie habe ich auch die Erfahrung gemacht (ist natürlich rein subjektiv, jeder hat seine eigenen Erfahrungen)... daß, je mehr "Klicki-Bunti" ein Programm/Emulator wasauchimmer ist, umso weniger performt er. Also: Die Dinger(Emulatoren), die selbst mit bunten hochauflösenden mausgestützten Menüs daherkommen, sind zwar "ringsherum" nett bedienbar, aber bei ihrer eigentlichen Aufgabe, nämlich die besagten Systeme zu emulieren, performen sie nicht richtig, können manche Modi nicht richtig darstellen, oder setzen schon bestimmte - langsame - APIs voraus, um manches zu tun und alles ist eher so "Hauptsache sieht von außen gut aus und geht irgendwie".
Und demgegenüber stehen die von außen eher "häßlichen" Emulatoren, deren Menüs sich auf das Notwendige beschränken (Textmode, evtl ohne Maus), teilweise sogar nur per Kommandozeile gestartet... Aber die stammen dann oft von der NICHT "Windows-/MacOS-verspielten" Gilde, sondern von irgendwekchen maschinennah agierenden Cracks, denen es eher um die performante Emulation des Systems geht (als um das "KlickiBunti" außerhalb) und die dies vollständig und performant tun.
Das gleiche bestätigt auch mein Kumpel, der z.B. oft Dinge tut wie Videos und/oder Sound encoden/re-encoden. Der sagt das gleiche: Die "schicken" GUI-basierten Dinger benutzen intern irgendwelches generalisiertes Zeug, kommen nicht mit irgendwelchen komischen Formaten klar und sind zudem langsam. Und die Kommandozeilen-Tools, die mit kryptischen Parametern daherkommen (allerdings wäre es ein Kinderspiel, dafür ein kleines Frontend zu bauen), benutzen alles, was das System eventuell bietet (und funktionieren auch noch, wenn das System weniger bietet!), verstehen jedes Format und sind außerdem schnell.

Mir ist natürlich klar, daß man nicht für "jedes und alles" in die tiefste Systemebene kriechen muß und oft kann ein schnell mal hingeschlunztes Skript mal schnell ein kleines Problem lösen - und zwar schneller, als wenn man sich in die Untiefen der Bits der Maschinencodeebene stürzt und Stunden mit Debugging verbringt, in denen man das eigentliche Problem schon lange manuell gelöst hätte.
Aber bei Emulatoren - also Programmen, die komplett andere - teilweise zu 100% zum Hostsystem inkompatible - Systeme - emulieren sollen, und außer der fremden CPU auch noch Sound-/Grafik-Chips mit all ihren seltsamen Modi oder altmodischem Speicherbanking und wasnichtalles... Da sollte man so viel Mühe wie nur irgend möglich in die Performance reinstecken. Denn das ist ja NICHT nur ein "kleines Problem, das mal nebenher gelöst werden soll", das ist ja ein Programm, das wirklich längerfristig und dauerhaft genutzt werden soll und das nur wirklich nützlich ist, wenn es seinen Zweck auch zur Zufriedenheit erfüllt.

Ab und zu spiele ich so von Leuten (ausm Internet, kenn die nicht persönlich) "selbstgemachte" Spiele, die teilweise mit "Game-Makern", teilweise auch "händisch" gemacht wurden - und auch, wenn einige davon schon Spaß machen, bin ich gelegentlich regelrecht erschüttert/entsetzt darüber, welche Systemparameter manche Leute heutzutage voraussetzen für Dinge wie ein 2D-Arcade-Spiel, damit es ruckelfrei läuft - bzw. überhaupt spielbar ist bzw. überhaupt startet.

Ach ja, zum Thema C noch mal:
Ich weiß nicht, was die Leute alle so daran mögen - die Sprache wirkt auf mich unaufgeräumt und zusammengeschustert. Was da als Syntax bezeichnet wird, wirkt wie ein zusammengeworfener Haufen von mindestens 5 verschiedenen Syntaxkonzepten. Bei Variablentypen ist nicht einmal festgelegt, welche Bitbreite sie haben und das Stringhandling ist das Letzte... (Nicht daß Strings jetzt wirklich wichtig wären. Aber sie sind eben beliebt...) - Aber das muß natürlich jeder selbst wissen -über Hochsprachen braucht man sich nicht zu streiten, es gibt sicher Gründe, wieso es so viele davon gibt. Da hat jeder andere Präferenzen.

Und ja, das war wahrscheinlich wieder etwas mehr Text als nötig.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Do 31. Jan 2019, 15:16
von BluesmanBGM
Um noch mal kurz auf das Emulatorenthema zurück zu kommen...

Danke an DOSferatu für die umfangreichen Ausführungen, ich habe es mit Interesse gelesen, und irgendwie haben mir seine Aussagen auch wieder Hoffnung gegeben, daß es eben im Prinzip doch möglich wäre, mit weniger auszukommen. Jetzt bräuchten wir nur noch ein fähiges Programmierteam, daß einen ultimativen Multimachine-Emulator schreibt, der mindestens alle klassischen 8-Bit-Rechner und Konsolen abdeckt, und trotzdem auf einem 486er akzeptabel läuft. Leider beschränkt sich mein eigenes Programmiertalent auf Basic 2.0 auf dem C64.

Eine andere Frage, die mir zum Thema noch einfiel bzw. die vielleicht auch mit dem Themenkomplex Interna von Emulatoren und Hardware-Anforderungen zu tun hat:

Wie kann es eigentlich sein, daß ein Emulator mit stark unterschiedlicher Geschwindigkeit läuft, je nachdem, welches Programm/ROM man im Emulator ausführt? Sollte es nicht eher so sein, daß ein Großteil der Rechenzeit im Emulator eben für die Nachbildung der Hardware an sich verbraucht wird, und nicht für das individuelle Spiel/Programm?

Beispiel: wenn ich einen C64-Emulator wie VICE benutze, dann sollte der doch immer ziemlich gleich schnell/langsam sein - egal, ob ich im Emulator nun in Basic tippe oder ob ich z.B. PacMan oder Turrican oder Maniac Mansion etc. ausführe. Keines von den Spielen sollte langsamer laufen, nur weil es aufwändiger programmiert ist. Auf einem Mittelklasse-486er würden also so unterschiedliche Spiele wie PacMan und Turrican unter VICE gleich stark ruckeln, weil die Leistung nicht (oder kaum) für das individuelle Spiel verbraucht wird, sondern für die generelle Emulation der Präsenz von 6510, VIC, SID etc.

Sehe ich das richtig?

Mich wundert in dem Zusammenhang nämlich das Verhalten vom no$gba. Wenn ich den auf dem Pentium 166 ausführe, dann erreiche ich natürlich keine GBA-Originalgeschwindigkeit. Ist nachvollziehbar, im originalen Gerät ist doch einiges an 32-Bit-RISC-Hardware drin. Man muß den Programmier im Grunde schon dafür loben, daß zumindest manche Spiele auch auf einem P166 ausführbar laufen.

Und trotzdem ist es so, daß verschiedene Spiele bei gleicher Einstellung (800x600, 3xScale) mit sehr unterschiedlichen Geschwindigkeiten im Emulator laufen.

Zelda - The Minish Cap läuft z.B. nur mit etwa 72% Geschwindigkeit und ruckelt merklich.

Bild

Das Spiel "Summon Night" dagegen läuft fast immer flüssig mit 94% oder mehr. In gerenderten Szenen geht es sogar fast auf 100% Geschwindigkeit.

Bild

Bild

Woher kommen diese höchst unterschiedlichen Werte in der Performance des Emulators?

Chris

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: Sa 2. Feb 2019, 19:20
von b20a9
Die GBA Spiele sind unterschiedlich groß, zwischen 4 und 64mb. Ob es vielleicht daran liegt?
Ich denke, du könntest die Performance durch Reduzierung der Auflösung deutlich verbessern, 800x600 upscaling erscheint mir unnötig hoch (Quellmaterial 240x irgendwas)
Ich emuliere GBA auf dem Gameboy DS, da sollte ein Pentium 166 eigentlich genug Leistung für die Emulation haben.

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: So 3. Feb 2019, 11:07
von Dosenware
Es handelt es sich um Emulatoren - je nachdem was das Programm besonders stark nutzt ist der Emulator eben schneller, bzw. langsamer.

So lassen sich bestimmte Operationen sehr einfach Emulieren, da man sie praktisch 1:1 auch auf dem Hostsystem ausführen kann (zum Bleistift beherrscht jeder Computer Addition und Subtraktion), andere Operationen benötigen deutlich mehr Aufwand da sie eben nicht auf dem Hostsystem zur verfügung stehen. (z.b. der Blitter im Amiga -> Daten im Speicher verschieben und gleichzeitig die Daten ändern, ohne dass der Prozessor dabei mithilft; oder wie vor dem Pentium üblich: die Gleitkommaemulation)

Re: Zu hohe Hardwaranforderungen für Emulation?

Verfasst: So 3. Feb 2019, 15:08
von drzeissler
Kurzum, mit einem p3-600 gehen schon so manche emulatoren ganz gut,
Aber immer noch nicht so gut, wie auf der originalen Maschine.

Mit einem p1 kannst du das vergessen, ein cel300 ist unterste grenze