Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 67 Antworten

letzter Beitrag von Tobias am

Upscaler-Idee - wuerde das funktionieren?

    Hi,


    mir kam gerade eine Idee fuer einen "Upscaler". Vorab: Ich habe von Hardware nicht viel Ahnung und koennte sowas nicht bauen. Aber vielleicht findet jemand die Idee ja gut und hat Bock das mal experimentell zu basteln.


    Wuerde es funktionieren, ein Geraet zu bauen, das man hinten an den C64 anschliesst, welches das S-Video-Signal erhaelt und absampled, z.B. in einem so grossen Takt dass er mindestens 8-16 Werte bekommt pro C64-Pixel, und aus diesen dann einen Durchschnitt errechnet, um zu ermitteln, um welche C64-Farbe es sich handelt, und anhand dieses Durchschnittswertes sich dann aus einer vorher festgelegten Palette einen Wert herausnimmt und diesen verwendet um damit ein sauberes HDMI-Bild zu generieren?


    Natuerlich waere das kein reiner Upscaler, sondern eher ein Bild-neu-synthetisierer, aber der Vorteil waere evtl. ein sehr sauberes Bild zu erhalten, ohne den C64 modifizieren zu muessen. Und man koennte sogar seine Lieblingspalette waehlen, oder vielleicht sogar einen Modus einbauen, der die Durchschnittswerte analysiert und daraus eine Palette generiert.


    Oder ist das C64-Signal dafuer bereits zu unsauber um sowas zu machen? Was denkt ihr?

    Ich hatte gedacht, über so ein Projekt mal gelesen zu haben.

    Nach etwas googeln bin ich auf folgendes für RGB-Quellen gestoßen:

    https://github.com/hoglet67/RGBtoHDMI

    Wahrscheinlich gibts noch andere Projekte.


    Am C128 80-Zeichen Ausgang würde das schon gehen, aber für SVideo als Quelle hab ich auf die Schnelle jetzt doch nix gefunden.

    Zitat von Goodwell

    Ich hatte gedacht, über so ein Projekt mal gelesen zu haben.

    Nach etwas googeln bin ich auf folgendes für RGB-Quellen gestoßen:

    https://github.com/hoglet67/RGBtoHDMI

    Wahrscheinlich gibts noch andere Projekte.

    Ich hab das mal überflogen, er verwendet einen Raspberry für die Umwandlung.


    Auf dieser Seite sieht man ein paar Screenshots:


    https://github.com/hoglet67/RG…iki/Gallery-of-Screencaps


    Die sehen (fast) so klar aus wie vom Emulator. Stellt sich halt dann doch unweigerlich die "Sinnfrage", warum nicht gleich einen Emulator (wie z.B. in Form vom TheC64, der 50 oder 60 Hz über HDMI ausgibt) nehmen, vor allem wenn sowieso ein Raspberry mitlaufen muss? ;)

    Zitat von Snoopy

    Stellt sich halt dann doch unweigerlich die "Sinnfrage", warum nicht gleich einen Emulator (wie z.B. in Form vom TheC64, der 50 oder 60 Hz über HDMI ausgibt) nehmen, vor allem wenn sowieso ein Raspberry mitlaufen muss? ;)

    Klar kann man die Sinnfrage stellen, aber ich denke es gibt einen Unterschied ob man den Pi als Video-Signal-Aufbereiter nimmt oder er gleich den ganzen Rechner emuliert ... das Sidekick benutzt auch einen Pi, werde ich deshalb einen Emu benutzen und auf meine original Hardware verzichten ? Sicher nicht ;)

    Zitat von Snoopy

    Die sehen (fast) so klar aus wie vom Emulator. Stellt sich halt dann doch unweigerlich die "Sinnfrage", warum nicht gleich einen Emulator (wie z.B. in Form vom TheC64, der 50 oder 60 Hz über HDMI ausgibt) nehmen, vor allem wenn sowieso ein Raspberry mitlaufen muss?

    Grundsätzlich eine berechtigte Frage.


    Ohne hier den Thread in die falsche Richtung entführen zu wollen, ist die Bildschirmausgabe alleine nicht das, was für viele ein 8-bit System ausmacht.

    Da gibts noch Tastatur, Sound, User-Port, Cassetten-Port, etc. Alle diese Punkte sprechen gegen Emulation.


    Der Pi liegt halt preislich noch dazu so, dass er gegenüber "echten" Hardware-Upscalern meist tatsächlich günstiger ist.

    Zitat von SkulleateR

    Klar kann man die Sinnfrage stellen, aber ich denke es gibt einen Unterschied ob man den Pi als Video-Signal-Aufbereiter nimmt oder er gleich den ganzen Rechner emuliert ... das Sidekick benutzt auch einen Pi, werde ich deshalb einen Emu benutzen und auf meine original Hardware verzichten ? Sicher nicht ;)

    Das würde nur wieder zu einer Frage führen, wo man die Grenze ziehen will. Die ist einfach individuell verschieden. ;)


    Einen Rechner neben dem C64 laufen zu lassen, der zig-mal leistungsfähiger als der C64 ist, damit ich das Bild des "echten" C64 auf einem supermodernen HDMI sehen kann, finde ich persönlich halt ein wenig "komisch". :)

    Zitat von Snoopy

    finde ich persönlich halt ein wenig "komisch".

    Ich widerspreche in keinster Weise.


    Bin gespannt, was sonst noch an Optionen hier geboten wird :-)

    Zitat von ZeHa

    Wuerde es funktionieren, ein Geraet zu bauen, das man hinten an den C64 anschliesst, welches das S-Video-Signal erhaelt und absampled, z.B. in einem so grossen Takt dass er mindestens 8-16 Werte bekommt pro C64-Pixel, und aus diesen dann einen Durchschnitt errechnet, um zu ermitteln, um welche C64-Farbe es sich handelt, und anhand dieses Durchschnittswertes sich dann aus einer vorher festgelegten Palette einen Wert herausnimmt und diesen verwendet um damit ein sauberes HDMI-Bild zu generieren?

    Ja, klar, so was würde funktionieren (funktionierte bei mir schon vor etlichen Jahren).


    Statt einen Pixel mehrfach zu sampeln reicht es schon, den C64-Clock-Takt zu sampeln und daraus

    das Timing für das Pixelsampling (einfach!) abzuleiten. Damit und einem passenden 2-Kanal-AD-Wandler

    hat man dann die RGB-Werte. Über 16 Comparatoren (z.B. im FPGA, je Farbe einer) hat man

    dann die Farbe, und über H-/V-Sync-Signale ein komplettes Abbild des C64-Videobilds.

    (Comparator: testet S-Video-Signalbereich gegen einen gegebenen C64-Farbwert, dafür gibt's

    verschiedene Ansätze)


    Je Monitor muss man dann nur noch ein neues Bild aufbauen. Mein Ansatz: je Monitor/Auflösung

    eigene Einstellungen => Bild ist perfekt in die Bildmatrix des Monitors eingemeisselt! Denn

    ohne perfekte Anpassung an die Matrix können sich z.B. mehrere Quell-Pixel ein und dasselbe

    Ziel-Pixel teilen, d.h. das Bild wirkt matschig. Perfekte Anpassung dagegen sorgt für immer

    gleichgrosse Quell-Ziel-Pixel, was aber bei einem grossen Monitor auch klotzig wirkt. Dazu kommen

    noch Anpassungen im Timing, Randabschneiden, etc.


    OT: das ganze lässt sich natürlich mit einem Amiga wesentlich einfacher machen, da die Farben

    bereits per Digital-RGB und Takt an einem Port ausgegeben werden.


    Das eigentliche Problem ist aber wie immer ein Board dafür zu entwickeln, und das wird idR teuer.

    Eines meiner Lieblingskanditaten ist das OSSC-Scaler-Board. Das hat aber leider keine digitalen

    Eingänge für Taktsignale etc., denn damit und der frei zugänglichen Dokumentation liesse sich

    wirklich so gut wie alles auf VGA/HDMI/etc. wandeln..schade! Oder aber man nimmt ein fertiges

    FPGA-Board mit HDMI/VGA-Ausgang und vlt. 30-50 Digital-IOs. Dazu eine kleine Platine mit

    AD-Wandler und passendem IO-Ausgangsdesign.


    Noch ein Wort zu fertigen Wandler: diese basieren auf Videochips, die Videosignale in digitale

    RGB- oÄ Formate wandeln. Hier ist das Wort Video entscheidend, den es sind keine Pixelchips

    (die es ausser selbstimplementiert nicht gibt). Ein Videochip kennt z.B. die Grenze zwischen

    2 Pixel nicht, was zu Matschigkeit führen kann, und es müssen im Nachhinein die Pixel durch

    erneutes Samplen extrahiert werden. Das ist zwar beim C64-Format nicht besonders schwer,

    kann aber trotzdem zu Artefakten kommen. Also besser schon an der Quelle (sprich S-Video-Signal)

    abtasten. Mein Ansatz Oben liefert somit eine perfekte Anpassung an die TFT-Matrix und eine

    perfekte Anpassung an die Farbwerte (bei alten Computer/Konsolen sind es ja nur sehr endlich

    viele Farben!).


    Ja ich hab auf RasPI basierende Upscaler für fast alle meine Retro Geräte.


    Angefangen hat das bei meinem BBC Master.

    Das Teil haben sie dann aufgebohrt für meinen Tandy CoCo-3.


    Funktioniert perfekt.



    Es hat mit Emulation nichts zu tun.

    Das Gerät bleibt dasselbe, es hat exakt dasselbe Verhalten.

    Aber man hat halt eine klare und gute Bildschirmdarstellung.


    Ich hab halt nur noch HDMI basierte Monitore.

    Und die üblichen Konverter nach HDMI kannst du halt praktisch nicht verwenden.

    Zitat von Snoopy

    Das würde nur wieder zu einer Frage führen, wo man die Grenze ziehen will. Die ist einfach individuell verschieden. ;)

    Ganz genau DAS ! Genauso kann man die Frage stellen, ab wann ist ein Pi denn ein Ersatz für den kompletten 8Bit Rechner ? Für mich z.B. ist ein PiZero mehr eine Art CoProzessor, ein Pi4 ein vollwertiger Computer ;)


    Aber das ist hier nicht das Thema ! Ich persönlich würde auch sagen das funktioniert bestimmt. Es gibt doch soweit ich weiss sogar eine Anpassung des RGB2HDMI Projekts für den C64 wo vorher noch ein YUV Signal erzeugt wird.


    Falls sich jemand des Projektes annimmt bleibt immer noch die Glaubensfrage : Welche Palette darf denn sein :roll: ?

    Zitat von Diddl

    Es hat mit Emulation nichts zu tun.

    Das Gerät bleibt dasselbe, es hat exakt dasselbe Verhalten.

    Aber man hat halt eine klare und gute Bildschirmdarstellung.

    "Das Bild wird vom Raspberry für meinen modernen HDMI-Monitor aufbereitet und die Programme ziehe statt von der Floppy von der SD-Karte. Aber ich bin nach wie vor 'original'!" ;)


    Es ist einfach weiterhin eine persönliche "Glaubenssache", ab wo man für sich die Grenze zieht.

    Zitat von SkulleateR

    Welche Palette darf denn sein :roll: ?

    Ja das ist richtig. :D


    Die original Video Hardware im C64 ist so grottenschlecht, dass keiner exakt sagen kann, welche Farben wirklich "original C64" sind.

    Es hat doch jeder auf seinem Monitor ein anderes Bild gehabt, mit derselben Software an seinem C64.


    Zum Glück kann man im RasPI einfach seine Lieblingspalette in einem Config File eingeben.

    So hat dann jeder seine persönliche Lieblings Preferenz.

    Nuja, wo soviel mit hunt the beam (oder wie heisst das) gearbeitet wird, ist jeder Upscaler gegenüber einem CRT im Nachteil.


    Es ist auf jeden Fall stets ein Unterschied zwischen 25 Vollbildern pro Sekunde oder 50 Halbbildern (die auch noch zeilenweise aufgebaut werden). In der Praxis heisst das, dass auf einem CRT eine Ausgabe, die erst fertig berechnet wurde, wenn der Beam oben schon gestartet ist, unten im selben Frame noch berücksichtigt werden könnte. Bei jedem De-Interlacer oder Upscaler kann das bestenfalls im nächsten oder gar im übernächsten Frame der Fall sein.


    Ein wirklich tolles Projekt wäre ein modernes Display, das das Bild zeilenweise und interlaced aufbaut. Das koennte dann wirklich nah am Original sein.


    Bei dem, was Liebhaber für CRTs ausgeben, könnte ich mit vorstellen, dass so ein modernes neues Display durchaus für einen angemessenen Preis vermarktet werdedn könnte...

    Zitat von FRauANtje

    Es ist auf jeden Fall stets ein Unterschied zwischen 25 Vollbildern pro Sekunde oder 50 Halbbildern (die auch noch zeilenweise aufgebaut werden). In der Praxis heisst das, dass auf einem CRT eine Ausgabe, die erst fertig berechnet wurde, wenn der Beam oben schon gestartet ist, unten im selben Frame noch berücksichtigt werden könnte. Bei jedem De-Interlacer oder Upscaler kann das bestenfalls im nächsten oder gar im übernächsten Frame der Fall sein.

    Nein, muss definitiv nicht: bei Zeilenverdopplern wird max. eine Zeile verzögert gezeichnet,

    mein Ansatz von Oben (bestimmt auch der RasPI-Ansatz) verzögert auch max. eine um Zeile.

    D.h. du hast eine Verzögerung von ca. 64 Mikrosekunden, merkt keine Sau.

    Jetzt kommt das Aber: beim TFT kommen so um die 1-4 Millisekunden Trägheit hinzu. Auch

    bei OLED bleibt's bei dieser Verzögerung. Einzig ein alter VGA-Monitor hat eine nicht

    wahrnehmbare Verzögerung.

    Vielen Dank schonmal für alle Antworten, werde ich später nochmal genauer durchlesen da ich gerade unterwegs bin.


    Was das Thema "da braucht man ja ein Raspberry Pi für" angeht - nur weil das in einem der Beispielprojekte gemacht wird, heißt das ja nicht automatisch, dass das so gemacht werden MUSS. Denkbar wäre ja auch etwas mit FPGA oder schlichtweg eine "echte" Schaltung. Aber ein Raspberry Pi eignet sich natürlich prima, um das Prinzip einfach mal auszutesten. Snoopy wenn Du Dir einen Upscaler im Laden kaufen würdest, wüsstest Du ja erstmal auch nicht was da drin nun exakt werkelt. Das kann von einer simplen Schaltung bis hin zu einem Mikroprozessor ja alles mögliche sein.

    Zeilen und Frames sind was Anderes...


    Du kannst per HDMI keine Zeilen an den Monitor übertragen sondern nur komplette Frames.


    Und das lässt sich mit den heute gebräuchlichen Monitoren auch nicht ändern. Nur mindern - man könnte zum Beispiel 200 komplette Frames pro Sekunde berechnen und an einen Monitor übergeben, der soviele Fullframes verarbeiten kann.


    Und je nach Game koennen ein oder zwei Frames (also zwei oder vier Halbbilder) schonmal über Erfolg oder Misserfolg entscheiden, aber das ist ein anderes Thema. Wenn in den oberen Zeilen das Bild noch gemalt wird, kann sich unten noch was um nen Pixel oder zwei verschieben. Das kannst Du mit Fullframes niemals so abbilden...

    Das U64 gibt auch ueber HDMI PAL-Frames aus, soweit ich weiss ohne Verzoegerung. Vielleicht erst den fertigen Frame, aber ich hatte mal mein U64 parallel an einem CRT (per S-Video) und an meinem Beamer (per HDMI) angeschlossen und es gab keinen Versatz.

    Zitat von ZeHa

    mindestens 8-16 Werte bekommt pro C64-Pixel

    Ich bin da bei Samplefrequenzen von 90-180 MHz. Wenn jedes Sample 3 Bytes liefert, sind wir bei 270-540 MByte / s. Ist spät, kann mich um 50% irren. ;-)


    Zitat von FRauANtje

    Ein wirklich tolles Projekt wäre ein modernes Display, das das Bild zeilenweise und interlaced aufbaut. Das koennte dann wirklich nah am Original sein.


    Bei dem, was Liebhaber für CRTs ausgeben, könnte ich mit vorstellen, dass so ein modernes neues Display durchaus für einen angemessenen Preis vermarktet werdedn könnte...

    Riecht nach 576 bis 1080 einzeiligen Displays im Formationsflug.

    Doch lieber neue CRTs herstellen? ;-)

    ius Okay, ich hatte da jetzt nicht nachgerechnet sondern dachte halt, weil die Pixel ja gerade am Rand auch recht unsauber sein koennen und ineinander verschwimmen koennen, dass es sicherer ist, wenn man sich einen Durchschnittswert aus mehreren Samples berechnet, aber vermutlich wird das wie Jotta sagt gar nicht unbedingt notwendig sein :)


    Jotta gibt es Deine Loesung irgendwo zu bestaunen? Oder hast Du das nur fuer Dich selbst gemacht bisher?

    Zitat von ZeHa

    Jotta gibt es Deine Loesung irgendwo zu bestaunen? Oder hast Du das nur fuer Dich selbst gemacht bisher?

    ..Tschuldigung, war am Wochenende sehr beschäftigt.

    Nein, fertig gibt's das nicht, wie viele meiner Projekte interessiert mich nur die Machbarkeit, ein Ansatz

    wird dabei schnell an einem Wochenende runtergeschrieben und implementiert. Dann vlt. noch ein

    Tag mit rumgespielt und dann den Stecker gezogen. Das ganzer hatte ich vor so 10-15 Jahren mal gemacht,

    deshalb erinnere ich mich an die damaligen Details nicht mehr so genau, nur das ich es auf meinem

    Oszi-FPGA-Board wegen der ADCs laufen lies (Welec2022a mit 2 Kanäle je 1GS). Ich habe gerade noch mal

    über die Implementierung nachgedacht, meine Lösung hatte glaube ich wegen der Begrenzung auf 2 Kanäle

    nur die Graustufen richtig erkannt.


    Das Prinzip liese sich aber auch auf RGB erweitern, siehe die Bilder im Anhang: zu sehen sind Aufnahmen

    eines 256er-Voxelspace, die C64-Farben als Pixel in den Raum reingezeichnet (inkl. 32 Pixel-Range). Es gibt

    nur 2 Farben, die sich "unbequem" nahe kommen, d.h. wo ein Vergleich etwas "feiner" sein muss. Im Anhang

    habe ich auch noch das Programm inkl. Voxeldaten, müsste eiglich auf Windows10 laufen (habe NVIDIA-Karte).

    Überträgt man das ganze auf ein RGB-Signal, dann kann man sich meinen Ansatz von Oben leicht vorstellen:

    Je Farbsignal 2 Komperatoren, alle 6 Zusammen ergeben dann eine Entscheidung über Farbgleichheit.


    C64RGB1.pngC64RGB2.pngC64RGB3.png


    C64YUV1.png


    Programm-Anleitung: (Achtung, schnell runtergenudelt + keinerlei Verantwortung für fehlerhaftes Verhalten!)

    - v: Demo-Voxelspace

    - f: File laden und anzeigen (evtl. mehrmals, da Prog fehlerhaft)

    - Mouse+LeftButton: Rotation

    - Mouse-Wheel: Voxel-Level (gezeichnet/nicht gezeichnete Voxel-Werte)



    Zitat von FRauANtje

    Zeilen und Frames sind was Anderes...

    Ja, habe ich auf mal von gehört .. ist das dein Ernst?

    Zitat von FRauANtje

    Du kannst per HDMI keine Zeilen an den Monitor übertragen sondern nur komplette Frames.

    Ich glaube, wir reden hier aneinander vorbei: ich steuere per FPGA einen HDMI-TX-Chip an (z.B. ADV7513

    auf einigen Terasic-Board, IT6613 auf dem OSSC etc.), da wird Pixel für Pixel übertragen. Und da eine

    C64-Zeile mehrere TFT-Zeilen sind, kommt es timingbedingt zu ein bit zwei Zeilen Verzögerung. Das merkt

    aber wirklich keine Sau, sind max. 0,2ms.