Zu hohe Hardwaranforderungen für Emulation?

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

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Di 5. Feb 2019, 14:50

drzeissler hat geschrieben:Mit einem p1 kannst du das vergessen, ein cel300 ist unterste grenze


Nuja, ganz so schlimm ist es ja zum Glück nicht. Es gibt doch sehr viele Emulatoren, die 8- und 16-Bit-Geräte gut und flüssig auch auf P1-Rechnern emulieren. Mir persönlich kommt sowieso nichts schnelleres als ein P166 ins Haus, auch nicht für Emulation.

Was mich beim GBA halt wundert, sind diese großen Unterschiede bei der Spiele-Performance. Das sind teilweise 25 - 30% Unterschied, so ausgeprägt habe ich das noch bei keinem Emulator gesehen. Und da stellt sich doch fast die Frage: wenn bestimmte Spiele auch auf P166 mit fast 100% laufen, warum tun das dann nicht alle Spiele? Und warum laufen Spiele mit gerendertem 3D-Kram (siehe letztes Bild oben) flüssig mit 99% und visuell einfachere Spiele deutlich langsamer?

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

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Di 12. Mär 2019, 19:34

DOSferatu hat geschrieben: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.


Du unterschätzt die modernen Compiler ein bisschen... :-)

Zu deinen Punkten:
1) Macht jeder moderne Compiler.
2) Das beherrschen selbst 15 Jahre alte Compiler.
3) Standardmäßig machen das Compiler nicht, vielen bieten das aber als Optimierungsstufe an. Wenn das ein Compiler per default machen würde, wäre der resultierende Code kaum noch zu debuggen.
4) In dem Punkt hast du wahrscheinlich recht. Das machen Compiler meines Wissen nach nicht. So eine Optimierung wäre gar nicht so schwer umzusetzen, allerdings wäre der zu erwartende Performancegewinn für allermeisten Programme gleich 0. Es lohnt sich einfach nicht.
5) Das kann kein Compiler und wird auch nie einer können. Solche Optimierungen lassen sich allerdings in jeder Hochsprache realisieren und sind daher Sache das Programmierers.
6) Der erste Teil: ja, das machen Compiler. Der 2.Teil - nein, das machen sie nicht. Da greift das Argument aus Punkt 3, dass der resultierende Code nicht mehr zu debuggen wäre. Wenn eine Kaskade von Subroutinen so oft aufgerufen wird, dass sich so etwas lohnen würde, dann greifen aber wahrscheinlich anderen Optimierungen, z.B. das Inlining von Funktionen.
7) Da weiß ich ehrlich gesagt gar nicht, was du meinst. :-)
8) Selbstmodifizierender Code ist seit dem 386er eigentlich tot - Stichwort Prefetch Queue. Während ein Befehl ausgeführt wird, werden zeitgleich die nächsten schon geladen. Eine Modifikation hat also keinen Effekt mehr. Ich habe mal selbstmodifizierenden Code für den Pentium gesehen, der vorher aufwändig getestet hat, wie groß die Prefetch-Queue ist und den selbstmodifizierenden Code dann vorher entsprechend modifiziert hat. Ja, wer Spaß auf sowas hat... nur zu! :-)

Wenn ältere Platformen heute noch relevanz hätten, dann wären auch die Compiler soviel besser als früher, dass du es dir 2x überlegen würdest, ob du wirklich alles in Assembler machen möchtest. Beim 386er kann ich es noch nachvollziehen, weil da die entsprechenden Compiler noch eher schwach waren. Der GCC unterstützt den 386er (und den Real Mode insbesondere) schon lange nicht mehr.

DOSferatu hat geschrieben: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.)


