bei NTSC-C64 sind es ca. 59,8 Hz
3 „Gefällt mir“
Und hier wäre es spannend zu wissen, ob das Polling in Echtzeit abläuft. Wird garantiert 1000 Mal gepollt? Oder kann es auch passieren, wenn der ARM überlastet ist (wie auch immer), dass dann nur noch 123 Mal die Sekunde gepollt wird?
Ich hätte gedacht, dass die Steuerung des FPGAs in einem Teil des SoC übernommen wird. Das würde IMHO mehr Sinn ergeben. Also nicht über das Hostsystem, sondern die Steuerung des logischen Gatters. Ich meine auch eine Ebene unter I/O.
Der FPGA ist nur das logische Gatter. Und um eine CPU zu simulieren, braucht man ja noch andere Elemente. Sind die alle auf dem nicht-ARM Teil vom SoC?
Gerade eine Ergänzung. Vielleicht geht das hier hervor:
Aber danach findet die I/O-Funktionalität auf dem FPGA Teil des Cyclone V5 statt? Hmm… jetzt bin ich verwirrt. → Jetzt verstehe ich es. Das Routing findet auf dem FPGA-Teil statt. Die Verarbeitung im Host.
1 „Gefällt mir“
Ist ja auch richtig so. Aber mit Timings sind hier sicher die Events gemeint die Ausgelöst werden. Ich rede von Signallaufzeiten innerhalb einer digitalen Schaltung, das ist bei der Entwicklung von ASICs/ICs sehr wichtig, weil da auch dinge wie EMV/EMC und Temperaturen einfließen. Das kann man beim FPGA gar nicht steuern soweit ich weiß (habe ich aber auch nie gesucht). Ich hatte auch schon mal den Fall, dass etwas im µC Funktioniert, im FPGA nicht und auch anders herum. Lag immer an unterschieden bei Laufzeiten der Signale (sind auch leicht zu beheben).
Ich vermute mal, dass da Hardware Funktionen (e.g. Interrupts bzw. mit Interrupts würde ich es machen) genutzt werden. Da sind die 1kHz ziemlich gut garantiert, es lässt sich aber auch einstellen was eine höhere Priorität hat. Man kann durchaus in den Fall kommen, dass ein der Interrupt hinten angestellt werden muss, weil ein Interrupt wichtiger ist und gerade etwas erledigen muss. Im Mittel wird aber 1kHz richtig sein (ist bei den original Geräten nicht anders).
2 „Gefällt mir“
Das weiss ich auch nicht. Da der USB Controllertreiber wahrscheinlich Teil des Kernels ist, könnte es schon sein, dass der Linux Kernel das garantiert dass es 1000 Mal passiert. Kann aber auch sein, dass es eher so eine Art Richtlinie ist.
Deine andere Frage verstehe ich nicht. Der FPGA muss einmalig konfiguriert werden, wenn man einen Core lädt. Das Laden des Cores auf den FPGA passiert über Linux. File I/O und USB passiert über Linux. Und das Core Menü also welche Menüfunktionen angezeigt werden sollen, dass wird glaube ich auch von Linux an den Core übertragen. Aber der Core auf dem FPGA läuft autark und unabhängig in seiner eigenen Zeit.
2 „Gefällt mir“
Das ist gut. Aber da sieht man, dass das gesamte System eigentlich nicht Echtzeitfähig ist. UART, I2C weder SPI sind echtzeitfähige Kommunikationsprotokolle (möge mich jemand korrigieren?).
Aber das ist jetzt auch nur das Hardware Blockdiagram, in Wirklichkeit wissen wir gar nicht was da alles im FPGA oder SoC läuft. Da bräuchten wir jetzt Funktionsblöcke der Softwarearchitektur 
2 „Gefällt mir“
Ja genau. Aber die wichtigen Sachen laufen beim MiSTer in Echtzeit auf dem FPGA vergnüglich vor sich hin, wie die originale Hardware es auch tun würde.
Im Idealfall würde man vielleicht auch File I/O und die USB Controller direkt in Echtzeit im FPGA machen, indem man eine eigene USB Schnittstelle in Verilog implementiert und auch das Auslesen von MikroSD Karten etc. direkt in Verilog codet. Das wäre aber extrem viel Arbeit denn man müsste auch Filesysteme wie Fat32 implementieren, und Controllertreiber für hunderte USB Controller usw.
Stattdessen setzt der MiSTer auf eine Hybridlösung, wo USB Controller und File I/O auf ein nebenbei auf einem ARM Prozessor (Teil des HPS im Diagramm) laufendes Linux ausgelagert werden. Da kommt dann erst der Kram (SPI oder wasweisich) den du erwähnst ins Spiel. Der ARM Prozessor befindet sich physikalisch direkt neben dem FPGA. Bei File I/O ist das komplett logisch, finde ich, das wird auch bei originaler Hardware über langsame Schnittstellen gelöst. Bei USB Controllern könnte man sich streiten, ob man die Linux überlassen will. Es wäre schon schön Controller direkt vom FPGA in Echtzeit auszulesen, wie bei originaler Hardware, ohne Linux. Das hat auch zu vielen Diskussionen in der MiSTer Community geführt. Daher gibt es jetzt einige Enthusiasten, die SNAC benutzen, eine dedizierte direkte FPGA Controllerschnittstelle. Die funktioniert aber nur mit bestimmten alten Controllern und benötigt angepasste Cores.
Dann hat jemand aber diesen Trick mit dem forcierten 1000 Hz USB Polling bei Linux herausgefunden und jetzt sind sowieso erstmal alle glücklich. Die Puristen setzen weiter auf SNAC aber der Lag bei den 1000 Hz ist eh nur 1-2 ms also ein Zehntel Frames oder so, mit guten Controllern.
Es werden auch extrem viele Lagtests und andere Tests von enthusiastischen Usern am MiSTer gemacht, um sicherzustellen was der Lag ist, ob der Sound akkurat ist usw.
2 „Gefällt mir“
Das wäre quark, weil der FPGA dann vermutlich zu klein ist. Und schon wäre es auch fraglich ob es alles parallel durchführen kann. Was ja das generelle Problem ist bzw. was bei den Emulatoren ein Problem macht.
Wenn man sich darüber beschwert, dann muss man eh überlegen wo die Prioritäten der Person liegt, wenn man nicht kompromissbereit ist. Das ist unnötig viel Arbeit in ein Problem zu investieren, dass eigentlich nicht existiert. Welche Relevanz hat es, dass man nach einer Stunde 3.6s akkumulierte Verzögerung hat? Da kann man dann einen Frame-Skip einbauen und man ist dann wieder in der Spur…
2 „Gefällt mir“
So schlimm ist es lange nicht. Obwohl die Controller über Linux ausgelesen werden, gibt es keinerlei akkumulierte Verzögerungen und keinerlei, absolut keinen Frameskip, nie! Der MiSTer kann endlos ohne einen einzigen Mikroruckler oder Frameskip oder verdoppelten Frame laufen! Es ist wirklich toll.
Das einzige was passiert ist, dass der Core manchmal in einem Frame etwas „veraltete“ Controllerdaten bekommt, also die von vor 2 ms statt was Du genau jetzt gerade an Knöpfen drückst, das ist alles. Es wird nichts akkumuliert und es wird auch nie das Bild verzögert oder Ähnliches. Es wird nicht gewartet nur manchmal werden alte Daten verwendet.
Es handelt sich also um reinen Inputlag keinen Videolag. Der Inputlag ist aber auch so gering, dass er finde ich vernachlässigbar ist.
Wenn Du Frameskips einbauen würdest, dann würde die MiSTer Community ausrasten, die sind da sehr empfindlich. Zurecht, finde ich. Es gibt finde ich nichts schlimmeres beim Zocken alter C64 und Amiga Spiele als unnötige Ruckler im ansonsten butterweichen Scrolling 
2 „Gefällt mir“
Es wurde schon das meiste gesagt. Das wird für den Accelerometer genutzt, der auf dem DE10 Board enthalten ist. Der wird vom Mister nicht genutzt. Das DE10 ist eigentlich ein Board für die Forschung und Lehre und wird auch subventioniert. Bei einer seriellen Schnittstelle (über UART) finde ich die Problematik mit der Echtzeit auch nicht sonderlich schlimm, da das für externe Peripherie gedacht ist. Und bei den damaligen Geschwindigkeiten der seriellen Schnittstelle kann man IMHO die Echtzeitproblematik auch fast vernachlässigen. 
Es gibt an dem Board sicherlich noch einige Dinge zu optimieren, aber bei einigen Bausteinen macht das IMHO nicht wirklich Sinn. Interessanter wird es, wenn analoge Chips per FPGA abgebildet werden. Wie z.B. der SID-Chip. Das ist eine Herausforderung, wo FPGAs an die Grenzen kommen.
Spannendes Thema… muss aber weiter arbeiten ;-).
2 „Gefällt mir“
Gerade noch gesucht. Also wenn ich diese Grafik richtig interpretiere, findet das Timing und die Steuerung doch in bestimmten Teilen außerhalb des FPGA bzw. auf dem SoC statt:
Allerdings bezieht sich das wohl nicht auf dem ARM. Was auch bedeutet, dass wenn der ARM überlastet wäre, der Core auf dem Mister nicht anfängt langsamer zu werden.
Quelle zum vertiefen: Cyclone V SoC FPGA硬核处理器系统简介 - 可编程逻辑 - 电子发烧友网
Was meinst Du mit Steuerung? Wie gesagt der FPGA hat seine eigenen Uhrsignale und läuft autark. Das HPS ist ein Bonus welches zur Konfiguration also Programmierung des FPGA benutzt werden kann (kann aber auch anders gemacht werden). Wenn der FPGA einmal programmiert ist läuft er von selbst.
Das HPS ist fest mit drin, muss aber nicht verwendet werden.
1 „Gefällt mir“
Ok, das ergibt Sinn. Die Schemata sind leider auch nicht sonderlich befriedigend.
Haben wir denn jetzt alle Leute verschreckt? So kompliziert ist der MiSTer eigentlich nicht, wie wir das jetzt hier aufgetan haben. 
@Fabu Du bist schuld, weil Du uns getriggert hast ;-).
2 „Gefällt mir“
Ihr Stalker!
Hat der eigentlich mehrere externe Taktgeber oder wird im FPGA ein Taktgeber designed der auf den gewollten Takt umwandelt?
Können nicht Da braucht man entsprechende Analoge Schaltungen. Da geht es dann schon los mit Frequenzgang und Dämpfung und bla.
Währendessen Fabu:
1 „Gefällt mir“
Ne, ich find’s super. Deswegen habe ich ja auch einen eigenen Thread daraus gemacht. 
1 „Gefällt mir“
Dass, das nicht funktioniert ist logisch. Allerdings lassen sich auf dem FPGA analoge Schaltkreise „emulieren“ (ja… hier passt das Wort ;-))
Gerade beim C64 gibt es einige Chips, die als FPGA nachgebaut wurden. Z.B. der FPGA-SID:
Hier wurde versucht (recht erfolgreich IMHO), den analogen Part des SIDs nachzubilden. Der FPGA SID ist, zumindest von vielen Leuten subjektiv empfunden, jeglicher Emulation überlegen und recht nah am Original dran.
Also im Prinzip wurde ein neuer Chip entwickelt, den man in einen C64 einsetzen kann.
Ich bin jetzt nicht sicher, ob diese Implementierung jetzt auch schon im C64 Core des Mister schlummert… irgendwie fehlt mir hier ein anderer Club27 User, der da verdammt kompetent ist. @SIDKIdd ;-p
2 „Gefällt mir“
boah dieses Videotext-Configtool:
Konnte auf die schnelle nicht sehen wie das aufgebaut ist, aber ich vermute mal, dass ist ein FPGA mit DAC und Operationsverstärkern & Co. Das schwierige ist ja, dass genaue nachbilden des Verhaltens und Ausgabe.
1 „Gefällt mir“
Der hat ein extrem komplexes Clockzeug. Ich glaube es gibt eine externe Quartzuhr (300 MHz?), und im FPGA sind mehrere Phase Locked Loop (PLL) Schaltungen eingebaut, die daraus dann andere Frequenzen erzeugen. Es ist dadurch möglich, die verschiedenen implementierten Chips der retro Geräte mit den originalen Frequenzen zu Takten, also 7.14 oder so MegaHertz beim Amiga 68000 usw.
Edit: Da ist nicht nur ein externer Quartz sondern ein ganzer externer Clock Generator IC auf dem Board. Man sieht es hier im Diagramm:
So geht es mir auch grad… Aber irgendwann muss mir halt noch jemand in einfachen Worten erklären, worum es eigentlich genau geht 
2 „Gefällt mir“
Moinsen!
Sie haben geläutet Herr @Pagefault2000 ?
Ich hab jetzt mal nur kurz so über den Thread drüber geflogen…nun kommt der Senf dazu
Die SID Nachbildung im C64 Core ist schon sehr beeindruckend. Da braucht man gute Ohren und entsprechende Kopfhörer/Monitorboxen um Unterschiede zu hören. Es ist weniger Tiefgang bei den Bass-lastigen Stücken und natürlich gibt es auch Musiken die gänzlich komplett anders klingen. Der SID ist in seiner Art und Weise vom technischen Aufbau einzigartig und jede Charge der produzierten Chips klingt auch anders. Ich bin Fan des 6581R4AR (alter SID) wenn es um Software aus den Anfängen des C64 geht. Bei moderneren Sachen (bis heute) bevorzuge ich den SID II 8580R5.
Der FPGA SID ist leider closed source. Ich kann wenn gewünscht mal ein Foto von der Platine posten, muss meinen allerdings erstmal finden Klanglich finde ich ihn besser als den MiSTer FPGA, was allerdings an den zusätzlichen Komponenten (DAC) liegen mag.
Cooles Feature: man nutzt einen FPGA SID Chip in der alten Hardware und kann zwei SIDs z.B. für Stereo Sounds aktivieren. Eine Stereoschaltung ist also integriert. Das Konfigtool habe ich bisher nur ein Mal benutzt, man hat ja seine persönliche Präferenz wie die Chips konfiguriert sein sollen.
Ich besitze auch noch einen einen Ultimate64. Das ist ein modernes Mainboard mit FPGA für den C64 mit zwei Sockeln für echte SID Chips oder wahlweise auch eine FPGA Software Variante. Da gehen dann bis zu 8 SID Chips simultan.
Und so klingen 8 SIDs gleichzeitig:
Für professionelle Audioaufnahmen habe ich einen modifizierten C64 mit einem MixSID Board und professionellen XLR Stereo Ausgängen. Auf dem Board stecken dann je nach Projekt die jeweiligen Chips, meistens die oben erwähne Mischkonfiguration aus altem und neuen SID. Besonderheit dieser Lösung ist das rauscharme Audiosignal, denn bei einem originalen C64 hört man ggfs. kleine Störgeräusche. Außerdem kann ich per Hotkey Funktion zwischen altem und neuen SID beim laufenden Musikstück umschalten.
Liebe Grüße,
Danny
4 „Gefällt mir“