Hello, Guest the thread was called2.9k times and contains 15 replays

last post from gartenzwerg at the

Konverter von C128/VDC/RGBI zu DVI/HDMI relativ einfach?

  • Hi!


    Am Wochenende hatte ich eine spontane Eingebung, und ich würde gerne wissen was die Hardwaregurus dazu sagen.


    Das Problem: Am RGBI-Ausgang des 128ers kann man bekanntlich keine TFTs anschließen; zum einen wegen der digitalen Signalpegel und zum zweiten wegen der 15-kHz-Zeilenfrequenz.


    Die übliche Lösung: Mit ein paar Bauteilen wird das digitale RGBI-Signal zu einem analogen RGB-Signal gewandelt (optional mit dem von CGA übernommenen Dunkelgelb-zu-Braun-Fix), und anschließend gibt man dieses auf den RGB-Eingang einer SCART-Buchse oder in einen teuren (Amiga-)Scandoubler.


    Eigentlich müsste es doch aber auch so gehen: Man nimmt den 16.xx MHz-Pixeltakt des VDC, liest mit diesem Takt die vier RGBI-Leitungen und schreibt die Daten in einen Linebuffer. Ein zweiter Linebuffer wird mit der doppelten Geschwindigkeit ausgelesen und an einer DVI-Buchse ausgegeben. Mit jedem HSync werden die Buffer gewechselt.
    Mit anderen Worten: Man baut sich einen Scandoubler. Der Witz hierbei ist aber, dass man sich den ganzen analogen Kram sparen kann: Im Gegensatz zu einem echten RGB-Scandoubler wie am Amiga braucht man hier zum Speichern einer Zeile nur 4x1kBit! Erst beim Auslesen der Zeile würden die vier RGBI-Bits zu 24 RGB-Bits erweitert, wobei man dann auch gleich den Dunkelgelb-zu-Braun-Fix unterbringen könnte. Neben der ganzen Steuerlogik bräuchte man also zwei 4x1kBit-RAMs und einen 4-zu-24-Bit-Lookuptable (wobei sich letzterer aufgrund der beschränkten Palette stark reduzieren dürfte). Das müsste doch mit einem relativ winzigen FPGA möglich sein, oder?


    Problem Nummer 1:
    Der 16,xx-MHz-Pixeltakt liegt nicht an der RGBI-Buchse an, man müsste ihn also auf der Platine abgreifen (evtl. das ganze Projekt gleich als VDC-Adapterplatine ausführen, dann kann man auch gleich 64 KByte VDC-RAM unterbringen :)).


    Problem Nummer 2:
    Zum Auslesen muss man den Takt verdoppeln (PLL?); ich hab keine Ahnung wie aufwendig sowas ist.


    Problem Nummer 3:
    Wie man an Problem Nummer 2 schon erkennen kann, hab ich von Hardwaredesign keinen blassen Schimmer, es muss sich also ein Entwickler für dieses Projekt finden... :whistling:


    Was sagen die Profis? Geht das wirklich so "einfach" oder hab ich was Wichtiges übersehen?
    Falls sich jemand findet, der das für durchführbar hält und machen will: Für zwei Belegexemplare verzichte ich auf sämtliche Rechte an dieser Idee. :D

  • Am Wochenende hatte ich eine spontane Eingebung, und ich würde gerne wissen was die Hardwaregurus dazu sagen.


    Öhm... "Bitte mach das, dann fällt wieder was von meiner viel zu langen Projektideenliste weg" ;)


    Quote

    Das Problem: Am RGBI-Ausgang des 128ers kann man bekanntlich keine TFTs anschließen; zum einen wegen der digitalen Signalpegel und zum zweiten wegen der 15-kHz-Zeilenfrequenz.


    Kommt auf den TFT an - Fernseher sollten das Timing via SCART akzeptieren können und manche TFTs nehmen am VGA-Anschluss auch 15kHz-Signale an.


    Quote

    Die übliche Lösung: Mit ein paar Bauteilen wird das digitale RGBI-Signal zu einem analogen RGB-Signal gewandelt (optional mit dem von CGA übernommenen Dunkelgelb-zu-Braun-Fix), und anschließend gibt man dieses auf den RGB-Eingang einer SCART-Buchse oder in einen teuren (Amiga-)Scandoubler.


    Du könntest mal einen GBS-8200/8220 ausprobieren - kostet knapp 30 Euro via eBay. Es gibt deutlich bessere Upscaler, aber nicht zu diesem Preis. Nicht von der Angabe "CGA/EGA" verwirren lassen, die meinen damit nur die Signaltimings. Das Ding braucht tatsächlich analoges RGB, evtl. aber mit höherem Pegel als den normalen 0,7V Vpp aus dem Consumerbereich.


    Quote

    Eigentlich müsste es doch aber auch so gehen: Man nimmt den 16.xx MHz-Pixeltakt des VDC, liest mit diesem Takt die vier RGBI-Leitungen und schreibt die Daten in einen Linebuffer. Ein zweiter Linebuffer wird mit der doppelten Geschwindigkeit ausgelesen und an einer DVI-Buchse ausgegeben. Mit jeden HSync werden die Buffer gewechselt.


    DVI/HDMI ist prinzipiell mit den richtigen FPGAs machbar (z.B. Spartan 6), allerdings etwas aufwendig. Ausserdem wird das Timing des VDC möglicherweise etwas neben der HDMI-Spec liegen und dann muss man wieder hoffen, dass der Fernseher/Monitor es annimmt. Im Falle eines Fernsehers könnte man auch noch versuchen, statt eines 480p/576p-Signals einfach 240p/288p auszugeben um das Linedoubling wegzulassen. Das Timing dafür ist spezifiziert (und verwendet Pixeldoubling =) ), aber optional.


    Man kommt evtl. auch ohne den Pixeltakt aus: Wenn man im FPGA einen Takt generiert, der ein deutliches Vielfaches (z.B. 10x) des Pixeltakts ist könnte man damit das VDC-Signal überabtasten. Die Flanken der HSync-Signale sollten hoffentlich in fester Phasenbeziehung zum Takt der Ausgabepixel stehen, ab diesem Punkt zählt man mit dem hohen Takt durch und übernimmt nur jeden x-ten der übersampleten Pixel. Den Zähler legt man als Fixkommawert an, dadurch muss der "simulierte Pixeltakt" kein ganzzahliger Teil des Oversample-Takts mehr sein.


    Noch etwas einfacher könnte man es machen, wenn man statt eines Digitalausgans einen VGA-Ausgang vorsieht: Es reichen ein paar wenige Widerstände für einen diskreten DAC (zwei Bit pro Farbe, evtl. drei wenn man Braun will), viele Low-End-FPGA-Entwicklungsboards und IIRC auch das Chameleon machen genau sowas für 8 bit 12 Bit Farbtiefe. Man könnte sich dann wahrscheinlich auch die Pixeltaktrekonstruktion sparen, müsste aber etwas knobeln um die HSyncs sauber zu verdoppeln.


    Quote

    Das müsste doch mit einem relativ winzigen FPGA möglich sein, oder?


    Die Variante mit diskretem DAC und VGA-Ausgabe könnte man wahrscheinlich sogar aus einem Haufen 74xx-Logik und zwei SRAM-Bausteien konstruieren.


    Quote

    Zum Auslesen muss man den Takt verdoppeln (PLL?); ich hab keine Ahnung wie aufwendig sowas ist.


    Praktisch jeder FPGA hat heutzutage mehrere PLLs oder ähnliches für Taktgenerierung eingebaut, allerdings kommt nicht jeder mit gerade mal 16MHz Eingangstakt klar.

  • Erinnert mich irgendwie an die alten Scandoubler für den Amiga... Nur, die darauf verbauten speziellen RAMs (Linebuffer und Fieldbuffer) dürften nicht mehr zu bekommen sein.


    Das müsstest du also auch im FPGA integrieren.


    Öhm - ich dachte, das in Post #1 klar gemacht zu haben: der Unterschied zu einem Amiga-Scandoubler wäre der komplette Verzicht auf Analogtechnik, und dank RGBI bräuchte man lediglich 8 kBit RAM (beim von Unseen vorgeschlagenen Oversampling natürlich entsprechend mehr), was in halbwegs aktuelle FPGAs hineinpassen sollte. Und selbst wenn man externe SRAMs benutzt, dürfte der Hardwareaufwand bedeutend geringer sein als bei einem Analog-Scandoubler.


    Es fehlt nur noch ein Hardwareentwickler... :thumbsup:

  • und dank RGBI bräuchte man lediglich 8 kBit RAM (beim von Unseen vorgeschlagenen Oversampling natürlich entsprechend mehr), was in halbwegs aktuelle FPGAs hineinpassen sollte


    Schon der kleinste FPGA in der Spartan 6-Familie von Xilinx (XC6SLX4) hat 12 BlockRAMs mit jeweils 18 KBit Speicher. Wenn man noch simplere Chips will könnte man ein MachXO2 von Lattice nehmen, da müsste es tatsächlich der zweitkleinste Chip (XO2-640, 2 BlockRAMs a 9 kBit) werden weil der kleinste gar keine Block-RAMs hat. Mit den Lattice-Chips kenne ich mich nicht aus, aber beim Spartan 6 sind die Block-RAMs echte Dualport-Speicher (Lesen+Schreiben auf beiden Ports, unabhängige Takte) mit einer maximalen Taktfrequenz von 280 MHz - das sollte für diese Zwecke ja wohl reichen. =)


    Quote

    Es fehlt nur noch ein Hardwareentwickler...


    Es dürfte wohl eine ziemlich gute Idee sein, das erstmal mit einem FPGA-Eval-Board zu prototypen bevor man sich den ganzen Spass mit differenziellen Highspeed-Signalen (DVI) und vermutlich einer 4-Layer-Platine im eigenen Design antut.


  • Öhm - ich dachte, das in Post #1 klar gemacht zu haben: der Unterschied zu einem Amiga-Scandoubler wäre der komplette Verzicht auf Analogtechnik, und dank RGBI bräuchte man lediglich 8 kBit RAM (beim von Unseen vorgeschlagenen Oversampling natürlich entsprechend mehr), was in halbwegs aktuelle FPGAs hineinpassen sollte.


    Der DAC ist beim Amiga-Scandoubler nachgeschaltet und damit für die eigentliche Schaltung nicht relevant, die läuft komplett digital. AFAIK kann der VDC aber doch auch Interlace, oder? Wenn man also korrekt implementieren will braucht man neben den Linebuffern auch Framebuffer und die waren auf den Flickerfixern zwar die vom Gehäuse her kleineren RAMs aber hatten aber genug Kapazität ein komplettes Halbbild zu puffern.


    Quote


    Und selbst wenn man externe SRAMs benutzt, dürfte der Hardwareaufwand bedeutend geringer sein als bei einem Analog-Scandoubler.


    Soviel war da gar nicht drauf. Die Fieldbuffer auf den Flickerfixern waren übrigens keine SRAMs sondern DRAMs mit sehr speziellem Interface welches die Ansteuerung stark vereinfachte (Dual-Port, Adresszähler intern).


    Ein Problem hast du allerdings noch. Beim Amiga lag am Video-Slot ein Takt an den man für die PLL benutzen konnte. Am Ausgang des C128 ist das nicht der Fall, also wird die Schaltung intern einbebaut werden müssen.


  • Schon der kleinste FPGA in der Spartan 6-Familie von Xilinx (XC6SLX4) hat 12 BlockRAMs mit jeweils 18 KBit Speicher. Wenn man noch simplere Chips will könnte man ein MachXO2 von Lattice nehmen, da müsste es tatsächlich der zweitkleinste Chip (XO2-640, 2 BlockRAMs a 9 kBit) werden weil der kleinste gar keine Block-RAMs hat. Mit den Lattice-Chips kenne ich mich nicht aus, aber beim Spartan 6 sind die Block-RAMs echte Dualport-Speicher (Lesen+Schreiben auf beiden Ports, unabhängige Takte) mit einer maximalen Taktfrequenz von 280 MHz - das sollte für diese Zwecke ja wohl reichen. =)


    Hört sich an, als könntest du das... Die Atari-ST-Gemeinde wäre dir ewig dankbar, wenn du das mal für den ST umsetzen könntest, solch eine Box, umschaltbar für analog ST-LOW/MED (PAL) und dem monochromen (digitalen) High-Modus (70Hz), die auf der anderen Seite ein sauberes VGA-Signal (DVI/HDMI wäre auch nett) ausgibt. Hast du Lust dazu? Denn das wäre eine echte Marktlücke. Und wenn du dabei bist, ein umschaltbarer VGA/ECL to VGA-Adapter (also der je nach Schalterstellung entweder VGA durchreicht, oder ECL in ein VGA-Signal mit 1280x960 wandelt (oder gar oben und unten noch ein paar leere Pixel "anhängt" um auf für moderne Monitor leichter darzustellende 1280x1024 Pixel zu kommen, oder gleich ein DVI/HDMI-Signal draus macht), wäre für die Atari-TT-Besitzer auch was schönes, da gibts zwar im atari-forum.com das Projekt von Tenox, nicht VGA/ECL-umschaltbar (und nicht auf 1280x1024 erweitert), aber an das ist so schwer/teuer ranzukommen, weil Tenox in den USA sitzt.


    Ruhm und Ehre wäre dir gewiss!

  • AFAIK kann der VDC aber doch auch Interlace, oder? Wenn man also korrekt implementieren will [...]

    Ja, der VDC kann Interlace. Und Du hast natürlich Recht, dass in dem Fall ein De-Interlacing "korrekt" wäre. Mir wäre diese Funktionalität allerdings nicht wichtig genug, um deshalb den Hardwareaufwand hochzuschrauben. Auch im Interlace-Modus würde die in Post #1 skizzierte simple Hardware noch ein Bild auf ein TFT bringen - nur wäre das Bild dann eben auch am TFT noch interlaced, würde also flimmern. Ich könnte damit leben. :D

    Hört sich an, als könntest du das... Die Atari-ST-Gemeinde wäre dir ewig dankbar, wenn du das mal für den ST umsetzen könntest, solch eine Box, umschaltbar für analog ST-LOW/MED (PAL) und dem monochromen (digitalen) High-Modus (70Hz), die auf der anderen Seite ein sauberes VGA-Signal ausgibt.

    ...wobei man den monochromen High-Modus einfach nur durchreichen muss - das habe sogar ich schon mit einem Stecker und drei Dioden zusammengebastelt hinbekommen.

  • ...wobei man den monochromen High-Modus einfach nur durchreichen muss - das habe sogar ich schon mit einem Stecker und drei Dioden zusammengebastelt hinbekommen.


    Du mischst das Monochrom auf die drei Farbsignale per Dioden? Was für Dioden hast du da denn verwendet? Ich hab das nämlich auch schon ausprobiert und bekomme da übelste Farbverschiebungen.

  • Die Atari-ST-Gemeinde wäre dir ewig dankbar, wenn du das mal für den ST umsetzen könntest, solch eine Box, umschaltbar für analog ST-LOW/MED (PAL) und dem monochromen (digitalen) High-Modus (70Hz), die auf der anderen Seite ein sauberes VGA-Signal (DVI/HDMI wäre auch nett) ausgibt.


    So, nach Ausleihen eines Mega ST2 und ein paar Experiementen sowie Blicken in den Schaltplan: Vergiss es, das ist nichts für mich. Wenn ich die Schaltpläne richtig interpretiere dann erzeugen zwar manche Modelle das Videosignal mit einem einfachen Widerstands-DAC, so dass man die digitalen Pixel noch leicht abgreifen könnte, andere aber spucken direkt ein Analogsignal aus dem Shifter aus. Um bei letzteren das Bild weiterzuverarbeiten, müsste man entweder diese Analogsignale wieder digitalisieren oder den Shifter komplett nachbilden - beides ein ziemlicher Aufwand, der sich IMHO nicht lohnt. Für die Modelle mit Widerstands-DAC könnte man noch über eine interne Lösung nachdenken, aber da weiss ich nicht wie verbreitet die sind.


    Quote

    Denn das wäre eine echte Marktlücke.


    Es gibt doch schon diverse Videoscaler von sehr billig bis sehr teuer, die analoge RGB-Signale annehmen und daraus Component/VGA/DVI/HDMI machen - warum nicht einen davon nehmen? Zugegebenermassen sind die 30-Euro-Lösungen nicht unbedingt optimal (GBS-8220):
    desktop-gbs-fixed.gif
    Andererseits wäre eine FPGA-Lösung mit Sicherheit teurer, wenn auch vermutlich günstiger als ein XRGB Mini:
    desktop-mini.gif
    Aber insbesondere wenn man den Gebrauchtmarkt einbezieht sollte sich eine Lösung dazwischen finden lassen. Für Low/Medium-Res ist das Problem im Prinzip das gleiche, das auch bei diversen alten Spielkonsolen vorliegt (240p/288p) und zu dem einige Leute ziemlich viel Text ins Netz gestellt haben. Hires-Mono geht eh direkt an vielen Monitoren und zumindest in manche Scaler könnte man es auch reinschieben (der GBS-8220 mags nicht, der XRGB Mini hat keine Probleme).


    Ich habe mal zwei Demos durch beide Scaler geschoben und hier abgekippt - beim GBS gabs aus bisher ungeklärten Gründen weisse Punkte im Bild, das könnte evtl. ein Defekt an meiner etwas verbastelten Platine sein. Bei der Mini-Version von Oddstuff ist die Bildqualität nicht ganz optimal, da die Demo an vielen Stellen 50Hz-Flackereffekte verwendet und das für Videocodecs ziemlich ungünstig ist. Ich hatte kurz erwogen die Videos einfach auf Youtube zu stellen, aber Google konvertiert wohl immer noch zwangsweise auf 30fps oder weniger runter. (GBS-8220 auf 800x600, XRGB Mini auf 576p50, Aufzeichnung via Startech PEXHDCAP mit Lossless-Codec, konvertiert mit x264 "constant quality" 23 für alles ausser oddstuff-mini, letzteres mit cq 21 weil die Flackereffekte sonst zu stark verschmierten)



    Aufnahmen vom C128-VDC reiche ich nach wenn ich irgendwas gebastelt habe um dessen Digital-RGBI auf analoges RGBS/RGBHV zu adaptieren.

  • Den Schaltplan für den RGBI digital -> RGB analog - Konverter in Reply #57 dort hast Du schon gesehen?


    Schaltpläne gibts im Netz genug - insbesondere auch aus anderen Quellen bei denen man sich nicht erst registrieren muss - aber auch wenn man den ausgedruckten Schaltplan noch so clever faltet um ihn in die RGBI-Buchse zu stecken gibts das Bild erst wenn man ein passendes Kabel bastelt. =)

  • Das Wesentliche wurde ja schon Oben von Unseen und Sauhund vorgeschlagen:
    Die (implizite) Pixelclock 16.xx und die Signale oversamplen, und zwar so, das
    z.B. die ersten Pixel am Anfang einer Zeile frühstens bei ca. 1/4 der Pixeldauer
    und die letzten Pixel bei spätestens 3/4 der Pixeldauer abgegriffen werden (dazwischen
    dann linear zwischen 1/4 und 3/4). Das kann mit einer relativ einfachen Zähner/Sampler-
    Schaltung realisiert werden. Zu Beginn der Zeile (HSYNC) wird der Zähler resettet.


    Interlace: darum muss man sich keine Sorgen machen, denn der C64/C128 spucken
    je 25Hz-Bild zwei Halbbilder aus (auch im 80er-Modus). Es müssen nur diese Hablbilder
    angezeigt werden.
    Beim Amiga in hochauflösenden Modi (>=400 Zeilen) ist das natürlich anders. Bei
    <300Zeilen sind beide Halbbilder wie beim C64 "identisch" (falls sie nicht in der
    Zwischenzeit geändert wurden).


    Der Scandoubler (ich bevorzuge für 1024x768 Scantrippler!!) ist eigentlich auch
    relativ einfach aufgebaut. Externen SRAM braucht's nicht, die internen RAMs reichen
    mehr als locker aus.


    Die Ausgabe der Pixel kann man dann im "eigenen" Clockraum, z.B. mit 25MHz oÄ
    machen. Dazu muss nur die VGA-Zeilenlänge entsprechend angepasst werden
    (auch kein grösseres Problem, nur ein wenig Rechnerei und Probieren).


    Und: Statt DVI/HDMI (brauchen idR eigenen Chip) reicht für die C64/C128/Amiga-
    Auflösung locker VGA-Analog, z.B. per R2R-Netzwerk. Beispiele inkl. Widerstandswerte
    gibts im Netz zu Hauf.


    Grob nach der Anleitung habe ich mal meinen A500 an meinen TFT angeschlossen.
    Das Bild war wirklich bombig, keine Artefakte, keine unterschiedliche Zeichenbreiten
    etc. Allerdings muss man für eine pixelexakte Ansteuerung des TFT das Design
    für jeden TFT individuel gestalten.

  • Also einige Monitore machen auch die niedrigere HSync-Frequenz mit, z.B. mein Dell Monitor. Habe es eben mal auf einem Breadboard aufgebaut:


    http://www.frank-buss.de/c128/vdc/index.html


    Das einzige Schönheitsproblem ist die falsche braune Farbe, da die eine Sonderbehandlung braucht, aber sieht sonst recht brauchbar aus. Ich werde am besten mal bei Gelegenheit dazu eine Platine entwerfen.