Ich kann deine Leidenschaft, aus einem alten System das Optimum herauszuholen, sehr gut nachvollziehen. Es macht halt Spaß immer noch ein paar Taktzyklen einzusparen und irgendwelche Routinen Schritt für Schritt noch ein bisschen besser zu machen. Nur darf man diegleiche Akribie nicht von anderen erwarten. Für viele hat das Ziel, einfach fertig zu werden, einen höheren Stellenwert. Ich habe auch noch ein Projekt für den 486er in Arbeit und versuche natürlich auch das beste aus dem System herauszuholen. Ich mache das aber alles in C/C++ und schaue mir später an, wo die meiste Rechenzeit verbraten wird. Entsprechende Teile werden dann durch Assembler ersetzt. So haben es ja auch die späteren DOS-Spiele gemacht, die alles aus den Rechner rausgeholt haben. Die haben kaum noch Assembler verwendet, weil die Compiler immer besser wurden. Bei Wolfenstein 3D gab's noch eine Menge davon, bei Doom schon deutlich weniger, und Quake or DukeNukem3D waren dann schon 99% C-Code. Es hat sich einfach nicht mehr gelohnt.

DOSferatu hat geschrieben: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.


Das liegt aber daran, dass er für das entsprechende System kompiliert wurde und der Programmierer von den Compilereinstellungen keine Ahnung hatte. :-) Wenn das Programm Open Source ist, ist das ja aber kein Problem VICE z.B. kannst du ohne weiteres für DOS kompilieren und der funktioniert dort wunderbar. Dass er auf einem 486er deutlich langsamer ist als ältere Emulatoren, die ich von früher kenne (z.B. C64S), liegt nur daran, dass VICE einfach viel genauer in der Emulation ist. Den Sourcecode habe ich mir auch schon oft angeschaut - das ist guter C-Code. Man könnte sich die Mühe machen und mal mit einem Profiler schauen, wo die Rechenzeit verbraten wird und entsprechende Routinen in Assembler umschreiben. Da holst du vielleicht 5% raus. Alles Weitere lohnt nicht mehr.

DOSferatu hat geschrieben:
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...


Ich wäre auch nicht stolz drauf, aber hey - wo soll der arme Programmierer eine Maschine mit weniger als 1 Ghz und ohne eingebaute 3D-Fähigkeiten herbekommen? :-) Jeder hat irgendwie so ein Ding auf dem Tisch stehen. Daher läuft der Müll auch überall. Ich bin da generell auch sehr kritisch. Und wenn jemand sagt, dass er in Javascript programmiert, dann bin ich der erste, der ihm erklärt, dass das mit programmieren wenig zu tun hat, was er da macht... :-) Aber die Welt dreht sich weiter und wenn du möchtest, dass die Menschen deine Spiele spielen, dann wirst du sie auch mit einer DosBox bündeln müssen. Und kaum ein Spieler weiß, was da im Hintergrund eigentlich passiert. Aber du kannst dich stolz schätzen, dass man dein Spiel auch noch in 50 Jahren spielen kann - während der Hobbyprogrammierer mit seinem Game-Maker sein Spiel vermutlich schon in 10 Jahren nirgends mehr starten kann. Ich habe schon als Kind Mitte der 80er Spiele für den C16 geschrieben - die laufen heute noch. Ein kommerzielles Spiel, dass ich Anfang der 2000er für Win98/2000/XP geschrieben habe, startet unter Windows 7 nur noch mit einem Patch und unter Windows 10 gar nicht mehr, obwohl es blitzsauber programmiert wurde. Das hat schon eine gewisse Ironie. Microsoft hat in dem Fall ein paar Direct3D-Funktionen aus Windows einfach rausgeschmissen. Dumm gelaufen...


DOSferatu hat geschrieben: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.


Deine Kritik an C ist absolut berechtigt, nur bedenke: die Syntax von C ist aus den frühen 70ern! Niemand konnte damals ahnen, wohin die IT-Welt einmal geht und wie komplex Software einmal werden wird. Unter der Voraussetzung ist es schon fast erstaunlich, dass man heute noch einigermaßen vernünftig in C entwickeln kann. Und auch C hat sich weiterentwickelt. Heute gibt es Datentypen wie uint8_t oder int16_t, die die Anzahl der Bits garantieren. Und C wird heute oft mit C++ kombiniert, dessen String-Handling eindeutig besser ist. C hat den großen Vorteil, dass es Compiler für nahezu jede Platform gibt - und wenn du etwas in C schreibst, kannst du dir sicher sein, dass du es auch noch in 10 Jahren auf einem neuen System kompilieren kannst. Bei den meisten anderen Hochsprachen ist fraglich, ob die die nächsten 10 Jahre überleben. Wobei nicht einmal klar ist, ob man C zu den Hochsprachen zählen sollte. Für viele ist es nur ein besserer Makro-Assembler. Es gibt z.B. auch heute so nette Makros wie __builtin_expect, mit denen du bei If-Abfragen sagen kannst, welcher Fall der wahrscheinlichere ist und der Compiler optimiert dann entsprechend.
GMBigB
Norton Commander
Beiträge: 133
Registriert: Fr 5. Mär 2010, 13:30

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Di 12. Mär 2019, 19:52

