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

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.

Ja ein Indi für den 64er...

Ist nur die Frage wo man die Signale überall abgreifen muß.

Wenn das 10 Strippen oder mehr sind...wird es für die meisten uninteressant sein.

Zitat von Freak

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

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

Ist meine Idee so abwägig?

Prinzipiell nicht

Zitat

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.

Zitat

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.

Zitat von oobdoo

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.

Zitat von Phasengleich

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

PAL scheint wohl noch nicht tot genug zu sein

Zitat von 4LEX

PAL scheint wohl noch nicht tot genug zu sein

solange der C64 PAL ausgibt ...NÖÖÖÖ

Zitat von Freak

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.

Zitat von syshack

Macht im Jahre 2017 noch auf VGA-only setzen noch Sinn?

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

Zitat von androSID

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.

Zitat von syshack

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

Zitat von androSID

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

Zitat von syshack

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

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

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

Zitat von 4LEX

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!

Zitat von c0zmo

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

Exakt so ist es!

Zitat von c0zmo

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.