Hello, Guest the thread was called1.9k times and contains 43 replays

last post from DivZero at the

nicht-MK3 bezogenes FPGA OT

  • Hm. gerade erst gesehen ... ohje, genau das wünschen sogar andere: X(

    Von "Wünschen" kann keine Rede sein, sogar in keinster Weise, da ich an sich kein Fan der Gerätegattung Retro-FPGA-xyz bin, einzige Ausnahme: das MIST, denn das ist wirklich universell ausgelegt und kann somit auch für GANZ ANDERE Dinge verwendet werden, wo man eben nur mal HDMI und ein paar "PC"-Schnittstellen braucht...


    Auch ein FPGA-Ansatz ist eine Emulation, die auf Software basiert, nur dann eben in anderer Sprache geschrieben und auf anderer HW ausgeführt. D.h. da tuts ein 50 EUR Raspi mit freiem Emulator drauf dann genauso, hat auch HDMI und zig USB-Schnittstellen etc.



    Ich hatte lediglich technisch eine Breakout-Box vorgeschlagen und zwar eine rein elektromechanische, d.h. sämtliche Signale gehen über eine VIELPOLIGE, aber dennoch kleine (=> High-Density) Buchse nach aussen, dort KANN man eine Breakout-Box oder auch nur einzelne Adapterkabel für beliebig zu konfigurierende Teilmengen dann anschliessen.


    Es muss also nicht auf jeden Fall eine "klobige" Box irgendwo stehen, wenngleich der Brotkasten auch damals schon keinen Designpreis gewonnen hat und es daher eigentlich ganz gut dazu passen würde 8)


    Von USB-C war überhaupt nicht die Rede, wozu auch?

  • Ruudi es mag für DICH das gleiche sein, aber der FPGA-Ansatz ist technisch gesehen eben schon etwas völlig anderes als ein Software-Emulator auf einem Raspberry Pi. Dazu gibt es hier im Forum auch schon ausführliche Threads die den Unterschied beschreiben. Und eine FPGA-Emulation wird eben nicht "ausgeführt", dieser Begriff ist irreführend.

  • Ruudi Jemandem wie dir mit deinem Background dürfte der Unterschied zwischen einem FPGA und Software-Emulation aber schon geläufig sein, oder?

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Ruudi Jemandem wie dir mit deinem Background dürfte der Unterschied zwischen einem FPGA und Software-Emulation aber schon geläufig sein, oder?

    War der Meinung, das gleich mit dazu geschrieben zu haben: auch eine FPGA braucht SOFTWARE (von Abel über VHDL bis System-C), nur eben ANDERE Software, da anders (theoretisch massiv parallel) organisiert, als die eher sequenziellen Prozessoren, wobei sich das gerade zu vermischen beginnt, wie man auch an den Zukäufen von intel und AMD sehen kann... (gibts natürlich auch schon länger, hatte z.b. 2006 beruflich ne FPGA-Karte von NI mit im PC stecken, darauf konnte man schon damals den C64 oder auch nen PC-AT komplett emulieren samt VGA-Out, das Ding diente aber der schnöden Bus-Protokoll-Entwicklung automotive ...)


    Aber letztlich setzt man sowohl mit einer FPGA als auch mit einer Softwareemulation gut um den Faktor 10 hoch 6 MEHR Transistoren ein, als im Original zu finden waren und diese Transistoren sind in beiden Fällen ganz anders verdrahtet und laufen mit ganz anderen Takten, ebenso teils um obigen Faktor höher...


    Also jeweils mit Kanonen auf Spatzen geschossen, wobei aber der PC den Vorteil hat, dass ich ihn ausser für die nostalgische Emulation eines C64 oder Amiga auch zum tagtäglichen und produktiven Arbeiten verwenden kann und dass man heute zum Preis eines solchen, hochproprietären FPGA-Systems schon ganze Notebooks samt formschönen Gehäuse und gutem TFT, SSD etc. bekommt, während man so ein FPGA-Teil nur noch zusätzlich rumstehen hat und produktiv ist das zu so gut wie gar nix zu gebrauchen, es sei denn, man macht da auch beruflich was mit und hat insofern Wissen wie auch (teure, wenns nicht gerade um die Einsteiger-FPGAs geht) und komplexe Software dafür zur Verfügung, auf einem Rechner meist, der auch die Emulation super doll könnte ;-)


    Aber soll kein Bekehrungsversuch sein, warum auch, soll jeder so glücklich werden, wie er eben kann!


    Mir geht an der PC-Emulation wirklich nur der Expansion- und Userport ab, "früher" hatte man am PC immerhin noch einen Parallelport, den man auf die Schnelle mal als "Userport" verwenden konnte...


    Apropos:


    Selbst für ISA- und PCI-Bus gibt es inzwischen "USB"-Breakout-Boxen, mit denen man alte HW wie Spezial-Interface-Karte etc. noch betreiben kann.

    Sowas wäre für die Ports des C64 doch auch mal der Bringer, gut in eine Emulation integriert versteht sich... Eproms brennen, mit SFX-Sound oder Sprachausgabe experimentieren, IEEE488-parallel mit Kernalunterstützung oder auch den alten CRT-Schirm mit 80Z-Karte unter CP/M nutzen oder die selbstgebaute Eisenbahnsteuerung wieder zum Leben erwecken etc etc etc.

  • Ruudi es mag für DICH das gleiche sein, aber der FPGA-Ansatz ist technisch gesehen eben schon etwas völlig anderes als ein Software-Emulator auf einem Raspberry Pi. Dazu gibt es hier im Forum auch schon ausführliche Threads die den Unterschied beschreiben. Und eine FPGA-Emulation wird eben nicht "ausgeführt", dieser Begriff ist irreführend.

    Tja, das WAR wohl mal wahr, inzwischen wäre ich mir da gar nicht mehr so sicher, die Grenzen verwischen zusehens und dank System-C nähert sich auch die Art der Programmierung an.


    Das klassische FPGA wird einmalig, defakto aber bei jedem Reset SERIELL (egal ob auf Bit oder Byte/Word etc Länge) "geladen" und führt dann die geladene PROGRAMMIERUNG parallel in allen Elementen aus. Jeglicher Zugriff auf gemeinsame Information setzt dieser Parallelität aber strikte Grenzen. Gerade nicht benötigte Elemente werden quasi "angehalten", aber meist dennoch getaktet, was sich für die Energie-Effizienz nicht unbedingt gut ausnimmt...


    Ein klassischer Prozessor lädt ein Programm schrittweise und führt dabei mit wechselnden Parametern fest verdrahtete (eventuell noch um eine Microcode-Ebene weiter unten liegende...) Funktionen in seinem Kern aus. Der festverdrahtete Teil wird dabei zugunsten hoher Flexibilität und sogar (theoretisch) rekursiver Eigenprogrammierbarkeit möglichst klein gehalten, die Reaktionszeiten steigen durch die sequenzielle Natur, aber dem wird mit Mehrkernkonzepten, Interprozesskommunikation, Pipelines und out of Order execution u.a. auch wieder dagegen gehalten.


    Inzwischen sind aber FPGAs mit in HW integrierten Prozessorkern wie auch eine gemischte Synthese (sprich Soft-Prozessoren werden auf dem FPGA vom compiler erzeugt) auf dem Vormarsch, als auch andersrum FPGA-artige Strukturen nicht mehr nur in reinen GPUs, sondern auch in klassischen CPUs Einzug halten. Als ANWENDER weiß man dann auf beiden Plattformen nie, ob beim "Compilieren" oder "bauen" das Ergebnis dann im Prozessor sequenziell oder doch parallel in -dafür temporär festverdrahteter Logik umgesetzt wird oder meist gemischt, wenn dies aufgrund der Konstrukte sinnvoll und ressourcensparenste Variante vom Compiler so ausgewählt und umgesetzt wurde.


    Das ist -auf höherer Abstraktionsebene dann ähnlich, wie man beim C64 noch recht genau wusste, in welchen Bytes sein Programm und seine Daten dazu lagen oder auf der Diskette, wo genau welches Bit gespeichert wurde. Das ist beim PC längst schon nicht mehr so, es läuft über zig HALs und Virtualisierungen und gerade Code ist ziemlich frei verschiebbar geworden...


    Genauso läuft das inzwischen mit dem sogenannten "System-Partitioning", man kennt nun nicht mal mehr den Aufbau der Struktur, auf dem der Task läuft! (unser Hirn machts genauso, nur noch komplexer..)


    So könnte man schon heute die Emulation nicht mehr nur auf der CPU des PC sondern -entsprechende HW vorausgesetzt und dem Compiler bekannt- auch auf deren GPU (ehemals als Grafikkarte bekannt...)verteilt laufen lassen, mit deutlich niedrigeren Latenzzeiten und ebenso massiv parallelem Ansatz, wo nötig und sinnvoll.


    Hart echtzeitfähig ist ein System aber so wie so immer nur in Bezug auf eine wohldefinierte Aufgabe, eine geforderte Reaktionszeit. Und die liegt z.b. bei der Emulation des C64 minimal im Bereich von Mikrosekunden, wenn es um IRQ und NMI oder Register-Inhaltswechsel der peripheren Chips geht (wobei das nur selten wirklich in diesem Raster auch kritisch ist) oder auch z.b. nur bei 50 Hz, wenn es z.b. um Tastaturabfrage oder auch framegerechte Ausgabe geht. Alles dazwischen ist möglich, z.b. Rasterinterrupts, um Bildschirmmodi zu mischen etc. Was hingegen die simulierte oder nachgebildete CPU oder Peripherie INTERN macht, das interessiert hierbei in beiden Ansätzen nicht, da es keinerlei direkte Wirkung nach aussen hin zeigt.


    Die benötigten Reaktionszeiten schaffen heute aber BEIDE Ansätze technisch locker, wenngleich unterschiedliche Probleme bei der Realisierung auftreten. So spielt beim PC z.b. die durchs *normale* Betriebssystem vorgegebene kleinste Reaktionszeit dagegen (was sich durch einen RT-Kernal genauso beheben lässt, wie durch parallele Threads in der Software), beim FPGA kostet jede vorzuhaltende Konfigurations-Variante mehr als das Doppelte an Ressourcen, da man eben die Zielhardware in Summe vorhält, egal was auf dieser "kommen" mag...


    Sorry fürs Labern, aber das musste jetzt sein ;-)=

  • Tja, das WAR wohl mal wahr, inzwischen wäre ich mir da gar nicht mehr so sicher, die Grenzen verwischen zusehens und dank System-C nähert sich auch die Art der Programmierung an.

    System-C ist eine Klassenbibliothek zur Hardwarebeschreibung und auch VHDL und Verilog sind keine Programmiersprachen, sondern Hardwarebeschreibungssprachen. Natürlich gibt es gewisse Überschneidungen, aber das sind doch ganz unterschiedliche Konzepte. Letztlich bildet man mit einem FPGA-basierten Emulator die Hardware auf Gatterebene nach (quasi "bottom up") und mit einer SW-Emulator versucht man "nur", zum gleichen Ergebnis zu kommen und kann sich dabei aussuchen, wie tief man dabei in die Details gehen will (quasi "top down"). Wenn man nur spielen will, kann man sich darüber streiten, ob man unbedingt die Nachbildung per FPGA braucht, aber wenn man das Timing echter Ein- und Ausgänge im Bereich weniger Nanosekunden nachahmen will, führt derzeit halt kein Weg an einer FPGA-Lösung vorbei. Eine Nachbildung im FPGA hat natürlich auch den Charme, zumindest theoretisch eine 100% identische Nachbildung des Original zu sein zu können.

    Aber natürlich hat der FPGA-Ansatz auch Nachteile. Speziell die Anbindung an die Außenwelt (GUI, moderne Ein- und Ausgänge) ist sehr viel aufwendiger als bei einem SW-Emulator. Deshalb benutzen moderne FPGA-Emulatoren wie MiSTer ja auch ein paar Abkürzungen für externes Filehandling, USB-Anschlüsse usw.

  • Eben so sehe ich das auch; natuerlich "programmiert" man einen FPGA mit "Software" bzw. mit einer Sprache, aber das ist trotzdem was anderes als wenn ein tatsaechliches Programm auf einer CPU und meist unter einem Betriebssystem ausgefuehrt wird. Wenn man ein Platinenlayout an einen Hersteller schickt, ist das ja im weitesten Sinne auch "Software", weils digital gespeichert ist und einen Schaltkreis beschreibt (gut, ohne die Bauteile, aber das Prinzip ist ja das selbe). Auch ist es doch meines Wissens so, dass man prinzipiell jeden FPGA-Schaltkreis hinterher auch in einen echten Schaltkreiss "giessen" kann - ist es nicht sogar so, dass sogar grosse CPUs wie z.B. von Intel und AMD erst als FPGA-Prototypen erzeugt werden, um sie zu testen? Einen Software-Emulator hingegen kann man nicht einfach so in Hardware verwandeln.

  • Tja, das WAR wohl mal wahr, inzwischen wäre ich mir da gar nicht mehr so sicher, die Grenzen verwischen zusehens und dank System-C nähert sich auch die Art der Programmierung an.

    System-C ist eine Klassenbibliothek zur Hardwarebeschreibung und auch VHDL und Verilog sind keine Programmiersprachen, sondern Hardwarebeschreibungssprachen. Natürlich gibt es gewisse Überschneidungen, aber das sind doch ganz unterschiedliche Konzepte. Letztlich bildet man mit einem FPGA-basierten Emulator die Hardware auf Gatterebene nach (quasi "bottom up") und mit einer SW-Emulator versucht man "nur", zum gleichen Ergebnis zu kommen und kann sich dabei aussuchen, wie tief man dabei in die Details gehen will (quasi "top down"). Wenn man nur spielen will, kann man sich darüber streiten, ob man unbedingt die Nachbildung per FPGA braucht, aber wenn man das Timing echter Ein- und Ausgänge im Bereich weniger Nanosekunden nachahmen will, führt derzeit halt kein Weg an einer FPGA-Lösung vorbei. Eine Nachbildung im FPGA hat natürlich auch den Charme, zumindest theoretisch eine 100% identische Nachbildung des Original zu sein zu können.

    Aber natürlich hat der FPGA-Ansatz auch Nachteile. Speziell die Anbindung an die Außenwelt (GUI, moderne Ein- und Ausgänge) ist sehr viel aufwendiger als bei einem SW-Emulator. Deshalb benutzen moderne FPGA-Emulatoren wie MiSTer ja auch ein paar Abkürzungen für externes Filehandling, USB-Anschlüsse usw.


    Nun, wenige ns, da sind die Toleranzen in den CSG/MOS-Datenblättern aber sehr viel toleranter als diese "Meinung"...


    Und selbst im µs-Bereich spielt -Bilderzeugung des VIC-II mal aussen vor- nur sehr wenig eine wirkliche Rolle, wenn man das Ganze als "Black box" betrachtet, d.h. nur als Zuschauer von Aussen, die wir als User nun mal sind. (mit einer minimalen Reaktionszeit weit im zweistelligen ms-Bereich und kaum Speichertiefe dann)


    Nehmen wir z.b. mal den seriellen IEC-Bus: gerade zu gemächlich geht es dort zu, im Original mit ca. 400µs/bit, beschleunigt entweder parallel, also von den Zeiten und Flanken her nicht anders oder eben durch Umkehr der Synchronisierungs-Taktquelle, da der 6510 ja bekanntlich regelmäßig "erstarrt", damit der VIC den Speicher refreshen kann und auch dann streift man kaum die 100µs/bit, da die Beschleuniger meist mit 2 oder gar 3bit parallel arbeiteten, was eben mit dem 6pol. Kabel abzgl. dem nicht nutzbaren reset und GND so ging.


    Ein paar µs, von ns ganz zu schweigen, spielen also auch dort keine Rolle, so genau hätte man das seinerzeit auch gar nicht hinbekommen, schon gar nicht C=, die ja auch mal gerne das Timing mit Kondensatoren "fixten", die schon eine Fertigungsstreuung von 10% und mehr hatten, vom Verhalten über Temperatur, Feuchte und Alterung ganz zu schweigen, ebenso von der Toleranz der "Stromquellen", sprich FAN-Outs der ansteuernden Bausteine...


    Oder der SID, das menschliche Gehör geht bis 20kHz, wenn wir jung sind, was wir damals ja auch waren :whistling:, aber 20kHz sind für uns nur noch als Sinus, also als Grundwelle wahrnehmbar. Stereo konnte der SID nicht, also nix mit Phasenlage oder ähnlichen Einwänden. Aber selbst wenn man noch 2 Oktaven aufs menschliche Gehör drauf gibt, dann wären wir erst bei ca 12 µs, kein Problem für heutige Prozessoren und D/A-Wandler, aber sehr wohl für die 6502-CPU, die mit dem Datenschaufeln dann gar nicht mehr hinterhergekommen wäre, von den Refresh/Sprite-bedingten Zwangspausen ganz zu schweigen...


    Bleibt der VIC-II: das kritischste Timing ist es sicherlich, trotz der Zwangspause beim refresh, jedesmal genau die gleiche Rasterzeile zu erwischen, um den VIC-II in internen Registern für die Rahmen und/oder Hintergrundfarbe halbwegs "zitterfrei" umzuschalten, oder die Pointer auf Sprites und/oder Bildschirmspeicher zu verbiegen.


    Hier ergibt sich für die Simulation (die ja KEINE Zwangspause einlegen muss) ein Zeitfenster von ca 20% der Dauer einer Bildschirmzeile, bei Pal interlaced dauert eine Zeile 1/(50x312) s. also 1/15625s oder 64 µs, davon 20%, also 12 µs. Sportlich für eine 1MHz-CPU, aber für ein, zwei Register-Writes reicht es... Die Simulation auf einem heutigen x64 hat dazu -im Vergleich- fast alle Zeit der Welt und der Mensch bekommt es sicher NICHT mit, wenn es aufgrund der Tatsache dass die wenigsten Bildschirm-Modes heute noch mit 50Hz interlaced rumflimmern, dann möglicherweise 1 Frame oder 1/70s Verzögerung herrscht, bis das Bild sich am Bildschirm tatsächlich ändert...


    Und ach ja: auch die FPGAs bilden die ehemalige HW weder auf Gatterebene ab, da viele Mechanismen damals echt asynchron implementiert waren (sonst wäre eine 6502 nicht mit den 3500 Transistoren darstellbar, im FPGA jedoch nur synchron machbar, noch läuft der FPGA denn mit dem Pixel-Clock oder den daraus abgeleiteten CPU-Clocks, vermutlich viele Einheiten nichtmal mit einem ganzzahligen Vielfachen davon!



    Und zum Thema "NUR spielen": ich dachte ja immer, Spiele wären die anspruchsvollsten Anwendungen hinsichtlich der Kompatibilität von Emulatoren, sei es HW-basierte oder SW-basierte?


    Was denn sonst wäre kritischer? Ein Eprombrenner am Userport etwa? die damaligen Algos sahen 50ms/Byte vor, "Schnelle Algos" gingen bis auf 5ms runter, dieses Timing würde sogar noch ein via USB-Bridge angebundener "PC-Userport" Ersatz schaffen!


    Meine damalige Geschäftssoftware lief jedenfalls nach Anpassung von ein paar "Peeks", die beim VC-20 und C-64 noch die joystick-Abfrage (Mausersatz) übernehmen mussten auch auf Plus/4 und später mit erstaunlich wenig weiteren Anpassungen auf dem PC unter PDS-Basic (den meisten wohl nur als Q-Basic bekannt, PDS war die Bezahlversion mit Compiler davon...)


    Solange ich als menschlicher Betrachter und "user" so ein System benutze und nicht via Logic-Analyzer direkt auf den Bus schaue, wann sich dort irgendein Bit ändert, so lange brauche ich da kein FPGA, um das zu realisieren, zumindest NICHT MEHR, wenn man sich die heutigen Taktfrequenzen und MIPS-Zahlen selbst von 08-15 CPUs so ansieht.


    Vor 20 Jahren hätte ich noch in einigen Punkten zugestimmt, aber damals hatte auch kein bezahlbares FPGA -samt Entwicklungsumgebung- die notwendige Anzahl an Zellen und die internen Takte lagen auch noch durchaus bescheidener als heute...


    Natürlich, wenn ich die Systemgrenze am Expansionport lege und dann eine echte HW wie die Super-CPU anschliessen will, dann tue ich mich mit einer Software-Emulation sehr schwer, heute sogar noch schwerer als vor einigen Jahren, da durch die fortschreitende Hochintegration heute kaum noch ein dafür brauchbarer Bus im PC zugänglich ist, resp. bei den seriellen Hochgeschwindigkeitsbussen ja dann zumindest dort wieder ein FPGA als Interface Dienst tun müsste, am ISA-Bus wäre das notfalls noch mit TTL-Logik gegangen...


    Aber was hat die SuperCPU denn an Schnittstellen zu mir als Mensch, von den paar läppischen LEDs abgesehen? Also wird die auch mit in Software emuliert und das Timing plötzlich absolut unkritisch, denn die Schnittstellen nach Aussen bleiben ja bekanntlich die Videoausgabe, der SID und die CIAs, welche aber im Original nur mit 1Mhz, max. 2MHz liefen und mangels DMA (von der REU mal abgesehen) vom Prozessor ja sinnvoll nur mit gut einem Zehntel oder weniger davon befüllt werden konnten...


    Schon der UR-8bit-ISA-Bus von 1983 lief aber mit 4,77 MHz und konnte DMA, d.h. war für solche Dinge schneller als die REU, von PCI und Nachfolgern ganz zu schweigen...


    Ich bleibe dabei: solange ich nicht die Prozesse IN den Chips IN ECHTZEIT emulieren möchte, brauche ich kein FPGA, und wenn ich da -aus welchen Gründen auch immer- heute so tief reinschnüffeln will, dann brauche ich dazu als Mensch erst recht keine Echtzeit!

  • und auch dann streift man kaum die 100µs/bit

    Die üblichen Softwarefastloader liegen im Bereich von 10 bis 15 Mikrosekunden pro Bitpaar.


    Ein paar µs, von ns ganz zu schweigen, spielen also auch dort keine Rolle

    JiffyDOS hat zB ein sehr auf Kante genähtes Timing, wenn die C64-Seite da um eine Mikrosekunde abweicht kann es gelegentlich Übertragungsfehler geben - der C64DTV braucht zB ein leicht gepatchtes Jiffy-Kernal weil das Timing des da rausgeführten IEC-Bus im Vergleich zum Original knapp daneben liegt.


    auch die FPGAs bilden die ehemalige HW weder auf Gatterebene ab, da viele Mechanismen damals echt asynchron implementiert waren (sonst wäre eine 6502 nicht mit den 3500 Transistoren darstellbar, im FPGA jedoch nur synchron machbar

    Warum sollte es nur synchron machbar sein? Achronix ist da sicherlich anderer Meinung.

  • und auch dann streift man kaum die 100µs/bit

    Die üblichen Softwarefastloader liegen im Bereich von 10 bis 15 Mikrosekunden pro Bitpaar.


    Ein paar µs, von ns ganz zu schweigen, spielen also auch dort keine Rolle

    JiffyDOS hat zB ein sehr auf Kante genähtes Timing, wenn die C64-Seite da um eine Mikrosekunde abweicht kann es gelegentlich Übertragungsfehler geben - der C64DTV braucht zB ein leicht gepatchtes Jiffy-Kernal weil das Timing des da rausgeführten IEC-Bus im Vergleich zum Original knapp daneben liegt


    10 - 15 µs/2bit wären 16,6 - 25 kByte/s, d.h. 2-3s für 202Blocks, aber immer noch Faktor 1000 über der Erstaussage " ein paar ns"...


    Hab aber noch keinen seriellen Fastloader gesehen, der es unter 6s schafft, meist eher 10-12s.


    Soweit mir bekannt dreht Jiffy eben wegen des -aufgrund der VIC-Busblockaden- unregelmäßigen Takts der CPU das Protokoll dahingehend um, dass der C64 Clockmaster ist.


    Dann wäre er sich ja quasi selbst im Weg...


    Weiß es Jemand sicher?


    Gibt es eigentlich -ausser dem, was Dr. Adler aka "NLQ" mal reverse engineered hat- nen dokumentiertes Quellcodelisting von Jiffy-Dos auf beiden Seiten, C64 und 1541?



    ABER: Das ist ja gerade das "schöne" an einer Software-Emulation:


    Der Datenfluss zw. Floppy und Computer läuft dort komplett IN DER Blackbox, d.h. da braucht überhaupt kein Timing zu stimmen (aber natürlich die Reihenfolge im Ablauf), im Idealfall wird erkannt "202 Blocks" mit jiffy oder CBM-DOS laden und diese werden mit der Geschwindigkeit des Hosts dann in die passende RAM-Struktur des Hosts kopiert (oder falls in C programmiert: über pointer einfach gelinkt...)


    Wenn ein Spiel einen eigenen "Fastloader" mitbringt, wirds Befehl für Befehl simuliert, dauert dann halt eher ewas länger, bei den heutigen CPUs nicht wirklich spürbar...


    "Passen" muss das Timing nur an den Aussenschnittstellen der Blackbox und wenn das nur noch das MMI zum User ist, dann wirds sehr einfach, da wir Menschen verdammt träge reagieren im Vergleich!


    Will damit nicht die Leistungen derer schmälern, die diese Blackbox programmiert haben, da steckt jede Menge Hirnschmalz drin und es wurde ja auch oft genug quasi wieder bei Null angefangen, bis der heutige Standard erreicht war.


    Aber gerade weil es den ja nun schon gibt, spricht doch mehr dafür, den auch zu nutzen, anstelle sich die nächste proprietäre und bald veraltete und kaum zu reparierende Lösung hinzustellen, das sind so meine Überlegungen dazu.


    Und wenn ich nen "echten" C64 vor mir haben will: die gibts ja auch noch und noch schaut es nicht danach aus, als ob die bald wirklich knapp werden würden...

    Vermutlich werden wir User schneller weniger, wie die verbleibene Hardware und ob wir in 20-30 Jahren uns dann noch damit auseinander setzen WOLLEN, das steht nochmals auf nem anderen Blatt...


    n.B.: Das wirklich Interessante finde ich übrigens, dass gerade die Leute auf "taktgenau" oder "phasengenau" pochen, die dann jeden Trick suchen, die Kiste SCHNELLER zu machen.... Netter Widerspruch finde ich!


    Just my 2 Cents!

  • Einigen Deiner Ueberlegungen stimme ich schon zu, innerhalb eines Software-Emulators sind die Timings quasi unwichtig, da hier schrittweise gearbeitet werden kann und ein Emulator ja z.B. deshalb auch problemlos in anderen Geschwindigkeiten laufen kann (siehe z.B. Warp-Modus im VICE). Und natuerlich kann in der Theorie ein Software-Emulator bei gegeben hoher "Host-System-Performance" auch das Original-System komplett authentisch nachbilden.


    Trotzdem haben die FPGA-Loesungen meiner Meinung nach in einigen Punkten die Nase vorn, vor allem wenn es um das Generieren von Signalen geht, z.B. ein analoges Bildsignal in der benoetigten Frequenz, und das auch ohne Latenzen usw, oder die Verarbeitung von Input-Signalen. Sogar das Video-Signal ueber HDMI bei Gideons Ultimate64-Board kommt bei mir latenzfrei aus der Kiste! Und zwar wirklich 1:1 gleichzeitig mit dem analogen Signal, zumindest konnte ich keinen Versatz feststellen, als ich gleichzeitig meinen Beamer als auch einen Commodore-Monitor dran hatte. Bei einem Software-Emulator auf einem PC hat man immer das 50/60-Hz-Problem, beim Sound hat man einen gewissen Audio-Buffer der erst gefuellt werden moechte, etc. Selbst beim TheC64, der ja im Prinzip das "Software-Emulations-Pendant" zum U64 oder MK3 waere, sind etliche Berichte ueber zu hohe Latenz bekannt.


    Und ich verstehe auch nicht Dein Argument bzgl. der "proprietaeren" Loesung, die bald veraltet sei, natuerlich ist das MK3 dann ein proprietaeres Produkt, aber da der FPGA ja wie Du selbst sagst ebenfalls in Software programmiert ist, spricht doch nichts dagegen, diese Software auch auf zukuenftigen FPGA-Loesungen laufen zu lassen. Dass Jens' Produkt nicht open-source sein wird, dafuer kann FPGA-Technik per se ja nichts, und in diesem Falle muesste man halt auf ein MK4 warten oder auf ein TC64-III. Davon abgesehen wuesste ich auch nicht, warum man ein MK3 jemals als "veraltet" betrachten sollte, denn wenn es alles kann, was der C64 auch kann, und dies auch im gefuehlt originalen Timing macht, dann kann man das MK3 doch auch in 10, 20 Jahren noch ganz normal nutzen. Zudem ist denkbar, dass irgendwann auch immer mehr FPGA-OpenSource-Cores entstehen, die gut sind, also sehe ich in dieser Hinsicht kein Argument fuer die Software-Emulation und gegen FPGA.


    n.B.: Das wirklich Interessante finde ich übrigens, dass gerade die Leute auf "taktgenau" oder "phasengenau" pochen, die dann jeden Trick suchen, die Kiste SCHNELLER zu machen.... Netter Widerspruch finde ich!

    Finde ich nicht! Das eine sind die Original-Rahmenbedingungen, die der C64 nunmal bietet, und da der die historische Vorlage ist, sollte die Emulation doch so exakt wie moeglich sein, oder nicht? Das andere ist das "alles rausholen" aus diesen gesetzten Grenzen, das ist nunmal der Sport der Demoszene. Den gab es aber schon zu Zeiten der Originalhardware, und man moechte ja dann schliesslich auch dass das auf allen kompatiblen Geraeten und Nachbauten genauso aussieht. Oder meinst Du jetzt weil die Leute sich ein JiffyDOS einbauen?

  • Mit proprietär meine ich die Kombination aus closed source mit einem FPGA, das in ein paar Jahren vermutlich ebenso schwer erhältlich sein wird, wie aktuell ein guter VIC-II oder gar TED, mit dem Unterschied allerdings, dass ein FPGA (Sofern dessen "Programmierung" überhaupt extern und ungeschützt ist , d.h. nach Tausch überhaupt noch läuft resp. auch nach Tausch des Flash/EEPROM wieder herstellbar ist) ungleich schwerer zu tauschen ist als ein DIL-40 und dass es vermutlich KEINEN geben wird, der dann einen FPGA-Ersatz fürs obsolete FPGA entwickeln wird...


    Also letztlich kauft man damit eine Hardware, die vermutlich (rein in der Zukunft) schneller irreparabel ist, als das Original, das aber jetzt schon über 35 Jahre auf dem Buckel hat!


    Auf ebay gibt es zur Zeit NOS-C64 PCBs aus Händlerbestand, die gehen teils unter 100 EUR weg und sind glaubwürdig wirklich ungebraucht, nur gelagert.

    Davon 2 oder 3 kaufen, dann würde ich behaupten, besteht kein Bedarf mehr auf Lebenszeit (es sei denn, man bastelt gerne und unvorsichtig...)


    Bislang -toi toi toi- hatte ich mit meinen Erstbesitz-Geräten noch KEINE Ausfälle!

  • ..... vermutlich ebenso schwer erhältlich sein wird, wie aktuell ein guter VIC-II oder gar TED, ......

    Da isser' wieder: Der Mythos vom schwer erhältlichen VIC-II oder TED!


    Also wenn ich mich umschaue sind z.B. ECHTE* 6502A inzwischen schwerer erhältlich als die o.g. Chips. :nixwiss:





    *Also keine Refurbs aus obskuren China-Tempeln

  • 10 - 15 µs/2bit wären 16,6 - 25 kByte/s, d.h. 2-3s für 202Blocks, aber immer noch Faktor 1000 über der Erstaussage " ein paar ns"...

    Ich hätte einen Zettel in einen Umschlag stecken sollen, in dem ich diese Rechnung vorhersage. =) 10-15 Mikrosekunden pro Bitpaar heisst nicht, dass diese Geschwindigkeit für die komplette Datei eingehalten wird. Die mittlere Geschwindigkeit ist geringer, weil da noch Dinge wie Handshakes zwischen den Bytes und das tatsächliche Lesen von Daten von Disk dazukommen. Die genannte Zahl ist das Timing für die Übertragung eines einzelnen Bytes und die ist nicht verhandelbar - sobald der C64 dem Laufwerk mitteilt, dass es das nächste Byte senden soll wird es mit einem festen, von der Laufzeit des Codes bestimmten Timing abgeschickt und wenn der C64 die Daten nicht zum richtigen Zeitpunkt ausliest sind sie weg.


    Soweit mir bekannt dreht Jiffy eben wegen des -aufgrund der VIC-Busblockaden- unregelmäßigen Takts der CPU das Protokoll dahingehend um, dass der C64 Clockmaster ist.

    Das ist falsch: Jiffy sendet und empfängt Bytes mit festem, durch die Codelaufzeit vorgegebenem Timing.


    Es gibt auch Fastloader, die tatsächlich wie von dir behauptet funktionieren, aber die sind typischerweise dafür designt, zu jedem Zeitpunkt beliebig lange unterbrochen werden zu können, damit sie in einem Spiel oder einer Demo parallel zu Rastereffekten laufen zu können, ohne diese zu stören.


    "Passen" muss das Timing nur an den Aussenschnittstellen der Blackbox und wenn das nur noch das MMI zum User ist, dann wirds sehr einfach, da wir Menschen verdammt träge reagieren im Vergleich!

    Klar, auf den ersten Blick könnte man einfach die Emulation immer ein komplettes Frame so schnell wie möglich berechnen lassen und dann lange genug warten, damit die mittlere Geschwindigkeit passt. Das erhöht aber die Latenz im Vergleich zum Original oder einer Nachbildung mit Echtzeit-Timing wie einem FPGA: Angenommen, ein C64-Spiel fragt den Joystick immer kurz vor Ende des Frames ab. Durch die nur-einmal-pro-Frame-Synchronisation der Emulation verschiebt sich der Abfragezeitpunkt auf einen Zeitpunkt kurz nach Darstellung des vorherigen Frames, Benutzereingaben nach diesem Zeitpunkt aber vor dem "richtigen" Joystick-Abfragezeitpunkt werden damit erst im nächsten Frame wirksam.


    Ausserdem hatte irgendwer in diesem Thread doch vorgeschlagen, mehr echte Hardware an einen Emulator anzuschliessen:

    Selbst für ISA- und PCI-Bus gibt es inzwischen "USB"-Breakout-Boxen, mit denen man alte HW wie Spezial-Interface-Karte etc. noch betreiben kann.

    Sowas wäre für die Ports des C64 doch auch mal der Bringer, gut in eine Emulation integriert versteht sich... Eproms brennen, mit SFX-Sound oder Sprachausgabe experimentieren, IEEE488-parallel mit Kernalunterstützung oder auch den alten CRT-Schirm mit 80Z-Karte unter CP/M nutzen oder die selbstgebaute Eisenbahnsteuerung wieder zum Leben erwecken etc etc etc.

    ...was alles die Grenze zwischen emuliertem und realem Timing verschiebt.

  • Zitat von unseen:


    ... weil da noch Dinge wie Handshakes zwischen den Bytes ... dazukommen

    ...


    => Ja was jetzt?


    Handshake oder fester Zeitablauf, Beides wäre ja Verschwendung und somit unwahrscheinlich beim damaligen Programmierstil...



    Übrigens:


    1 Zyklus der 6510 im C64 dauert ca 1,1 µs


    Die meisten Befehle der 6510 dauern 3-4 Zyklen, nur wenige wie NOP weniger.


    D.h. selbst "Befehlsgenau" hat einen statistischen Jitter schon von über 2µs!


    Wenn der VIC die 6510 anhält, dauert ein Zyklus an sich plötzlich min. doppelt so lange


    Und mit lauter NOP wird auch Jiffy nicht funktionieren :D



    Das mit den delays bei der Joystickabfrage setzt voraus, dass der Raster-IRQ dafür verwendet wird, der Standard-Tastatur-IRQ ist nicht zu den Frames synchron.


    50Hz (das Eine wie das Andere bei "uns", sprich PAL und 220V Netz) sind 20ms Periodendauer. Geht man davon aus, dass noch etwas entprellt wird, also erst bei der 2. Abfrage dann reagiert wird, kommt man im Mittel eben auf ein delay von 20ms schon auf Originalsoftware.


    Ist die Abfrage an den Raster-IRQ gekoppelt, hängt der Delay davon ab, welche Rasterzeile verwendet wird und wo davon relativ die Spielfigur sich befindet, d.h. ob kurz nach der Aktualisierung der relevanten Bildteile abgefragt wird (kurzes delay...) oder eben schon davor (langes delay min. 20ms).


    Ich bezweifle, dass sich ein Spieleentwickler seinerzeit um sowas geschert hat, bedenkt man doch, dass die menschliche Reaktionszeit (Auge -> Hirn -> Muskel) auf jeden Fall deutlich größer ist, bei extremen Training sind 100ms erreichbar, Otto-Normalo liegt eher bei 250-300ms!


    Oder hat es die Menschheit etwa geschafft, diese Reaktionszeit innerhalb der einen Generation, die seit den ersten Telespielen vergangen ist, genetisch zu optimieren? =O


    Aber lass gut sein, es darf ja Jeder kaufen was er will und mit spielen...


    Und ich habe mich ja schon geoutet, dass ich ja mit dem MIST auch ein FPGA-Teil mein Eigen nenne, wenn auch seltenst als C64 genutzt, sondern mehr als universelles Entwicklungssystem mit "netten" Schnittstellen ab Werk...

  • Also letztlich kauft man damit eine Hardware, die vermutlich (rein in der Zukunft) schneller irreparabel ist, als das Original, das aber jetzt schon über 35 Jahre auf dem Buckel hat!

    Ganz ehrlich, ich glaube kaum dass hier jemand diese Hardware fuer die naechsten 35 Jahre kauft. Wenn U64 und MK3 und Co in 35 Jahren noch laufen, ist das natuerlich supergeil, aber hier im Forum sieht man doch, dass die Kohle fuers Retro-Hobby locker sitzt und man eh immer das neueste haben will - und das meine ich jetzt nicht abwertend, sondern einfach nur realistisch und auch ueberhaupt nicht schlimm. Es ist ein Hobby und wenn es in 10 Jahren was viel geileres gibt als das U64, dann kauft man sich das eh, also ist es nicht wichtig dass das U64 in 35 Jahren noch laeuft oder aktualisierbar ist oder was auch immer. Auch der C64 wurde damals von keinem mit dem Ziel gekauft, in 35 Jahren noch betrieben zu werden! Und das gleiche gilt auch fuer VIC- oder SID-Nachbauten, die kauft man weil sie jetzt verfuegbar sind und weil man Spass damit hat, aber wenn es in 2 Jahren schon den besseren SID gibt, dann kauft man den halt auch noch. Das ist Teil des Hobbys und hier wird keiner nach streng wirtschaftlichen Denkmustern vorgehen.


    dass die menschliche Reaktionszeit (Auge -> Hirn -> Muskel) auf jeden Fall deutlich größer ist, bei extremen Training sind 100ms erreichbar, Otto-Normalo liegt eher bei 250-300ms!

    Ja jetzt sind wir bei dem Mythos angelangt. Spiel mal ein Spiel das Du schon oft gespielt hast mit 100 ms Latenz und Du wirst feststellen, dass Du oefters verreckst als auf der Original-Hardware. Spiel mal Boulder Dash auf einem TheC64 und Du wirst viel oefter von Steinen erschlagen werden. Mag sein dass das was Du schreibst bei tatsaechlichen Zufalls-Events zutrifft, z.B. bei einem ploetzlich auf die Strasse springenden Reh, aber nicht bei erwarteten Events (also z.B. "ich laufe jetzt hier unter den Steinen vorbei und biege dann links ab und dann fallen die runter also muss ich schnell sein"). Oder spiel mal Gitarre ueber eine Amp-Modeling-Software auf Deinem PC und stell den Audio-Buffer auf 40 ms und Du wirst aus dem Tritt kommen. Oder nimm eine Drum-Spur und eine Bass-Spur und verschiebe die um 20 ms, und Du wirst hoeren dass es nicht mehr "tight" klingt. Latenzen in dieser Groessenordnung sind wahrnehmbar, und das was Du da schreibst von 250-300 ms, da kannst Du sofort den Joystick an die Wand werfen.

  • Ja was jetzt?


    Handshake oder fester Zeitablauf, Beides wäre ja Verschwendung und somit unwahrscheinlich beim damaligen Programmierstil...

    Ja, beides und nein, keine Verschwendung.


    1 Zyklus der 6510 im C64 dauert ca 1,1 µs


    Die meisten Befehle der 6510 dauern 3-4 Zyklen, nur wenige wie NOP weniger.


    D.h. selbst "Befehlsgenau" hat einen statistischen Jitter schon von über 2µs!

    Korrekt, die einfachste Art der Synchronisation zwischen Laufwerk und C64 hat eine Unsicherheit von 7 Mikrosekunden und wird zB von JiffyDOS verwendet - gerade deswegen ist es ja so empfindlich gegenüber kleinen zusätzlichen Verschiebungen im Timing. Mit etwas cleverem Code kann man diese Unsicherheit aber auch reduzieren.


    Aber dein Argument ist trotzdem irrelevant: Während der Übertragung eines einzelnen Bytes ist diese Timing-Unsicherheit konstant. So lange beide Seiten mit dem gleichen Timing senden und empfangen bleiben sie nach dem initialen Handshake synchron zueinander. Auch den kleinen Taktunterschied zwischen C64 und Laufwerk kann man dabei problemlos kompensieren, wenn man pro Handshake mehr als ein Byte übertragen möchte.


    Wenn der VIC die 6510 anhält, dauert ein Zyklus an sich plötzlich min. doppelt so lange

    Es ist genau vorhersehbar, wann der VIC die CPU anhält und Fastloader vermeiden das zB durch Ausschalten des Bildschirms oder durch Verzögerung des nächsten Bytetransfers.


    Und: Welchen Zyklus meinst du? Sicherlich nicht den CPU-Takt, der ist im C64 (im Gegensatz zB zum Apple II oder C16/+4) konstant.



    Und mit lauter NOP wird auch Jiffy nicht funktionieren

    Die Diskussion fühlt sich immer mehr wie ein Beispiel für den Dunning-Kruger-Effekt an...


    Ich bezweifle, dass sich ein Spieleentwickler seinerzeit um sowas geschert hat, bedenkt man doch, dass die menschliche Reaktionszeit (Auge -> Hirn -> Muskel) auf jeden Fall deutlich größer ist, bei extremen Training sind 100ms erreichbar, Otto-Normalo liegt eher bei 250-300ms!

    Und du meinst also, dass die Spielbarkeit nicht darunter leidet, wenn man diese Reaktionszeit nochmal künstlich verlängert?

  • Hmm, bei den Chipbrokern sehe ich jede Menge 6502A und auch 6502B von Rockwell, UMC, Synertek etc., jeweils so um die 2 EUR/Stk. bei 1000Stk Abnahme, kannst Du sowas auch für TED oder VIC-II bieten, dann würd ich gern jeweils 1000 Stk nehmen (die verklopf ich dann auf ebay für 9,90 /Stk und werd reich und als Wohltäter berühmt...)