BluesmanBGM hat geschrieben: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?


Die Grafikkarte ist über einen Bus angebunden und das Übertragen der Daten auf die Grafikkarte dauert verhältnismäßig lange. Ich habe gerade keine Zahlen im Kopf, aber ich schätze mal, dass ein 486er mit VLB-Grafikkarte vielleicht 10MB/sec zur Grafikkarte schaufeln kann. Ein C64 hat eine Auflösung von 384*272. Das sind ca. 100KB pro Bild. Willst du also einen C64 mit seinen 50fps emulieren, geht schonmal 50% der Rechnenzeit nur für den Transport der Daten zur Grafikkarte drauf. Viele Emulatoren haben daher früher die Möglichkeit geboten, dass man Bilder einfach überspringt, d.h. sie werden nicht zur Grafikkarte übertragen. Nun kann man einen Emulator dahingehend optmieren, dass man nur die Änderungen am Bild an die Grafikkarte überträgt, weil man genau weiß, welche Register für welche Änderungen verantwortlich sind. Daher kann ein Emulator sehr viel schneller sein, wenn du nur Basic tippst, weil die Änderungen nahe 0 sind. Im Gegensatz dazu muss ein Bild, das gescrollt wird, jedes Mal komplett neu zur Grafikkarten geschickt werden.

Zum Thema Ruckeln: das hat etwas mit der Bildwiederholfrequenz und den fps zu tun. Wenn du einen CRT auf 75Hz stellst und beim C64-Emulator genau jedes zweite Bild, also 25fps überträgen würdest (und natürlich den Vertical Retrace beachtest), empfindest du das Scrolling als butterweich, während 50fps bei einer Bildwiederholfrequenz von 60 Hz ruckeln würden. Aber das ist ein Thema für sich...
drzeissler
DOS-Gott
Beiträge: 3236
Registriert: Mo 8. Feb 2010, 16:59

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon drzeissler » Di 12. Mär 2019, 19:59

Kann man das ggf. mit NTSC Games in der Emulation überlisten.
60hz/60fps.
CPU: 486 DX2/66 MOBO: SNI-D882 RAM: 3x16MB - FDD: 3,5" 1,44MB HDD: 6,4GB Seagate ISA(1): Audican32Plus PCI(1): 3com TX 905 OS: MsDos622 - Win95a - WinNT 3.51
GMBigB
Norton Commander
Beiträge: 133
Registriert: Fr 5. Mär 2010, 13:30

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Di 12. Mär 2019, 23:45

drzeissler hat geschrieben:Kann man das ggf. mit NTSC Games in der Emulation überlisten.
60hz/60fps.


Nunja... die meisten NTSC-Portierungen laufen einfach 20% schneller. Insofern könnte man auch einfach die Emulation eines PAL-Systems auf 60fps beschleunigen. Einziger Unterschied zu den NTSC-Versionen der Spiele wäre dann der Sound - der ist meist das einzige, was man bei Portierungen angefasst hat, damit er nicht 20% schneller/langsamer läuft.

Man kann den Geschwindigkeitsunterschied sehr gut bei Youtube-Videos von z.B. Turrican erkennen. Der Nachteil von NTSC ist übrigens auch, dass es einige Spiele gar nicht gibt (z.B. Turrican 2) und das Seitenverhältnis der Pixel ein anderes ist, so dass das Bild etwas verzerrt aussieht.
BluesmanBGM
MemMaker-Benutzer
Beiträge: 97
Registriert: Fr 10. Aug 2018, 10:46

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon BluesmanBGM » Do 25. Apr 2019, 09:56

