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

last post from RexRetro at the

Arduino (FPGA/ARM) als Basis für einen Retro-Computer [aus: Neuer Retro-Computer ...]

  • Eventuell mal über nen Raspi-Zero als "Peripherie" nachdenken. Der kann HDMI, USB, Massenspeicher und Netzwerk "erledigen". Dann kann man sich schön auf den Retro-Kern konzentrieren und die, die es brauchen/wollen, können die Brücke in die Moderne schlagen. Siehe https://github.com/hoglet67/RGBtoHDMI , https://github.com/c0pperdragon/Amiga-Digital-Video , https://github.com/captain-amygdala/pistorm usw. usf.

    Ja, ich weiß, auf dem Raspi Zero könnte man gleich eine "VM" für jedwelche Retrophantasien bauen und auf weitere Hardware verzichten, aber das wäre eindeutig zu einfach.

  • Verstehe ich das jetzt richtig: Du verzichtest notgedrungen auf die eigentlich anvisierten 480 Pixel?

    Anscheinend machen die riesige Probleme – und ich bin pragmatisch veranlagt. Auf VGA-Out (als Schnittstelle) stehe ich trotzdem nicht, da kann heute doch niemand mehr was anfangen. Wichtig ist mir auch das Seitenverhältnis von 16:9 – die 320 x 240 (bzw. 640 x 480 skaliert) müssen also verzerrt werden. Der Grafiker muss sich darauf verlassen können, dass die Pixel eher breit als hoch sind – wenn er z.B. einen Kreis pixelt. Auf dem C64 wird ja auch nicht auf einmal Multicolor mit quadratischen Pixeln in 4:5 hochkant dargestellt.


    Also bei meinem Fernseher (Panasonic) kann ich da nichts einstellen.

    Also, bei meinem TV kann ich verschiedene Seitenverhältnisse einstellen und erhalte dann je nach Input an verschiednen Seiten schwarze Balken oder aber es werden Bereiche abgeschnitten oder aber das Bild vollflächig verzerrt. Ich kann mir irgendwie auch nicht vorstellen, dass es 16:9-Geräte gibt, bei denen das nicht der Fall ist. Die müssen doch zwangsläufig auch irgendwie mit altem 4:3-Material umgehen – und da gibt es nun mal nicht nur eine Lösung.


    war ja der Hauptgrund dafür, HDMI bereits im Rechner zu verbauen

    Bei deiner Shield-Lösung gefielen mir die Legacy-Inputs aber auch genau so wenig, wie VGA-Out. Controller müssen über BT dran, Tastatur über USB/BT, WLAN ist auch Pflicht.


    Es wird schwierig sein, zwischen einer 320 Pixel-Anzeige und einer 640 Pixel-Anzeige künstliche Begrenzungen einzuführen, denn all diese erfordern aufwendigen Code im FPGA.

    Vielleicht stellst du es dir vielleicht am besten als 2 getrennte Grafikkarten vor – eine nur mit Textmode, eine mit Bitmap. Auch der Apple II und der Specci konnten im Textmode keinerlei Grafik darstellen, da der Zeichensatz unveränderlich war.


    Oder man macht es halt wie beim CPC und setzt eine Obergrenze von 2 Farben pro Zeile.

    Ich möchte die Farbe im Textmode vor allem für Syntax-Highlighting und ein paar UI-Sachen verwenden – da nützen mir 2 Farben je Zeile wenig. Ich hätte gerne je Char mindestens eine der beiden Farben frei definierbar (wie im C64-Hires-Charmode), besser beide (wie im C64-Hires-Bitmap-Mode). Mehr als 2 Farben ja Char sind aber nicht notwendig. Vielleicht fällt dir da ja ein gangbarer Weg ein. Mir würden übrigens 640 x 240 (auf 640 x 480 aufgeblasen) vollkommen ausreichen. Dann hätte man ungefähr die Textdarstellung vom C128 im 80Z-Mode – nur mit 30 statt 25 Zeilen.


    Wie ist es z. B. mit dem X-Scrollregister? Wird das lahmgelegt? Kann man die Adresse des Zeichensatz umsetzen? Wenn beides möglich ist, wird sich sicherlich jemand finden, der für diesen Modus ein Ballerspiel schreibt.

    Im Charmode benötigen wir kein pixelweises Scrolling, in X-Richtung ohnehin nicht. Wie gesagt, kein veränderlicher Zeichensatz. Für Spiele eher untauglich außer man steht auf alte PET- oder ZX81-Games.


    Ich glaube Overscan könbte bei TVs noch ein Thema sein.

    Allerdings kann man ja auch die meisten Flat-TVs als Monitor-Ersatz für den PC nutzen. Verschwindet dann die Windows-Taskleiste oder die Mac-Menüleiste einfach im Overscan? Oder teilt der PC dem TV mit, dass er sowas einfach mal sein lassen sollte?

  • Wie teuer wäre denn dieser FPGA

    Das kommt darauf an, wie gross er sein soll und ob du den aus zuverlässigen Quellen, unzuverlässigen Quellen oder mit direktem Draht zu Xilinx beziehst.


    gibt es dafür günstige Evaluationboards bzw. Module?

    Es gab definitiv mindestens ein günstiges Spartan 6-Evalboard/-Modul mit HDMI-Anschlüssen (miniSpartan 6), ein nicht ganz so günstiges (Digilent Atlys) und vermutlich auch noch weitere, aber das ist nicht unbedingt ein Markt den ich im Detail verfolge. Ausserdem ist der Spartan 6 schon ziemlich alt und wird von der aktuellen Xilinx-Synthesesoftware (die ich noch nicht verwendet habe) nicht unterstützt.


    Gibt es da irgendwelche bezahlbaren Dev Boards mit DVI/HDMI-Out für ETechnik-Noobs mit SMD Lötallergie (wie mich)?

    SMD-Löten kann man lernen. BGA muss ich aber mangels geeigneter Ausstattung auch vermeiden oder bestücken lassen.


    Ich würde nal 16:9 Formate wie 640x360 und 768x432 testen wollen.

    Protip: Das Verhalten verschiedener Anzeigegeräte bei Nicht-Standard-Auflösungen reicht von "No signal" über "Es sieht so ähnlich wie ein Bild aus" über "Das sind nicht die Farben mit denen ich gerechnet hätte" über "Seitenverhältnis wird ausgewürfelt und die Option abgeschaltet" über "Prima Bild, aber die Bits zum Seitenverhältnis im Infoframe werden ignoriert obwohl sie sonst auswertet würden" über "Geht alles prima, aber manchmal passiert beim Auflösungswechsel was seltsames" bis zu "Keine Probleme". Teilweise auch mit verschiedenen Stufen beim gleichen Gerät je nach Auflösung. Wenn du was problemlos funktionierendes willst, nimm eine Standardauflösung und halte dich exakt an die Positionen und Längen der Sync-Signale aus den Specs - ein um ein Pixel verschobenes HSync hat zB bei GCVideo-DVI dafür gesorgt, dass bestimmte Fernseher (IIRC Panasonic) das Bild mit vertauschten Cb- und Cr-Kanälen verarbeitet haben.

  • Gibt es da irgendwelche bezahlbaren Dev Boards mit DVI/HDMI-Out für ETechnik-Noobs mit SMD Lötallergie (wie mich)?

    SMD-Löten kann man lernen. BGA muss ich aber mangels geeigneter Ausstattung auch vermeiden oder bestücken lassen.

    Ich habe inzwischen festgestellt, dass alle, die das behaupten, ein fettes, teures Stereomikroskop rumstehen haben.

    Ohne sehe ich mit meinen Augen gar nix und so ein Mikroskop ist mir definitiv zu teuer.


    Immer wieder diese Mär, dass jeder SMD-Löten könne. :S


    Aber BGA geht dann nicht mangels Ausstattung. ;)

  • Ich könnte mir die VGA-Auflösung als HDMI-Output vorstellen, allerdings dann verzerrt auf 1920 x 1080 (das müsste man am TV ja einstellen können, wenn es nicht per default passiert). Dann hätte man etwas in die Breite gezogene Pixel, ähnlich der C64-Multicolor-Auflösung (oder auch beim NES). Als native Grafikauflösung für Spiele hätte man dann 1/4 dieser Auflösung, also 320 x 240 Pixel (natürlich auch in die Breite gezogen). Diese Auflösung müsste dann der FPGA nur auf VGA (640 x 480) hochskalieren (das sollte ja nicht allzu aufwendig sein).

    Verstehe ich das jetzt richtig: Du verzichtest notgedrungen auf die eigentlich anvisierten 480 Pixel?

    Evtl. muss ich nochmal ein wenig zurückrudern bzw. nach Lösungen suchen. 320 x 240 Pixel (aufgeblasen auf 640 x 480) sind schon eine ganze Menge – mehr als der Amiga in den meisten (NTSC)-Games verwendet hat. Das ist auch mehr, als z.B. das Neo-Neo für seine opulenten Spiele zur Verfügung hatte (320 x 224). Da muss man schon eine Menge pixeln, damit der Screen voll wird. Es ist für einen 8-Bit-Style nach meinem Geschmack auch schon etwas zu viel. Und viel mehr als beim Pico-8 ist es ohnehin.


    Allerdings: alle diese Systeme haben ihre Auflösungen nicht auf riesigen 16:9-TV dargestellt, wo das einzelne Pixel dann auf einmal knackscharf und Fingernagel-groß erscheint. Vielleicht muss man sich das auch erstmal in Ruhe in Original-Größe angucken, um das wirklich beurteilen zu können.


    Hier mal ein paar 320 x 240 px Grafiken (das erste zudem auf 16 Farben reduziert) – auf 1920 x 1080 hochskaliert:


    640x480>FullHD01.png 640x480>FullHD02.png 640x480>FullHD03.png


    Die sind (und erscheinen) jetzt natürlich verzerrt, da die Designer von quadratischen Pixeln ausgingen, die wir hier nicht mehr haben. Das wäre bei nativen Games natürlich anders.


    Ein zusätzliches Problem stellt auch einfach der Umstand dar, dass 1080 kein Vielfaches von 480 ist (von 360 z.B. aber schon) – VGA-Standard hin oder her. Es wäre natürlich schon wünschenswert - da einfach rechnerisch eine saubere Lösung zu finden.


    Ich glaube Overscan könbte bei TVs noch ein Thema sein. Beim Raspi kann man ja einen Border einstellen, wahrscheinlich um Overscan Verschnitt zu kompensieren.

    Das klingt nach einer guten Idee – allerdings dürften die zusätzlichen Border-Zeilen/Spalten ja nicht außen angehängt werden (da das außerhalb der Norm wäre), sondern innerhalb der 640 x 480 Pixel, was dann natürlich ein einfaches Hochrechnen durch verdoppeln der 320 x 240 Pixel im Wege stünde).


    Ich würde das gerne mal alles an 2 hier existierenden TVs austesten – ich weiß aber noch nicht, mit welcher "Quelle". Mein Mac kommt bei der Auflösung, glaube ich, nicht mehr soweit runter und bei anderen Rechnern weiß ich nicht, ob ich dafür einen HDMI-Adapter finde.

  • Im V4000 Forum wurde geschrieben, dieser Cyclone 10 mache mit LVDS transmitter 640 Gbits.

    Und 8 statt 10 Bit pro Farbkanal sollte auch gehen.

    Hast Du für die 640 Gbits ne Quelle?


    Da war ich undeutlich. Die 10 Bit sind schon die auf der Leitung:

    "TMDS nutzt einen spezifischen 8b10b-Code um Bytes auf 10 Bit lange Sequenzen zu erweitern, die im langfristigen Mittel gleich viele Einsen und Nullen enthalten, und gleichzeitig möglichst wenig Wechsel enthalten." (behauptet Wiki)


    Oder kann man die Farbtiefe bei HDMI noch weiter reduzieren?

  • Man sollte bei den Aufloesungen evtl auch noch den Overscan miteinberechnen, weswegen ich die Darstellung mit einem Rand durchaus sinnvoll finde.


    Beispielsweise koennte man eine Aufloesung von 256x192 festlegen (oder 256x144 fuer 16:9), diese so weit es geht integer hochskalieren (z.B. 7-fach, dann waeren wir bei 1792x1008) und drumherum einen einfarbigen oder schwarzen Rand anzeigen. Ist dann nicht Bildschirmfuellend, aber retro, und viele Fernseher haben ja noch heute einen Overscan-Bereich soweit ich weiss (auch wenn ein sog. "Game Mode" das abschalten kann). Haette aber auch noch den Vorteil dass man wirklich die Aufloesung nehmen kann, die einem gefaellt, ohne dass sie ein perfekter Teiler von 1920x1080 oder so sein muss.


    Gerade noch festgestellt: 256x144 ist jedoch ein perfekter Teiler von 1280x720, also HD. Da waere dann kein Rand erforderlich. Macht dann aber die Idee mit dem Overscan wieder zunichte. Naja, ist eh alles kompliziert dieser Aufloesungs-Wirrwar :)



    Ich bin aber durchaus der Meinung, dass Aufloesungen bis 320x240 super ausreichen, also 640x480 und aehnliches braucht es nicht, um tolle Grafiken auf den Bildschirm zu zaubern. Die meisten 16-bit-Konsolen bewegen sich noch in diesem Rahmen, und wir wollen hier ja eher in Richtung 8-bit gehen soweit ich das verstanden habe.

  • Eventuell mal über nen Raspi-Zero als "Peripherie" nachdenken. Der kann HDMI, USB, Massenspeicher und Netzwerk "erledigen". Dann kann man sich schön auf den Retro-Kern konzentrieren und die, die es brauchen/wollen, können die Brücke in die Moderne schlagen. Siehe https://github.com/hoglet67/RGBtoHDMI , https://github.com/c0pperdragon/Amiga-Digital-Video , https://github.com/captain-amygdala/pistorm usw. usf.

    Ja, ich weiß, auf dem Raspi Zero könnte man gleich eine "VM" für jedwelche Retrophantasien bauen und auf weitere Hardware verzichten, aber das wäre eindeutig zu einfach.

    Ja, das wäre auch eine Möglichkeit, evtl. sogar die günstigste. Z.B. auch RC2014 (mini) nutzt optional einen Pi Zero als (Grafik) Terminal.

    Wenn man es schafft alle OCS/ECS Signale an Denise nahezu latenzfrei abzugreifen und als HD über HDMI auszugeben, sollte das auch bei RetroFans Wunschauflösungen machbar sein.


    CPU und Retro-Grafikprozessor mit Tiles, Sprites, Textmode, etc. wäre immer noch im FPGA, aber der müsste das nicht zwanghaft in HD bis FullHD hochskalieren und als konformes DVI oder HDMI ausgeben.

    Ideal wäre ein FPGA Addon-Board für Raspi-0-W mit evtl. 2MB SRAM. Der Raspi würde den FPGA initialisieren und alle moderne I/O liefern.


    Und ja: man kann natürlich auf einem Raspi Zero auch genauso gut alles emulieren - auch bare metal (wenn man wie ich jegliches OS Bloatware unterhalb der Emulation vermeiden will). Trotzdem vermittelt mir ein FPGA immer noch das Gefühl "echter" Hardware. Es ist halt nicht nur ein Fantasy-System, das auf einer deutlich potenteren Hardware emuliert wird, sondern es könnte rein theoretisch ein eigener ASIC sein (z.B. Google sponsort Open Source Hardware Projekte, indem sie ein paar 130nm ASICs auf einem geteilten Wafer bezahlen. Und nein, ich will keinen eigenen ASIC haben, bin nur sehr fasziniert davon, dass sowas passiert).

  • Ich bin aber durchaus der Meinung, dass Aufloesungen bis 320x240 super ausreichen

    Das hatte ich ja auch schon gesagt – bzw. dass das schon fast zu viel ist. Die 640 x 480 stehen ja nur im Raum, weil das evtl. die geringste Auflösung ist, die HDMI annimmt (zumindest wird das hier "behauptet"). Man muss also die native Game-Computer-Auflösung auf irgendwas skalieren, das der HDMI-Eingang des TVs annimmt (und dann nochmal auf die volle Bildschirmgröße skaliert). Und das Doppelt-skalierte deswegen, weil das Board es nicht schafft, direkt 1920 x 1080 aus dem Ausgangsmaterial zu generieren.


    weswegen ich die Darstellung mit einem Rand durchaus sinnvoll finde.

    Um den (möglichen) Overscan auszugleichen (warum nur machen die so einen Scheiß, wenn doch 1920 x 1080 Pixel reinkommt und das der nativen Display-Auflösung entspricht????), macht ein zusätzlicher, dann verschwindender, Rand evtl. Sinn. Sollte man den aber sehen, sieht das speziell auf aktuellen (nahezu randlosen) Screens ein wenig so aus, wie gewollt aber nicht gekonnt.

  • Die geringste HDMI-Auflösung müsste doch
    https://de.wikipedia.org/wiki/720p

    sein, oder?
    Skalierungsmatsch wird's wohl so immer geben, mindestens 1x.

    Evtl. von Retro-Auflösung auf 720p aber dann sicher von 720p auf Full-HD, 4K ect....

    720p hätte wahrscheinlich den Vorteil dass es von möglichst vielen 16:9 Bildschirmen (TV und Monitor) unterstützt wird. TVs werden wohl zusätzlich TV-Auflösungen wie PAL/NTSC unterstützen und Monitore eher "Monitor-Auflösungen". Da scheint 720p die Schnittmenge zu sein.

  • Retrofan Ja, das war nur bestaetigend gemeint. Also dass auch ich der Meinung bin, dass man kein 640x480 nativ braucht. Vielleicht technisch, weil HDMI auch 640x480 kann (als Fallback eigentlich), und vielleicht ist das auch cool als Abwaerts-Kompatibilitaet (weil man dann auch alte Displays nutzen kann). Aber als "Nutzaufloesung" wurde ich auf jeden Fall irgendetwas bis max. 320x240 anpeilen und dann entsprechend skalieren/verdoppeln.

  • Im V4000 Forum wurde geschrieben, dieser Cyclone 10 mache mit LVDS transmitter 640 Gbits.

    Und 8 statt 10 Bit pro Farbkanal sollte auch gehen.

    Hast Du für die 640 Gbits ne Quelle?

    Ich bezog mich auf diesen Post im Arduino.cc MKR Vidor 4000 Forum:

    https://forum.arduino.cc/t/max…ignal-resolution/600454/2


    Ich habe dann im Cyclone 10 LP device datasheet gesucht, und denke in Tabelle 27 steht sowas:


    pasted-from-clipboard.png


    Ich bin aber bzgl. FPGAs und E-Technik absoluter Laie und blutiger Anfänger. Evtl. misinterpretiere ich da auch was.



    Da war ich undeutlich. Die 10 Bit sind schon die auf der Leitung:

    "TMDS nutzt einen spezifischen 8b10b-Code um Bytes auf 10 Bit lange Sequenzen zu erweitern, die im langfristigen Mittel gleich viele Einsen und Nullen enthalten, und gleichzeitig möglichst wenig Wechsel enthalten." (behauptet Wiki)


    Oder kann man die Farbtiefe bei HDMI noch weiter reduzieren?

    Da hast Du vollkommen recht. Sorry, hatte die 8->10 Codierung nicht bedacht, sondern vermutete, Du meinst HDR-HDMI Signale mit 10 Bit Farbtiefe. Weniger als 8 Bit sind wohl kaum vorgesehen.

  • Ich bin aber durchaus der Meinung, dass Aufloesungen bis 320x240 super ausreichen, also 640x480 und aehnliches braucht es nicht, um tolle Grafiken auf den Bildschirm zu zaubern. Die meisten 16-bit-Konsolen bewegen sich noch in diesem Rahmen, und wir wollen hier ja eher in Richtung 8-bit gehen soweit ich das verstanden habe.

    Zur Orientierung mal ein Schaubild:


    screenres.png

  • Vielleicht technisch, weil HDMI auch 640x480 kann (als Fallback eigentlich), und vielleicht ist das auch cool als Abwaerts-Kompatibilitaet (weil man dann auch alte Displays nutzen kann)

    Es muss dem User aber klar sein, dass er auf einem alten 4:3-Gerät dann eine verzerrte Darstellung erhält, weil die Spieldesigner (hoffentlich) Widescreen als Ziel-Seitenverhältnis ansehen.


    Die geringste HDMI-Auflösung müsste doch
    https://de.wikipedia.org/wiki/720p

    sein, oder?
    Skalierungsmatsch wird's wohl so immer geben, mindestens 1x.

    Evtl. von Retro-Auflösung auf 720p aber dann sicher von 720p auf Full-HD, 4K ect....

    480p geht wohl auch noch. Aber irgend eine handfeste Doku, was HDMI wirklich (nach unten hin) annimmt, gibt es anscheinend nicht, oder doch?


    Aber mir gefällt 720 ganz gut. Das ist, wie 1080, ein vielfaches von 360 bzw. 180. Und 180 wäre eine schöne Vertikal-Auflösung für Retro-Games. Und für Anwendungen dann halt 360 – das wären 45 Zeilen, wenn man nah genug am Bildschirm sitzt. Das einzige, was an 180 px nervt, ist, dass es kein Vielfaches von 8 ist. Da könnte man sich evt. damit behelfen, dass man jeweils unten und oben 2 schwarze, kaum auffallende Pixelzeilen hätte und als Netto-Auflösung dann 176 Pixel.


    Aber das Ganze mit den glatten Vielfachen etc. könnte evtl. durch den Overscan-Mist torpediert werden. Das müssten wir erstmal klären: wieviel verschwindet da – und kann man das verhindern?

  • Hier mal ein Beispiel, das Bild ist 320x180 gross, der gruene Rahmen 256x144


    pasted-from-clipboard.png


    Wenn man nun allerdings die HDMI-Fallback-Aufloesung 640x480 nimmt, dann waere es ja ein 4:3-Seitenverhaeltnis, welches allerdings auf einem HD-Monitor in 16:9 angezeigt wird. Demnach koennte man auch 256x192 nehmen:


    pasted-from-clipboard.png


    Allerdings wuerde das dann auf einem 16:9-Bildschirm so aussehen:


    pasted-from-clipboard.png


    Dann muesste man als Grafiker das halt von vorneherein mit einkalkulieren, oder damit leben, dass einige Spiele eher nach VC20 aussehen :)

  • 480p geht wohl auch noch. Aber irgend eine handfeste Doku, was HDMI wirklich (nach unten hin) annimmt, gibt es anscheinend nicht, oder doch?

    Ich hab zumindest auch nix brauchbareres gefunden. Wo steht das mit HDMI und 480p? Ist HDMI nicht immer 16:9?

    Ob ein aktueller 16:9 TV auch 480p per HDMI "kennt"?


    Aber mir gefällt 720 ganz gut. Das ist, wie 1080, ein vielfaches von 360 bzw. 180. Und 180 wäre eine schöne Vertikal-Auflösung für Retro-Games. Und für Anwendungen dann halt 360 – das wären 45 Zeilen, wenn man nah genug am Bildschirm sitzt. Das einzige, was an 180 px nervt, ist, dass es kein Vielfaches von 8 ist. Da könnte man sich evt. damit behelfen, dass man jeweils unten und oben 2 schwarze, kaum auffallende Pixelzeilen hätte und als Netto-Auflösung dann 176 Pixel.

    Vielleicht habe ich da zuviel C64 im Kopf, aber weniger Auflösung als beim C64 finde ich schade. Vorwärts immer, rückwärts nimmer. ;)


    Mir ist auch noch keine ideale Auflösung eingefallen, die man nehmen könnte. Im Normalmodus sollten das ca. 320x200 sein, im "Editormodus" 640x400.

    16/9=1.777

    1920/1080=1.777

    320/1.7777=180

    Hmmm....:whistling:

  • Tobias soweit mir bekannt ist, ist 640x480 im HDMI-Standard als "Fallback-Aufloesung" integriert.

    "Die Spezifikation von HDMI schreibt nur 480p und zwei Audiokanäle vor. Alle anderen in der Spezifikation genannten Merkmale sind dagegen optional. Das gilt ausnahmslos für alle HDMI-Versionen."

    https://www.elektronik-kompendium.de/sites/com/1205041.htm

    Wäre trotzdem spannend, ob das auch wirklich noch alle 2K Monitore und TVs akzeptieren und ob die das breitziehen oder schwarze Ränder haben.

  • Ich bezog mich auf diesen Post im Arduino.cc MKR Vidor 4000 Forum:

    https://forum.arduino.cc/t/max…ignal-resolution/600454/2


    Ich habe dann im Cyclone 10 LP device datasheet gesucht, und denke in Tabelle 27 steht sowas:

    Cool! Danke!

    O.k. das sind dann doch "nur" 640Mbps nicht Gbps (sonst wäre es ja auch zu einfach). Aber das ist ja schon mal deutlich mehr als die 250Mbps die daybyter für den Cyclone 2 angepeilt hat:

    Wenn jemand mitbasteln will, hätte ich hier vielleicht ein Konzept, wie der Cyclone 2 quasi VGA als HDMI Signal ausgeben kann. Dann sind wir bei 250 MHZ Ausgabetakt pro Farb-Bit, was wohl das Höchste der Gefühle sein dürfte. Wenn es mehr sein muss, müsste da wohl eine zusätzliche Hardware her, die den Takt verdoppelt, verdreifacht, vervierfacht usw. Kost Geld und ich seh ehrlich gesagt nicht so recht den Vorteil.

    Da wäre das Cyclone 10 Board bezüglich Video-Ausgabe wohl die bessere Wahl zum weitertüfteln.