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

  • Thema abonniert :)

    Ich möchte mich aber auch der Meinung anschließen, daß VGA wenig Sinn macht. Ich habe zwar die aufgebrachten technischen Argumente verstandan, aber VGA ist im Aussterben. VGA Monitore zu finden die 50Hz können ist beine genauso schwer wie welche mit FBAS oder S-Video eingang. Also eine "tote Technologie" mit einem anderen zu ersetzen hilf nicht viel den ursprünglichen Problem zu lösen...

    Bezüglich wo man Signale abgreifen sollte ohne viel zu löten: Könnte Mann die Platine (oder irgendein Anschlusskabel) zwischen den Sockel und der VIC stecken? Oder, und das ist etwas komplizierter, aber vielleicht könnte Mann den VIC komplett loswerden und es im FPGA nachbauen?

    EDIT: OK. In zwichen ist mir eingefallen, daß der Chameleon ursprünglich auch so angefangen hat, und es dann recht kompliziert wurde... Also nehme ich an, daß es doch nicht so einfach ist. Schade. Es wäre schön gewesen wenn Jens den VIC teil des Chameleons in ein eigenständiges Produkt abspalten könnte...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bjavor ()

  • bjavor schrieb:

    Es wäre schön gewesen wenn Jens den VIC teil des Chameleons in ein eigenständiges Produkt abspalten könnte...
    Ich weiss nicht, wie das Cham das Video abgreift, aber IIRC hat Jens mal irgendwo was von Bus Snooping Techniken (am Expansionsport) geschrieben.
    Wie auch immer, ich glaube nicht, dass es im Interesse von Jens wäre, ein eigenständiges VGA Output Modul für den Expansionsport anzubieten, was sicher billiger sein müsste, um verkauft zu werden.

    Denn damit würde eines des wenigen hervorzuhebenden Argumente (die manche User hier vehement wiederholen) für das Cham64 ad absurdum geführt, weil man dann das Chameleon ja nicht mehr zwangsweise kaufen müsste, um VGA zu haben. VGA-Modul und ein billigeres SD2IEC oder U1541-II(+) würde genügen. :D
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • androSID schrieb:

    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
    Welche Monitore machen denn so einen Blödsinn? Hab ich zum Glück noch nicht erlebt. Muß sich ein HDMI-Eingang nicht ohnehin auf den externen Takt synchronisieren? Wo wäre da der Sinn, wenn das anschließend noch umgewandelt wird?
  • 4LEX schrieb:

    da HDMI als differernzielle datenübertragungstechnik für digitale signale standart ist, wird auch hier schon alleine durch das CDR (Clock Data Recovery) synchronisiert weren müssen.
    DVI/HDMI verwenden vier Diff-Paare, drei für die Pixeldaten (bei dVI R/G/B, bei HDMI je nach Format variabel) und eine für den Pixeltakt.

    Phasengleich schrieb:

    Ich dachte immer HDMI ist per Standard 50Hz. 60Hz wäre ja echt blöd, dann ruckeln ja so gut wie alle Videoquellen. Die meisten Filme sind doch meines Wissens 25FPS und nicht 30 oder 60. Ein Vielfaches von 25 ist immer zu begrüßen.
    Filme sind 24fps

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Geräte mit HDMI-Eingang müssen 50 Hz und 60 Hz annehmen. Dazu müssen die Auflösungen 720x480 (60Hz), 720x576 (50Hz), 1280x720p und 1920x1080i unterstützt werden. Das ist Mindestvoraussetzung, um HDMI überhaupt verbauen zu dürfen, soweit ich weiß. Leider ist es wohl keine Voraussetzung, daß die Geräte das dann auch unverändert so anzeigen müssen.
    Grundsätzlich ist HDMI sehr flexibel und kann durchaus viel mehr Auflösungen und Frequenzen übertragen, was aber im Ermessen der Geräte liegt, da auch drauf einzugehen.
  • LogicDeLuxe schrieb:

    Geräte mit HDMI-Eingang müssen 50 Hz und 60 Hz annehmen. Dazu müssen die Auflösungen 720x480 (60Hz), 720x576 (50Hz), 1280x720p und 1920x1080i unterstützt werden. Das ist Mindestvoraussetzung, um HDMI überhaupt verbauen zu dürfen, soweit ich weiß. Leider ist es wohl keine Voraussetzung, daß die Geräte das dann auch unverändert so anzeigen müssen.
    Grundsätzlich ist HDMI sehr flexibel und kann durchaus viel mehr Auflösungen und Frequenzen übertragen, was aber im Ermessen der Geräte liegt, da auch drauf einzugehen.
    Also wäre ein ruckelfreies Bild von S-Video des C64 auf HDMI möglich?
  • Natürlich wäre das möglich. Bei 720x576 bin ich mir nicht sicher. Aber in 720p und 1080p/i muß HDMI immer zwingend 50Hz ausgeben können, natürlich nur wenn der entsprechender Bildschirm das auch kann.

    edit: Ja, 720x576 geht auch in 50Hz. Allerdings ist das natürlich interpoliert und sieht mies aus. Geräte mit nativer 576p Ausgabe? Das können noch nur diese winzigen Displays sein. Unter 15 Zoll.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Retro-Nerd ()

  • Retro-Nerd schrieb:

    Natürlich wäre das möglich. Bei 720x576 bin ich mir nicht sicher. Aber in 720p und 1080p muß HDMI immer zwingend 50Hz ausgeben können, natürlich nur wenn der entsprechender Bildschirm das auch kann.
    720x576 ist praktisch immer 50 Hz. Diese Auflösung ist schließlich für PAL-Material gedacht.
    Beim C64 darf man aber nicht vergessen, daß er eben keine exakten 50 Hz ausgibt, sodaß manche Geräte dann aussteigen.

    Ein FPGA-VIC könnte die Frequenzen natürlich angleichen und sogar echte 720x576i mit exakt 50 Hz ausgeben. Da der VIC den Systemtakt bereit stellt, hat er dies in der Hand. In den meisten Fällen würde man diesen geringen Unterschied wohl auch nicht bemerken, aber wenn es um timing-kritische Anwendungen geht, kann sowas natürlich zu Problemen führen. Die bessere Lösung wäre daher immer ein flexiblen Bildschirm zu verwenden, der mit dem C64-timing klar kommt.
  • LogicDeLuxe schrieb:

    Retro-Nerd schrieb:

    Natürlich wäre das möglich. Bei 720x576 bin ich mir nicht sicher. Aber in 720p und 1080p muß HDMI immer zwingend 50Hz ausgeben können, natürlich nur wenn der entsprechender Bildschirm das auch kann.
    720x576 ist praktisch immer 50 Hz. Diese Auflösung ist schließlich für PAL-Material gedacht.Beim C64 darf man aber nicht vergessen, daß er eben keine exakten 50 Hz ausgibt, sodaß manche Geräte dann aussteigen.

    Ein FPGA-VIC könnte die Frequenzen natürlich angleichen und sogar echte 720x576i mit exakt 50 Hz ausgeben. Da der VIC den Systemtakt bereit stellt, hat er dies in der Hand. In den meisten Fällen würde man diesen geringen Unterschied wohl auch nicht bemerken, aber wenn es um timing-kritische Anwendungen geht, kann sowas natürlich zu Problemen führen. Die bessere Lösung wäre daher immer ein flexiblen Bildschirm zu verwenden, der mit dem C64-timing klar kommt.
    Also wenn du einen neuen VIC 3.0 mit HDMI fertig hast, ich nehme einen. :thumbsup:
    Immer eine RealPLA für euch im Ofen! :thumbsup:
  • Jotta schrieb:

    Freak schrieb:

    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. vergleichbareChips der Hersteller), die Wandeln ein Bild nahezu perfekt ein...

    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.
    Hat sich da gerade jemand für die Umsetzung empfohlen?
    :whistling:
    Chris
  • Freak schrieb:

    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.

    Jotta schrieb:

    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 mich die letzten Tage mal nach einem geeigneten Wandler umgesehen.

    Der von Dir @Jotta genannte ADV7180 ist ja noch gut per Hand lötbar und hat auch eine Menge Eingänge, so dass man mehrere Buchsen als Eingänge vorsehen könnte (FBAS, SVideo und 8pol. DIN für direkten C64-Anschluss). Habe mich auch nach Alternativen umgeschaut (z.B. ADV7181C und ADV7401), jedoch haben alle diese Wandler einen Nachteil: Die Unterabtastung des Chroma-Signals.

    Diese sogenannte 4:2:2-Wandlung erzeugt nur für jedes zweite Luma-Pixel eine Farbinformation. Das mag bei bewegten Videosequenzen nicht bemerkbar sein, wenn man jedoch ein Computerbild nach dem Standard digitalisiert, erhält man zwangsläufig Farbsäume und kein "Pixel-Perfect"-Bild. :(

    Hier gibt es nähere Infos: Chroma Subsampling. Auf der Seite sind auch die Farbsäume bei Farbübergängen gut sichtbar. Info gibt es auch in Deutsch, dann aber ohne Farbsaumbild: Farbunterabtastung

    Meine Suche nach geeigneten Wandlern für FBAS und SVideo nach 4:4:4 (also für jedes der 720 Pixel pro Zeile 720 Y-, 720 Cr- und 720 Cb-Werte) war leider erfolglos. Vielleicht gibt es auch keine, da für bewegte Bilder eine 4:2:2-Wandlung ja völlig ausreichend ist...

    Jetzt stelle ich mir die Frage, ob ein ADV7180 (oder eine seiner Alternativen) als Eingangs-IC ausreicht, oder ob ich dann immer mit Farbsäumen leben muss und praktisch nie eine perfekte Darstellung erreichen könnte...

    Gruß,
    Thomas