Ein Nachtrag noch zum Emulatoren-Thema:

dieser Tage kam ja die C64-Version von Super Mario Bros raus (hey, jetzt kann ich endlich auch auf P166 quasi Mario 64 spielen ;-)). Nintendo ist aber wie üblich schon fleissig dabei, gegen die Verbreitung des Spieles vorzugehen.

Bei der Lektüre des Threads im Forum64 hatte ich aber den Eindruck, daß die C64-Version irgendwelche besonderen Programmiertricks verwendet, und daher vermutlich aktuellste (aka akkurateste) Emulatoren voraussetzt. Rein aus Interesse habe ich die d64 aber auch mit meinem "archaischen" DOS-VICE Version 1.9 von Mitte 2002 versucht. Ich hatte eigentlich erwartet, daß das Spiel entweder abschmiert, oder Grafik-/Sprite-/Scrollingfehler etc. zeigt.

Aber hey, es funktioniert auch mit 17 Jahre altem DOS-VICE mit Bild und Ton. Okay, bei zuvielen Gegnern gleichzeitig auf dem Screen stockt das Bild ein wenig, aber das liegt wohl am Programm bzw. C64 selbst. Und mir persönlich ist die Mario-Steuerung zu schwammig, der läuft immer wie auf Glatteis. Aber das ist wohl dem Original geschuldet, und hat nichts mit der Emulation zu tun. Die ist (soweit ich sehen kann) völlig stabil und in Ordnung.

Was mich zu meinem eigentlichen Argument bringt: ich denke, daß ein Großteil der Emulatoren für 8- und 16-Bit-Geräte im Prinzip schon vor vielen Jahren einen Stand erreicht hatte, der ausreichend nahe an die originalen Geräte herankam. Waren die C64-Emulatoren Mitte der 90er noch recht holprig, war "bereits" 2002 ein Stand erreicht, auf dem aktuelle Spiele, Demos, Musik, FLI-Bilder, Diskmags etc. allesamt problemlos laufen. Auch die aktuelle Digital Talk z.B.

Und da stellt sich mir wieder die Frage, wozu man dann überhaupt die ständigen neuen Updates und Versionen von Emulatoren braucht. Das ist dann halt noch mehr Komfort und Detaileinstellungen, aber alles mit ständig steigenden Hardware-Anforderungen, und vor allem meistens auch nicht mehr für DOS. Und gerade beim Homecomputerbereich will ich persönlich gar keine Massen von Bequemlichkeitsfeatures, das widerspricht der "Philosophie" der Geräte. Das Argument "Wer ordentlich emulieren will, braucht ein aktuelles OS und die neuesten Emulatoren-Updates" kann ich also nicht nachvollziehen, es geht in der Regel auch mit "Uralt-Software".

Und jetzt sollte doch bitte noch jemand den perfekten C64-Emulator coden, der auch flüssig auf einem 386er läuft. Und dann bitte noch einen Playstation-Emulator für den 386SX hinterher. Dann wäre ich zufrieden ;-).

Chris
drzeissler
DOS-Gott
Beiträge: 3236
Registriert: Mo 8. Feb 2010, 16:59

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon drzeissler » Do 25. Apr 2019, 12:54

Den CSS64 gab es auch für Dos und Windows. Der konnte 50hz in 800x600 am 15" TFT
und hat auch keine Probleme mit PCI-Soundkarten, da er unter Windows gestartet wohl
die SB16 Emulation von Win98se nutzt. Sprich ein ScoveryXS mit D1215 macht da richtig
Spass.
CPU: 486 DX2/66 MOBO: SNI-D882 RAM: 3x16MB - FDD: 3,5" 1,44MB HDD: 6,4GB Seagate ISA(1): Audican32Plus PCI(1): 3com TX 905 OS: MsDos622 - Win95a - WinNT 3.51
Jareika
Windows 3.11-Benutzer
Beiträge: 5
Registriert: Sa 13. Apr 2019, 13:22

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon Jareika » Do 25. Apr 2019, 15:37

