Hello, Guest the thread was called10k times and contains 60 replays

last post from Highlander64 at the

Idee für einen FPGA-"C64-FBAS zu TFT"-Konverter (Brainstorming)

  • Hallo,


    mir schwebt seit ein paar Tagen eine Idee im Kopf rum, um das C64-Bild auf einem neueren TFT darstellen zu können und dabei die Qualität drastisch zu verbessern. Es gibt ja bekanntlich eine Reihe von "FBAS zu VGA"-Konvertern (FBAS ist das Videosignal, das der C64 ausgibt), wobei die meisten mehr schlecht als recht arbeiten und es ein Glückspiel ist, ein gutes Bild zu erhalten.


    Meine Idee besteht aus drei Modulen:


    Modul A (Digitalisierung):


    (Möglichst getrennte) Digitalisierung der Chroma- und Luma-Signale. Keine Ahnung mit wieviel MSPS oder wieviel Bits Auflösung. Diese digitalisierten Daten gehen dann ins nächste Modul. Sync-Signale sind bestimmt auch für das nächste Modul relevant.



    Modul B (FPGA-Teil / Speicherung):


    Hier wird das digitalisierte Bild im BlockRAM zwischengespeichert und farblich reduziert. Schließlich hat der C64 nur 16 Farben und es würde keinen Sinn machen, alle Bits des A/D-Wandlers zu speichern. Gleichzeitig hätte man den Vorteil, dass das ausgegebene Signal frei von AEC-, Phi2-, oder sonstigen Störungen wäre...



    Modul C (FPGA-Teil / Ausgabe):


    Das gespeicherte Bild wird auf einer VGA-Buchse oder einer DVI-Buchse ausgegeben. VGA würde über eine Handvoll Widerstände gehen, DVI (oder sogar HDMI) könnte man z.B. über einen Baustein von Chrontel (CH7301C) machen oder den seriellen Datenstrom sogar direkt aus einem Xilinx-Spartan-6-FPGA selbst generieren. Die Spartan-6-FPGAs sollen TMDS I/O-Support haben...


    Man könnte damit auch relativ einfach eine Darstellung von Scanlines erzeugen, indem man einfach jede zweite Zeile mit verringerter Helligkeit ausgibt...


    Wenn man dann ein Bild mit der Auflösung 800x600 (oder ggf. 1024x768) an den Monitor ausgibt, hätte man auch automatisch ein Seitenverhältnis von 4:3.


    Xilinx-FPGA-Boards habe ich hier (auch mit entsprechendem Spartan-6 oder Artix-7), allerdings habe ich sehr sehr lange nichts mehr mit VHDL gemacht (so 2-3 Äonen lang). :D




    Ist meine Idee so abwägig? Unterschätze ich den Aufwand? Wie seht ihr das? Vorschläge für geeignete A/D-Wandler? Gibt es vielleicht welche, die gleich ein FBAS- oder SV-Signal ordentlich digitalisieren?



    Ist halt erstmal nur so eine Idee von mir...


    Gruß,
    Thomas

  • Ich finde die Idee gut. Ich hatte sowas schonmal im Thread "Was wünscht ihr euch von ICOMP" angefragt, wurde aber abgelehnt weil es wohl nicht so einfach zu machen ist.
    Am liebsten wäre mir ne Multibox, die alle möglichen Eingänge hat (C64, CPC, Atari XL, Amiga) und das an einen modernen TFT ausgeben kann.

  • (Möglichst getrennte) Digitalisierung der Chroma- und Luma-Signale. Keine Ahnung mit wieviel MSPS oder wieviel Bits Auflösung. Diese digitalisierten Daten gehen dann ins nächste Modul. Sync-Signale sind bestimmt auch für das nächste Modul relevant.

    Optimal für einfache Weitergabe ans Display: Ein Vielfaches von 27 MHz
    Optimal für einfache Auswertung: Ein exaktes Vielfaches des Pixeltakts - d.h. der FPGA muss mit dem Pixeltakt des C64 verbunden oder der Takt muss per geeigneter externer PLL aus den HSyncs generiert werden


    Und was die Auflösung angeht: Typischerweise verwendet man im Consumer-Bereich nur 8 Bit für Video. Beim C64 würde noch weniger reichen, IIRC hatte Pepto doch mal rausgemessen, dass die 9 Helligkeiten des VICs sich auf einer gleichmässigen 5-Bit-Quantisierungsskala (32 Stufen) darstellen lassen. Aber da die billigen Video-ADCs eh 8 Bit haben kann man sich die Erwägungen für die Eingangsstufe sparen.


    Quote

    Hier wird das digitalisierte Bild im BlockRAM zwischengespeichert und farblich reduziert.

    Warum reduzieren? Man kann grundsätzlich zwei Wege wählen: Entweder baut man einen möglichst guten PAL/NTSC-Decoder nach Spec, um die (zum Teil ausgenutzten!) Signalartefakte mitzunehmen oder man versucht ein Bild im Emulator-Stil zu rekonstruieren, bei dem die Farbe jedes Pixels rekonstruiert wird - dann könnte man sogar die von sauhund so verhassten Paletten einbauen ;)


    Zur Farbrekonstruktion müsste man zuerst bestimmen, in welche Helligkeitsstufe das aktuelle Pixel fällt und dann mit dem Chroma-Signal entscheiden, welche der beiden in dieser Helligkeitsstufe möglichen Farben der VIC gerade ausgibt. Der erste Teil ist recht einfach. Beim zweiten Punkt bin ich mir nicht sicher wie gut das in der Praxis funktioniert, da der mit den Farbinformationen modulierte Farbträger eine geringere Frequenz als der Pixeltakt hat.


    Quote

    Schließlich hat der C64 nur 16 Farben und es würde keinen Sinn machen, alle Bits des A/D-Wandlers zu speichern.

    Na ja, ein 2 KByte-Block-RAM reicht, um eine komplette 720-Pixel-Zeile in YCbCr 4:2:2 (halbe horizontale Farbauflösung) zwischenzuspeichern - beim C64-Signal braucht man sich da eher keine Sorgen um den RAM-Bedarf zu machen, so lange man nur einzelne Zeilen zwischenspeichern will.


    Quote

    oder den seriellen Datenstrom sogar direkt aus einem Xilinx-Spartan-6-FPGA selbst generieren. Die Spartan-6-FPGAs sollen TMDS I/O-Support haben...

    Spartan 3A (aber nicht 3 oder 3E) auch, DVI funktioniert damit prima.


    Quote

    Wenn man dann ein Bild mit der Auflösung 800x600 (oder ggf. 1024x768) an den Monitor ausgibt, hätte man auch automatisch ein Seitenverhältnis von 4:3.

    Genau das würde ich keinesfalls machen, dann müsste man auch noch vertikale Skalierung einbauen. 576p (720x576x50Hz) ist auch ein hübscher Videomodus und exakt das, was man für ein zeilengedoppeltes PAL-C64-Bild braucht.


    Quote

    allerdings habe ich sehr sehr lange nichts mehr mit VHDL gemacht (so 2-3 Äonen lang)

    Macht doch nichts, so ein Projekt ist die ideale Gelegenheit, um die eigenen VHDL-Fähigkeiten wieder aufzupolieren. Ausserdem lernt man dabei mehr über Videotimings und evtl. auch DVI-/HDMI-Eigenheiten als man je wissen wollte. ;)


    Quote

    Ist meine Idee so abwägig?

    Prinzipiell nicht


    Quote

    Unterschätze ich den Aufwand?

    Einige Teile sind etwas aufwendiger, wenn man Code aus existierenden Open Source-Projekten (zB OSSC oder GCVideo) zusammenklaubt könnten einige Teile einfacher werden.


    Quote

    Gibt es vielleicht welche, die gleich ein FBAS- oder SV-Signal ordentlich digitalisieren?

    Gibt es, die Frage ist eher, ob man die zu einer guten Verarbeitung des C64-Signals überreden kann. Evtl. mal bei Analog Devices in den Produktlisten blättern?


    Alternativ könntest du versuchen, einen PAL-Decoder auf dem FPGA zu implementieren und mit einem etwas generischeren ADC arbeiten, wobei man dann immer noch einen RGB-/Component-tauglichen ADC erwägen könnte, um sich die analoge Signalvorverarbeitung zu sparen. Wenn ich Zeit für sowas hätte, würde ich versuchen sowas mit der OSSC-Hardware umzusetzen - Luma an den Y-Eingang, Chroma an Pb oder Pr und dann viel VHDL-Gefrickel um daraus geeignetes RGB zu fummeln.


    Am liebsten wäre mir ne Multibox, die alle möglichen Eingänge hat (C64, CPC, Atari XL, Amiga) und das an einen modernen TFT ausgeben kann.

    Für Systeme mit RGB- oder Component Video-Signal würde ich einen Blick auf den OSSC empfehlen. Der Preis ist natürlich deutlich jenseits der üblichen Foren-Heulgrenze, aber das im ersten Posting angedachte Projekt wäre am Ende vermutlich in einer ähnlichen Preisregion.

  • Wie ist das eigentlich bei aktuellen Flachbildfernseher, die müssten doch alle 50Hz machen, oder etwa nicht?

    jo, 576p @50Hz können die TV's wohl alle (ich hab zumindest noch keinen gesehen, der das nicht kann).
    Wie gut oder schlecht der jeweilige TV das macht, hängt vom TV (bzw. dessen Eingangsstufe ab). Aber das ist hier nicht das Thema :)

  • Ist meine Idee so abwägig? Unterschätze ich den Aufwand? Wie seht ihr das? Vorschläge für geeignete A/D-Wandler? Gibt es vielleicht welche, die gleich ein FBAS- oder SV-Signal ordentlich digitalisieren?

    Schau mal nach Chrontel's ch7010a oder nach AD's ad7180 (bzw. vergleichbare
    Chips der Hersteller), die Wandeln ein Bild nahezu perfekt ein. So gut wirst Du
    es "manuell" per ADC nicht hinbekommen, jedenfalls nicht so einfach.
    (intern arbeiten viele Chips mit mehr als 8 Bit, z.B. 9 oder 10. Dazu kommen
    Oversampling, Filterfunktionen, SYNC-Abtastung etc.)


    ich habe FPGA-Boards mit beiden Chips. Und die liefern für C64 (bzw. C128),
    Amiga, VHS-Videorecorder und andere alte Videoquellen sehr gute Bilder
    (oft vielfach besser als die ganzen kommerziellen VGA-Boxen). Dazu kann
    entweder das komplette Bild im FPGA zwischengespeichert werden (braucht
    aber schon etliche interne BlockRAMs, passt aber locker in viele FPGAs) oder
    Zeile für Zeile per Scandoubler ausgegeben werden.
    Die Ausgabe als VGA ist eiglich einfach, für HDMI etc. ist ein entsprechender
    Transmitter (z.B. von Chrontel) besser geeignet.


    Zum C64: Farb- bzw. Chromawerte der Chips (oder auch fertige RGB-Werte)
    lassen sich relativ einfach filtern und in C64-Farbwerte umrechnen, hat bei
    mir jedenfalls fehlerlos geklappt (keine Artefakte, keine Aliasingpattern etc.).


    Probeme bei "manueller" Abtastung: Wenn man das quellinterne Taktsignal
    als Taktquelle verwendet, dann hat man mit "heutigen" FPGAs das Problem,
    das die Takteingänge und die PLLs nicht so "langsame" Taktsignale akzeptieren.

  • Macht im Jahre 2017 noch auf VGA-only setzen noch Sinn?
    Meine letzten Dell Monitoren haben Duallink-DVI, HDMI und DisplayPort, wobei ich am PC Letzteres bevorzuge.
    Na gut, ich kaufe aber auch keine 17" Monitore aus der Grabbelkiste.


    HDMI wäre von der Auflösung ja auch mehr als ausreichend, hätte aber auch den Vorteil, dass man jeden TV mindestens der letzten 5 Jahre verwenden kann.

  • ich habe die Erfahrung gemacht, dass manche Monitore sich beim VGA Signal auf den Takt der Quelle synchronisieren bzw. diesen übernehmen, aber bei HDMI das Bild auf den eigenen Takt (60hz) konvertieren. das bedeutet: ruckelfrei war nur VGA

    Das mag ja sein, nur was nützt das, wenn Computermonitore immer weniger VGA haben? Bei TV war das auch eher selten der Fall.
    Dann müsste man wieder einen Adapter haben, was das ganze Vorhaben ad absurdum führt.


  • Das mag ja sein, nur was nützt das, wenn Computermonitore immer weniger VGA haben? Bei TV war das auch eher selten der Fall.Dann müsste man wieder einen Adapter haben, was das ganze Vorhaben ad absurdum führt.


    Mir ist schon klar, das dies keinen Sinn macht! Es ging es um ein anderes Problem:


    Ruckelfreie Darstellung auf modernem Display!



    Ich persönlich kann Micro-ruckler bei scrollern absolut nicht ausstehen...

  • Ruckelfreie Darstellung auf modernem Display!

    Wenn der Bildschirm schwarz bleibt, weil er keinen VGA Anschluss mehr hat....ja, dann hat es keine Ruckler, da stimme ich Dir 101% zu... :bgdev

  • Wenn der Bildschirm schwarz bleibt, weil er keinen VGA Anschluss mehr hat....ja, dann hat es keine Ruckler, da stimme ich Dir 101% zu... :bgdev


    Wie meine Frau... muß immer das letzte Wort haben! :abgelehnt



    ps: Wenn ich sehe, das seit 2016 immer noch über 300 Monitore *NEU* rausgekommen sind mit VGA-Interface
    mache ich mir um einen schwarzen Bildschirm keine sorgen!


    http://geizhals.de/?cat=monlcd19wide&xf=100_VGA%7E3311_2016

  • VGA an modernen TVs (TFTs etc) macht sowieso kaum mehr Sinn da hier wieder convertiert werden muss > Verluste. HDMI/DVI oder displayport wäre hier schon der sinnvollere
    Übertragungsstandart. Bei Röhren TVs / Monitore hingegen macht VGA Sinn. wie leicht sowas umzusetzen ist, steht auf einem anderen Blatt. Die Frage ist auch, welche Signale mir von
    vorn herein zur Verfügung stehen

  • Moin,


    ich finde die Idee gut. ;) Aber ist es nicht problematisch, dass die Video-Ausgabe eines PAL-C64 nicht richtig mit dem Soll übereinstimmt? Der gibt doch 50.15 Hertz oder so aus. Ich habe Vieles probiert, um einen C64 an mein Samsung LED-TV anzuschließen. Ein relativ aktueller Yamaha Receiver (RXV-773 oder so) gibt bei FBAS-Eingang kein Signal aus, übrigens auch nicht vom C64-DTV. Das Bild bleibt einfach schwarz. Mein alter Harman/Kardon Receiver hat S-Video, kriegt das Bild darüber aber nicht synchronisiert. Der selbe Receiver über FBAS zeigt ein ziemlich geiles Bild, aber es läuft langsam durch (vermutlich wegen der 50 Hz-Diskrepanz).


    Sieht denn die DVI-/HDMI-Spezifikation überhaupt "krumme" Wiederholraten vor?


    Gruß
    c0z

  • VGA an modernen TVs (TFTs etc) macht sowieso kaum mehr Sinn da hier wieder convertiert werden muss > Verluste. HDMI/DVI oder displayport wäre hier schon der sinnvollere
    Übertragungsstandart. Bei Röhren TVs / Monitore hingegen macht VGA Sinn. wie leicht sowas umzusetzen ist, steht auf einem anderen Blatt. Die Frage ist auch, welche Signale mir von
    vorn herein zur Verfügung stehen


    Vom technischen Standpunkt ist VGA obsolet und es macht keinen Sinn,
    ein digitales Signal erst analog zu wandeln (-> VGA) damit es im Display wieder digitalisiert wird.


    Das Problem ist: Ich habe schon mehrere Displays hier gehabt, die bei VGA den Takt der Quelle
    übernommen haben, aber bei HDMI/DVI eben nicht. Immer wenn das Display asynchron zum
    Quelltakt angestuert wird, ist ruckeln unvermeidbar.


    Davon abgesehen: VGA ist mit ein paar billigen Bauteilen implementiert!




    Quote from c0zmo

    Aber ist es nicht problematisch, dass die Video-Ausgabe eines PAL-C64 nicht richtig mit dem Soll übereinstimmt?


    Exakt so ist es!

  • Sieht denn die DVI-/HDMI-Spezifikation überhaupt "krumme" Wiederholraten vor?


    Nein, die dafür zuständigen Specs unterscheiden aber nicht mal zwischen 59.97Hz und 60.0Hz bei NTSC sondern verweisen darauf, dass die Frequenz um +/-0,5% abweichen darf.