nicht-MK3 bezogenes FPGA OT

Zitat von GeTE

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

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

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

Zitat von kinzi

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.

Zitat von ZeHa

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 ;-)=

Zitat von 0xdeadbeef

Zitat von Ruudi

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 , 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!

Zitat von Unseen

Zitat von Ruudi

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

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

Zitat von Ruudi

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!

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!

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

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?

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...

Zitat von androSID

Zitat von Ruudi

..... 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.

*Also keine Refurbs aus obskuren China-Tempeln

Alles anzeigen

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...)