Ich persönlich fände es ja mal eine ordentlich Programmierarbeit wenn man von den ganzen Emulationsgedöns wegkommt.

Wenn man ein Spiel Emulieren kann müsste es doch Theoretisch möglich sein, das ganze Spiel durch einen Filter laufen zu lassen und es in die jeweilige Betriebssystemsprache zu Übersetzen.

Ich sehe da keinen Grund warum das nicht möglich sein sollte.
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3667
Registriert: Mi 24. Mai 2006, 20:29

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon Dosenware » Fr 26. Apr 2019, 07:24

Wenn man ein Spiel Emulieren kann müsste es doch Theoretisch möglich sein, das ganze Spiel durch einen Filter laufen zu lassen und es in die jeweilige Betriebssystemsprache zu Übersetzen.
Psst, das nennt sich Emulation - aber nicht verraten ;-)

Wenn du von der Emulation wegkommen willst, brauchst du eine VM oder eine Portierung - beides ist längst nicht so universell einsetzbar wie eine Emulation.
Eine Portierung ist aufwendig und muss für jedes Programm einzeln vorgenommen werden und eine VM (über die heute üblichen Hardwarefunktionen) ist immernoch an die zugrundeliegende Hardware gebunden - mit den entsprechenden Einschränkungen, will man diese überwinden muss dies Emuliert werden.

Wobei hier Bochs eine Art Sonderstellung einnimmt - der Emuliert die Hardware und ist somit irgendwo zwischen einer Emulation und einer VM - kann dafür aber auch auf ARM, PowerPC usw. einen x86-kompatiblen Rechner emulieren.
GMBigB
Norton Commander
Beiträge: 133
Registriert: Fr 5. Mär 2010, 13:30

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon GMBigB » Sa 27. Apr 2019, 02:29

Dosenware hat geschrieben:
Wenn man ein Spiel Emulieren kann müsste es doch Theoretisch möglich sein, das ganze Spiel durch einen Filter laufen zu lassen und es in die jeweilige Betriebssystemsprache zu Übersetzen.
Psst, das nennt sich Emulation - aber nicht verraten ;-)

Wenn du von der Emulation wegkommen willst, brauchst du eine VM oder eine Portierung - beides ist längst nicht so universell einsetzbar wie eine Emulation.


Was Jareike meint ist eine automatische Portierung. Die Idee ist grundsätzlich gut und eingeschränkt funktioniert das sogar. Code für einen 68000er oder eine 6502-CPU kann man leicht für das Zielsystem kompilieren. Wenn es denn aber um die Spezialchips geht, wird es schwierig, weil sehr viel Code von exakten Timings abhängt. Einfachstes Beispiel: ein Sprite auf dem C64. Wen ich den einfach verschiebe, weiß ich nicht, ob die Änderung zum aktuellen Frame gehört oder erst im nächsten Frame sichtbar wird. Dazu müsste man wissen, welchen Teil des Bildes der Grafikprozessor gerade aufbaut. Und das geht nur durch eine zyklengenaue Emulation.
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3667
Registriert: Mi 24. Mai 2006, 20:29

Re: Zu hohe Hardwaranforderungen für Emulation?

Beitragvon Dosenware » Sa 27. Apr 2019, 03:16

Code für einen 68000er oder eine 6502-CPU kann man leicht für das Zielsystem kompilieren.

Meist hast du aber nur den Binärcode, und da würde die automatische Portierung im wesentlichen einer Voremulation entsprechen - sprich: Der Code den der Emulator beim Ausführen eines Programmes erzeugt, würde am Ende als eigenständiges Programm gespeichert, quasi wie compiliertes Java.

Damit fällt auch nur der Interpretationsaufwand weg, das Ergebnis ist immernoch recht aufgeblasen und bei komplexen Programmen ist die Fehleranfälligkeit deutlich höher als bei einer Emulation, da hier das Programm sehr genau analysiert werden muss - während die Emulation einfach mit den Daten, die zur Laufzeit entstehen, arbeiten kann.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste