Das mit den Modulen ist schon clever, aber die Auswahl reizt mich nicht sonderlich. Ich denke mal, meine nächste „Konsole“ wird ein MiSTer FPGA sein.
Bringt das nun einen Vorteil oder nicht? Was ich bislang gelesen habe, hat es eher keine Vorteile gegenüber der Software Emulation.
Ich habe beim drüberlesen ca. Gröbere Rechtschreibfehler gesehen. Bitte korrigieren 
sagt derjenige der immer knapp an der 5 in Deutsch vorbeigeschrammt ist…
1 „Gefällt mir“
Ich stecke nicht so wirklich tief im Thema, aber was ich von @rsn8887 und @Pagefault2000 über den Mister mitbekommen habe, klingt sehr vielversprechend. Vielleicht mag ja einer der beiden kurz die Vorzüge erläutern. 
1 „Gefällt mir“
Ich liebe meinen MiSTer. Der Unterschied zu herkömmlichen Emulatoren ist gerade bei schnellen Actionspielen wie IO und Uridium auf dem C64 wie Tag und Nacht finde ich, weil man keinen Lag und butterweiches Scrolling ohne Mikroruckler hat und somit so schnell reagieren kann wie auf einem originalen Gerät.
Einige MiSTer FPGA Vorteile:
-
Verhält sich wie originale Hardware unterstützt aber USB Controller und hat HDMI Ausgang für Bild und Ton
-
Anschalten und loslegen, die Bootzeit beträgt nur ca. 2 Sekunden
-
Praktisch null Inputlag, also keinerlei zusätzliche Verzögerung, bis Mario z.B. endlich springt, verglichen mit originaler Hardware, dank 1000 Hz forcierter USB Pollingrate und lagless Beamracing ohne Framebuffer wenn man den vsync_adjust=2 low-lag Modus benutzt
-
Mit modernem Freesync/Gsync Monitor absolut butterweiches Scrolling ohne Mikroruckler, selbst bei Amiga und C64 PAL Spielen. Auch die flackernden Schatten in manchen Spielhallen Kampfspielen oder Shmups flackern perfekt synchron ohne Aussetzer, genau wie bei der originalen Hardware.
-
Es gibt keinen Audiolag, also wenn man ballert kommt der Schusston direkt beim Schiessen und nicht wie bei manchen anderen Systemen erst eine halbe Sekunde später.
-
Spiele laufen in der originalen Hz Frequenz zum Beispiel Bolo auf dem Atari ST in monochrom mit 72 Hz wie damals beim echten ST S/W Monitor
-
Super simples Menüsystem, so dass man sich auf’s Zocken konzentrieren kann, siehe mein Video hier zum Inputmapping als Beispiel: MiSTer (FPGA) Input Mapping - YouTube
-
Einige Systeme haben richtig coole moderne Features, zum Beispiel kann man im GBA Core zwei GBA im Splitscreen parallel laufen lassen und dann Multiplayer Spiele im Splitscreen spielen. Beim GB Core geht das auch. Das ist einer der Vorteile der inhärenten Parallelität des FPGA. Core Entwickler können mehrere Geräte gleichzeitig instanzieren auf dem Chip und die laufen dann in parallel.
-
MiSTer ist Open Source und hat eine aktive Community. Der Code für die Cores, die Baupläne für die optionalen I/O Platinen, und eine schöne Dokumentation liegen öffentlich auf GitHub. Jeder kann Issues eröffnen um Bugs zu beschreiben, und jede Woche werden Bugs gefixt und Verbesserungen vorgenommen. Einen tollen offiziellen Discord Server und offizielles Forum gibt es auch, wo rege diskutiert wird.
Einige Nachteile:
-
Es gehen keine neueren Systeme wie N64 oder Dreamcast. PS1 und Saturn sind in der Mache und wahrscheinlich das höchste der Gefühle, weil sie den FPGA schon fast zu 100% ausnutzen
-
Spiele werden als einfache Filenamen ausgewählt, es gibt keine Videovorschau, Boxart, Thumbnails oder Ähnliches im Menü, es ist absichtlich schlicht
-
Teuer und oft ausverkauft. Man muss sich entweder das De10-Nano Board und Speicher kaufen und dann ein 3D Druckgehäuse basteln oder ein teures Komplettpaket kaufen
-
Bei vielen Cores gibt es keine Savestates. Es ist eher wie die originalen Geräte, also speichert man nur wenn das Spiel einem die Möglichkeit dazu gibt.
-
Man muss für Bluetooth und Wifi USB Dongle anschließen, weil das De10-Nano Board diese Chips nicht integriert hat. Zum Glück sind die Dinger aber inzwischen für $10 oder so zu bekommen.
Ich kann auch diesen englischen Artikel zur Frage „Why FPGA“ sehr empfehlen: Why FPGA · MiSTer-devel/Main_MiSTer Wiki · GitHub
4 „Gefällt mir“
Das klingt aber eher an Probleme der Software Emulation, als etwas, dass sich ausschließlich mit einem FPGA lösen lässt. Was ich gelesen habe, hängt das vom System und jeweiligen Spiel ab, weil der FPGA kann ja auch nicht zu 100% die original Hardware abbilden (technisch nicht möglich mit FPGAs).
Die Polling Rate ist aber genauso schnell wie die von Controllern an Windows, wenn ich mich nicht täusche. Find es aber Interessant, also das mit den Flackern usw. ist natürlich etwas. Was ja viele Emulatoren machen, ist auch dinge absichtlich per Default zu ändern, weil sie meinen es sieht schöner aus (Kantenglättung urgh).
Das schnelle Starten ist natürlich super 
Wie viel Strom zieht das ding eigentlich? Wäre interessant ob man das per direkt USB am Beamer betreiben kann…
1 „Gefällt mir“
Ich glaube der MiSTer zieht 2A, ich meine es wird ein 5V 2A Netzteil beigeliefert, und das funktioniert. Aber es wird ein powered USB Hub empfohlen, und sowas benutze ich auch, weil die USB Peripherie wie Wifi Dongle und manche Controller zum Teil auch einiges ziehen können.
Klar im Prinzip braucht man für die Funktionalität nicht zwingend einen FPGA. Aber garantiertes Timing, also realtime ist schon eine schöne Eigenschaft des FPGA verglichen mit Betriebssystemen wie Windows, MacOS und Linux die eigentlich immer dazwischenfunken können. Am ehesten zu vergleichen wäre ein Realtime OS wie diese Circle Bibliothek auf Raspberry Pi, manchmal auch als Baremetal bezeichnet. Die Emulatoren BMC64 und ZXBare kommen da am ehesten ran. Unter Windows ist mir nur WinUAE bekannt, der lagless beamracing mit GSync unterstützt und damit auch butterweiches Scrolling ohne Lag hinbekommt. Alle anderen klassischen Emulatoren machen da irgendwelche Kompromisse, die zu Verzögerungen beim
Input und Sound, und zu Mikrorucklern führen.
Man kann es auch schön sehen wenn man zum Beispiel SF2 auf MiSTer, Automat und Mame nebeneinander laufen lässt. Dann laufen MiSTer und Automat schön synchron über 20 Minuten lang, aber Mame läuft schon nach ein paar Minuten asynchron auseinander.
Ich kann es nur von mir selber sagen, aber der MiSTer hat mir wieder neuen Spaß am Retrogaming beschert. Endlich kann ich mich einfach auf das Zocken konzentrieren statt auf das Konfigurieren irgendwelcher Menüs und anderes Gekrampfe! Das lässt sich so schön bedienen und wie soll man sagen es funktioniert einfach. Und endlich habe ich bei Turrican Amiga und Uridium und IO C64 in 50 Hz wieder butterweiches Scrolling ohne den geringsten Stotterer sehen können, mir kamen fast die Tränen.
PS: Ich habe auch neulich was längeres im CiBO Forum dazu geschrieben, falls es jemand interessiert. Da ging es aber hauptsächlich um den neuen PlayStation 1 MiSTer Core:
https://circuit-board.de/forum/index.php/Thread/27086-MiSTer-FPGA-News-Support/?postID=956525#post956525
4 „Gefällt mir“
Also digitale Chips lassen sich sehr wohl 1:1 abbilden. FPGAs wird auch in der Chip-Entwicklung genutzt, um Konzepte zu testen. Außerdem kann man mit FPGAs sehr einfach Custom Chips herstellen. Man findet z.B. FPGAs oft auch in Videomischern (z.B. die Atem-Geräte) oder in Signalprozessoren. Dort lassen sich dann - je nach Anwendung - mehrere Custom-Chips in einem FPGA realisieren. Problematisch wird es bei einem FPGA, wenn man die alten Schnittstellen nachbilden möchte. Z.B. kannte ein Amiga oder eine PS1 keinen digitalen HDMI-Ausgang. Man kann aber an dem Mister auch analoge Monitore anschließen. Ich habe z.B. für meinen einen Scart-, Komponenten- und VGA-Anschluss. Bei den Joysticks gibt es auch die Möglichkeit das ganze über einen DB9 Port anzuschließen, der direkt auf der I/O Platine steckt (Ich habe einen modifizierten Mister von Antonio Villena). Dadurch spart man sich die USB-Wandung der Joysticks. Hierzu braucht man aber angepasste Cores. Ob das Sinn ergibt, wage ich zu bezweifeln, da man mit einem aktuellen USB/Competion Pro 120 (bin ich jetzt nicht ganz sicher) mal in der Sekunde pollen kann. Der Mister unterstützt auch noch eine Fastpolling Option, dann geht es noch schneller. Aber das Gerät muss es unterstützen.
Ansonsten sind viele I/O Schnittstellen mit dem Host-System über Wrapper verbunden. Im Host-Linux werden dann diese Schnittstellen emuliert. Allerdings dann mit einer garantierten Latenz.
Beim Amiga sind z.B. soweit ich weiß, alle Custom Chips auch im FPGA implementiert. Das sorgt dafür, dass die Kommunikation der Custom-Chips mit der CPU 1:1 ausgeführt wird, ohne dass der Sound z.B. mal der Bildschirmausgabe davonrennt. Bei einem Emulator wird das so nicht möglich sein, da Timing (gerade bei Multicore-Systemen) sehr schwierig ist. Man kann den exakten Takt bzw. einen Prozessor mit einer anderen Prozessorarchitektur nie nachbauen. Das ist z.B. auch der Grund, warum man im Mister noch langsames EDO-Ram einbaut, da die modernen DDR-Rams von den Taktszyklen und der Architektur zu verschieden sind.
4 „Gefällt mir“
Nein kannst du nicht, du kannst die Logik abbilden, aber nicht die Laufzeiten, Schaltgeschwindigkeiten, Timings etc. Da sind einfach Grenzen gesetzt und ergeben sich durch den physikalischen Aufbau. Dafür verbrauchen FPGAs auch erheblich mehr Strom als z.B. ASICs (oder jede andere Form von integrierter logischer Schaltung). Das führt dazu, dass sich die Spaß im FPGA alles super verhält und dann im physischen Zustand andere Ergebnisse liefert, andere Takte etc.
Da sind Welten dazwischen und man verbringt da nicht umsonst jede Menge Zeit damit (gerade mit den Timings).
Das würde mit Microprozessoren genauso funktionieren. Die Vorteile vom FPGA sind, dass du z.B. die Architektur komplett umstellen kannst und dir z.B. dann mehr internen Speicher geben kannst (wenn noch Gatter verfügbar) und natürlich auch aus Nerdtum. In VHDL zu programmieren ist halt schon irgendwie geil und macht, zumindest mir, irre Spaß.
Man muss ja auch gar nicht Echtzeitfähig sein, weil die meisten Systeme damals schon nicht Echtzeitfähig waren und vor allem ruht sich die CPU heutzutage aus, das Problem das ihr beschreibt ist ein reines Software Problem und ließe sich auch entsprechend beheben. Natürlich kann es sein, dass das Betriebssystem sagt, dass man jetzt paar Zyklen warten muss, aber jetzt müsst ihr mal überlegen wie viele Zyklen das heutzutage wären um die Hardware von damals abzubilden, da kann man 100 Neogeos parallel laufen lassen und die CPU ist die meiste Zeit am warten.
1 „Gefällt mir“
Ok, da habe ich mich falsch ausgedrückt. Die Logik wird im FPGA abgebildet. Das Timing erfolgt wahrscheinlich wie auch bei einer gewöhnlichen CPU über einen externen Taktgeber. Ich bin da nicht vom Fach und verbreite hier bestimmt auch viel Halbwissen (aber mit Begeisterung! ;-)). 
Ich dachte eigentlich, die Probleme mit den Timings auf dem Mister rühren daher, dass es zu vielen CPUs keine Aufzeichnung gibt und man sich an die Strukturen herantasten muss. Im Prinzip versucht man eine CPU zu „emulieren“, was natürlich dem Konzept eines FPGAs widerspricht. Es gibt auf YouTube viele Laufzeitvergleiche (Original vs. Mister) und da ist der Mister erstaunlich nah am Original dran. Eine Emulation schafft das nicht. Allerdings ging auch immer davon aus, dass CPUs deren Aufbau bekannt ist (z.B. 68000er & 486er), auch das Timing kein Problem darstellt.
Ich hatte vor 25 Jahren im Studium mit QNX, einem Echtzeit-Betriebssystem gearbeitet. Ich denke, dass so etwas bei einem Mister auch Sinn ergeben würde. Ob das Linux Echtzeitfähig ist, weiß ich nicht.
2 „Gefällt mir“
Ich schiele auch schon eine ganze Weile in Richtung MISTer, da mich an diversen Emulatoren regelmäßig Zipperlein stören, weil zb nach Windows Updates irgendwelche Funktionen nicht mehr laufen wie sie sollen. Am häufigsten steigt die Controller-Erkennung aus. Der nächste verträgt sich nicht mit OBS. Anders gesagt: Mich nervt schlicht der Wildwuchs im wachsenden Maße.
Beim MISTer geht halt alles über den gleichen Video-Ausgang. Idr hat man ein vergleichbares Zeitverhalten bei der Eingabe, wie auf der Original-Hardware und die für mich interessantesten Cores sind offensichtlich in einem ausgereiften Zustand. Wenn dann auch noch ein funktionierender Saturn-Core dazukommt, bin ich ohnehin selig.
4 „Gefällt mir“
Das ist finde ich auch ein riesiger Vorteil beim MiSTer: man kann Ruck-Zuck zwischen den Cores wechseln und zwischen Systemen hin- und herspringen. Man muss nicht verschiedene Emulatoren starten und dann wieder die Input Mapping Options finden und jeder Emulator hat eine andere Oberfläche, die verwirrend und immer anders ist je nach Emulator.
Beim MiSTer ist alles einheitlich und einfach. Das ist ein riesiger Vorteil, den kann man nicht unterschätzen! Auch das Updaten mit dem „Update_All“ Skript läuft super einfach und uniform, verglichen mit einzelnen separaten Emulatoren. Und es gibt jede Woche Updates und Bugfixes, nicht wie bei Retropie nur alle 6 Monate mal eines, wo dann nach dem Update wieder die Hälfte kaputt ist und neu konfiguriert werden muss. Die ganze User Experience beim MiSTer ist finde ich richtig schön zweckmäßig.
Ein anderer Vorteil am MiSTer: ich muss meinen lauten, stromschluckenden, riesigen klobigen Desktop PC oder Laptop mit zig Lüftern nicht anwerfen, um zu zocken. Mein einer MiSTer, der ohne Gehäuse, braucht nicht mal einen Lüfter! Der andere im Gehäuse hat nur einen winzigen Lüfter
5 „Gefällt mir“
Mit Echtzeit habe ich mich auf den Core Verilog/Vhdl Code bezogen der auf dem FPGA läuft, nicht auf das Linux. Übrigens HDMI Output läuft auch vom FPGA direkt nach draußen, also in Echtzeit, ohne Linux. USB Controller Input und File I/O laufen aber über das Linux also nicht in Echtzeit. Deswegen muss auch mit 1000 Hz USB gepollt werden, weil das Polling asynchron zum FPGA Core läuft. Sonst würde ja 50/60 Hz wie bei den originalen Maschinen reichen.
1 „Gefällt mir“
Wobei es auch Ansätze gibt (SNAC?), einen DB9 Port direkt über den User-Port zu verwenden und man dann mit einem modifizierten Core das USB-Problem umgehen kann. Leider muss man dann jeden Core, der den DB9 Port verwenden will, anpassen. Und das lohnt sich nicht wirklich.
1 „Gefällt mir“
Wenn ich von Timings rede, beziehe ich mich darauf wie lange ein Signal physikalisch benötigt die Strecke zurück zu legen.
Also vielleicht lege ich mich jetzt in die Brennnessel, aber wenn ich mich nicht täusche bedingt ein FPGA nicht automatische eine (harte) Echtzeitfähigkeit, je nach Umsetzung.
Gibt es irgendwo unterlagen wie der Mister FPGA aufgebaut ist? ihr redet jetzt von Linux, läuft da ein SoC mit Linux und ein FPGA Board Huckepack?
Das kann ich sogar gut nachvollziehen. Die Emulatoren versuchen ja nicht die Hardware nachzubilden, sondern den Code umzusetzen und die Schnittstellen abzubilden. Ich denke mal, dass das möglichst originale Reproduzieren nicht unbedingt die höchste Priorität im Lastenheft hat.
Weiß eigentlich jemand, ob die mit den selben FPS-Limits arbeiten wie original Hardware oder rendern die Emulatoren so viele Bilder wie es die PC-Hardware hergibt?
2 „Gefällt mir“
Der MiSTer arbeitet mit den exakten krummen Cores wie die Originale. Also beim C64 war das ca. 49,2 Hz. Auf jeden Fall krumm genug, dass manche Monitore / TVs oder Capture Karten aussteigen. Man kann aber die Ausgabe auf 50 oder 60 Hz festzurren. So habe ich das bei mir gemacht, da ich keinen Multisync/Freesync Monitor habe. Außerdem mag meine Elgato HD60+ nur bestimmte Bildwiederholfrequenzen.
1 „Gefällt mir“
Zu dem DE10 Nano gibt es viele Informationen:
https://www.intel.com/content/www/us/en/developer/articles/guide/terasic-de10-nano-get-started-guide.html
Der verwendete Cyclone V5 SoC hat neben einem ARM Cortex-A9 einen FPGA mit 110.000 programmierbaren Gattern.
Mich würde es wundern, wenn ein FPGA keine harte Echtzeitfähigkeit hat. Ggf. wird die auch vom Host-Linux gesteuert? Ich kenne mich da aber auch zu wenig aus. Wenn FPGAs nicht grundsätzlich Echtzeitfähig wären, stünde das IMHO auch ein wenig im Widerspruch zu den verwendeten Einsatzgebieten, wo es auch auf Echzeit-Signalverarbeitung ankommt. Es gibt mittlerweile für alte Computer nachgebildete Chips in FPGA Technik, die man in die alte Hardware einsetzen kann. Gab/Gibt es nicht eine FPGA-Denise für den Amiga? Aber wie zuvor erwähnt … ich bin User kein FPGA-Experte. 
@Arne Du hast doch mal mit Deinen Studenten etwas in FPGA entwickelt? Vielleicht bist Du da eher kompetent?
1 „Gefällt mir“
ich glaube man muss klarstellen was Echtzeitfähig bedeutet: Es heißt nur, dass man Garantiert, dass etwas in einer definierten Zeitspanne erledigt ist. Bei harter Echtzeitfähigkeit wird das Ergebnis dann verworfen, bei weicher gibt es Ausnahmen bzw. weitere definierte Toleranzen.
Nur weil man mit einem festen Takt arbeitet, bedeutet es eben nicht, dass etwas Echtzeitfähig ist. Daher kommt ja meine Frage Der Takt schwankt ja auch mit der Temperatur. Echtzeitfähigkeit wird hauptsächlich nur in Sicherheitsrelevanten Applikationen eingesetzt, weil es sehr schwierig ist und man sich einen Rattenschwanz hinterher zieht der nicht einfach zu beherrschen ist (zumindest wenn es mehr als ein Taschenrechner ist).
FPGAs werden hauptsächlich da benutzt wo der Energieverbrauch nebensächlich ist, aber man möglichst flexibel sein möchte, falls man nicht weiß was sich da noch tut. Meistens arbeiten sie ja auch nicht alleine, sondern werden mit einer Platine kombiniert und übernehmen nur einen kleinen Teil der Aufgaben.
Real-Time wird übrigens in der Signalverarbeitung oft falsch angewandt Prinzpiell wird in frage gestellt ob komplexere System überhaupt Echtzeitfähig sein können und geht soweit dass infragestellt wird ob etwas komplexer als ein Lichtschalter Echtzeitfähig sein kann.
Sowohl in der NTSC wie auch PAL version? Aber lustig, aber sehe ich jetzt auch nicht so problematisch ein Signal mit so einem Takt zu erstellen, der entsteht durch die Divider die man einstellt.
2 „Gefällt mir“
Ein RPi kann selbst wenn er wollte gar nicht das Bild in den originalen 49.2 Hz eines C64 ausgeben, sondern soweit ich weiß nur standardkonformes 50/60 Hz, das ist eine Limitierung des HDMI Bausteins glaube ich. Das heißt entweder läuft der emulierte C64 flüssig aber einen Tick zu schnell, oder es werden Frames verdoppelt oder übersprungen, was zu Mikrorucklern also Stottern im Scrolling führt. Außerdem wird ein Framebuffer (Double oder Triple) benutzt, der das Bild verzögert und Lag erzeugt.
Beim MiSTer ist das komplett in der Hand des Programmierers, deswegen gehen auch zum Beispiel 72 Hz beim ST monochrom Modus. Eine moderne PC Grafikkarte mit GSync oder Freesync kann das auch, aber der Emulator muss es halt auch unterstützen und am besten noch Lagfrei. Das kann soweit ich weiß z.Zt. nur WinUAE im lagless vsync modus (beamracing).
FPGA arbeiten von Haus aus immer in absoluter Echtzeit. Herkömmliche Computersysteme können das aber auch prinzipiell (siehe Baremetal), wenn man direkt in Assembler ohne Multitasking Betriebssystem programmiert. Wenn ich auf dem Amiga in Assembler programmiere und das Betriebssystem dabei abschalte, dann ist das auch in Echtzeit. Das heißt, ich weiß genau, wie lange es verzögert, wenn ich vier NOP (no Operation) Instruktionen nacheinander ablaufen lasse, das wird auch gerne als NOP Timing bezeichnet. Bei Mikroprozessoren wie Arduino ist es dasselbe. Das habe ich auch schonmal gemacht, bei der Retroadaptermod Firmware, wo man zum Beispiel Gamecube Controller mit einem Arduino an moderne Geräte anschließen kann. Da musste das Timing halt genau auf die Mikrosekunde stimmen. Einfach ein paar NOPs eingefügt in den Assemblercode und es ging.
Das Problem warum moderne OS nicht echtzeitfähig sind, ist eher dass ein Kernel jedes laufende Programm ständig unterbrechen kann, um irgendeinem Treiber oder anderem Prozess auch Zeit zu geben. Wenn man Betriebssystemkonform programmiert, kommt man da nicht drum herum. Und welcher Emulator schaltet schon das Betriebssystem ab (geht das überhaupt noch)?
Ein Grossteil der Arbeit beim Synthetisieren von kompliziertem VHDL/Verilog Code wie den MiSTer Cores besteht übrigens darin, dass sichergestellt wird, dass das Timing „geschlossen“ wird, also jedes Gatter, so wie es platziert wurde, bei der vom Entwickler festgelegten Clockfrequenz Zeit hat, auch umzuschalten. Selbst die Temperatur des FPGA Chips wird bei modernen Entwicklungsumgebungen mit berücksichtigt. Das heißt, es wird dem Entwickler angezeigt bei wieviel Grad der Schaltkreis nicht mehr alle Gatter rechtzeitig umschalten kann innerhalb einer Uhrperiode.
1 „Gefällt mir“
Nein, wenn man auf NTSC umschaltet, dann müsste die Bildwiederholfrequenz anders sein. Ich nutze den C64 meistens nur in PAL, da die meisten Spiele aus Europa stammen.
Hier habe ich noch etwas Interessantes zum Timing gefunden:
"➨In FPGA design, software takes care of routing, placement and timing. This makes lesser manual intervention. The design flow eliminates complex and time consuming place and router, floor planning and timing analysis. "
Ehrlich gesagt, kenne ich den Begriff der Echtzeitsysteme nur aus dem Softwarebereich bzw. von Betriebssystemen. Aber wie hier zitiert, übernimmt eine Software das Timing. Ich denke, das wird doch auch irgendwo im SoC gemacht und nicht im Host-Linux?
1 „Gefällt mir“
Du musst das beim MiSTer trennen was auf Linux auf dem integrierten ARM läuft und was auf dem FPGA direkt läuft. Auf dem FPGA läuft in Echtzeit das alte Gerät (C64, Amiga) etc., ohne dass etwas dazwischenfunken kann. Auf dem Linux auf dem integrierten ARM läuft das File I/O und USB.
Wenn der Core jetzt ein File laden will, dann fragt er über eine implementierte Kommunikationsschnittstelle beim Linux an, gib mir mal die Daten des Files, und die werden dann übertragen. Aus der Sicht des Cores sieht das dann aus wie ein altes Diskettenlaufwerk oder Festplatte von dem Daten kommen.
Genau so ist es bei Controllern. Der Core will die Controllerdaten haben, und Linux liefert ihm die letzten bekannten. Aus der Sicht des Cores ist da ein Competition Pro Joystick an der virtuellen Joystickbuchse, aber in Wirklichkeit kommen die Daten von Linux. Linux kann aber nicht dann den Controller auslesen, wenn der Core es genau dann braucht, weil Linux nicht in Echtzeit perfekt synchron mit dem Core läuft. Also fragt Linux die Controller so schnell wie möglich immer ab, mit 1000 Hz im Falle des MiSTer, um dann immer sehr aktuelle Daten liefern zu können, wenn sie vom
Core benötigt werden.
2 „Gefällt mir“