Hello, Guest the thread was called7k times and contains 116 replays

last post from PiCiJi at the

Denise 1.0.x Emulator

  • letzter Zwischenbericht:


    crt emulation mittels Cpu (fertig)

    - 8 Modes: pal/ntsc palette/spektrum crt an/aus

    Jeder Modus hat seine eigene Speicherung. Somit kann man schnell umschalten ohne alle Slider wieder neu anpassen zu müssen.

    - pal delay line (Farbmischung zweier Zeilen)

    - Hanover bars

    - chroma subsampling (mehrere Pixel sind ineinander gemixt)

    - rf Modulation (Helligkeit steigt / fällt nicht innerhalb eines Pixels )

    - Scanlines

    - in extra thread ausführbar (somit kein Geschwindigkeitsverlust wenn Cpu genug freie Cores hat)


    crt emulation mittels Gpu GLSL Shader ( fast fertig)

    - alles wie bei Cpu

    - verbessertes chroma subsampling -> pal/ntsc signal bandwidth emulation mittels FIR Lowpass Filter

    - Luminanz / Chrominanz Rauschen

    - radiale Verzehrung

    - VICII Luminanz Glitches (BA, AEC, RAS, CAS, PHI0) http://hitmen.c02.at/temp/palstuff/


    Es fehlen noch der Bloom Effekt und Lochmaske Emulation: Aperture und Shadow Mask.

    Externe Shader können mit internen kombiniert werden.

    Shader wie Lottes / Trinitron kümmern sich nicht um Pal Signal Emulation sondern

    vielmehr um die Struktur der Röhre wie Bloom und Lochmaske / Phosphor Effekte.

    Ich schätze mit etwas Anpassung externer Shader könnte man beide Welten gut kombinieren.

    Jetzt bin ich eine Woche unterwegs und dann hoffe ich Ende August / Anfang September auf ein release.

  • 1.0.5

    https://sourceforge.net/projects/deniseemu/files/v%201.0.5/

    -----

    [drag'n'drop]

    Es ist verfügbar im Firmware und Laufwerke Fenster oder direkt auf dem Hauptfenster.

    Zieht man eine Datei auf das Hauptfenster und ist die Emulation ausgeschalten, wird das Abbild

    in das entsprechende Laufwerk (Diskette, Kasette, Modul, Prg) eingelegt und gestartet.

    Das 'Load' Kommando wird ausgeführt und abschließend ein 'Run' getriggert.

    Ist die Emulation bereits eingeschalten, wird nur das Abbild eingelegt und das entsprechende Laufwerke Fenster angezeigt.

    Die Emulation wird jedoch nicht neu gestartet. Es könnte sich ja um einen Disketten/Kasetten Wechsel handeln.

    Unter Einstellungen kann dieses Verhalten derart geändert werden, das die Emulation immer neu startet.

    Möchte man nur die Dateien einlegen, sollten diese direkt auf die jeweiligen Eingabe Boxen gezogen werden.

    Dies löst in keinen Fall einen Power/Reset Zyklus aus.

    In den Eingabe Boxen selber kann nicht geschrieben werden, damit nicht ausversehen Pfade verfälscht werden.

    Per Drag'n'Drop können auch Archive verwendet werden. Enthält das Archiv nur eine Datei wird diese automatisch verwendet.

    Sollten es mehrere sein, erscheint eine Tree View zwecks Auswahl. Generell gilt für Dateien aus Archiven, das diese nur

    schreibgeschützt verwendet werden können. Nach einem Neustart des Emulators werden in Archiven zugewiesene Dateien

    wiedergefunden.


    [Spielstände]

    Datei Pfade der verwendeten Firmware werden jetzt mit gespeichert. Beim Laden des Spielstandes wird geschaut, ob die entsprechende

    Firmware bereits eingelegt ist. Andernfalls wird dies getan ohne die aktuell Angezeigte zu überschreiben. Bei einem

    Reset wird dann wieder die Aktuelle verwendet. Sollten die Firmware Pfade im Spielstand ungültig sein, wird über eine

    Fehlermeldung informiert und der Spielstand mit der aktuellen Firmware geladen.

    Warum ist das Speichern der Firmware Pfade wichtig ?

    Wird z.B. ein Spielstand beim Laden einer Disk mit aktiviertem Jiffy Dos generiert und dieser später mit der standard Firmware

    geladen, knallt es natürlich.

    Aufgrund von Änderungen können keine Spielstände, generiert mit der Vorgänger Version von Denise, in der Aktuellen

    verwendet werden. Es wird durch eine entsprechende Fehlermeldung abgewiesen.


    [Firmware]

    Nun können 2 zusätzliche Konfigurationen vorbereitet werden. Per Radio Button kann schnell zwischen den

    einzelnen Konfigurationen gewechselt werden. Das erspart das lästige Neu Einlegen einzelner Dateien.

    Z.b. kann man eine Konfiguration für Jiffy Dos erstellen. Hierbei reicht es aus Kernal und Floppy Firmware

    vorzubereiten. Char und Basic müssen nicht zugewiesen sein. Es werden dann automatisch die standard roms verwendet.

    Da einige user darüber gestolpert sind, ist Firmware im laufenden Betrieb nicht mehr ausgegraut. Neu eingelegte Firmware

    wird dann beim nächsten Power/Reset angewendet.


    [Eingabe Zuweisung]

    Wird der Emulator das erste Mal gestartet, heißt es ist noch keine settings.ini angelegt, versucht er die im OS

    hinterlegte Sprache zu erkennen und lädt dann die entsprechende Übersetzung und weist das entsprechende Tastatur Layout zu.

    Zudem werden alle Eingabegeräte mit einer Standard Belegung versehen. Der Joypad z.B. wird mit den Richtungs Tasten der Tastatur

    vorbelegt.

    Belegt ein am Control Port eingestöpseltes Gerät die gleichen Eingabe Elemente wie die Tastatur werden diese Elemente

    für die Tastatur abgeschalten ohne diese aus der Zuweisungsliste zu entfernen. Wird das Gerät ausgestöpselt oder die Zuweisung

    derart angepasst, das keine Doppel Belegung mehr auftritt, werden die jeweiligen Eingabe Elemente der Tastatur wieder aktiviert.

    Dies geschieht völlig automatisch und man muss nicht befürchten das Zuweisungen verschwinden. Dies verhindert das z.B. bei einem

    Spiel der C64 eine gedrückte Richtungs Taste nicht über Tastatur und Control Port empfängt.


    Ich habe einen weiteren Freiheitsgrad hinzugefügt. Für jedes Eingabe Element steht ab sofort eine alternative Belegung

    zur Verfügung. Ebenso können hierbei mehrere Einzel Elemente zugewiesen werden, welche und/oder verbunden sind.


    Beispiele

    ---------

    Spielstand speichern

    Belegung 1: Alt und F5

    Belegung 2: Joypad Schultertaste oder Ziffernblock Taste


    C64 Eingabeaufforderung: Stern Taste drücken

    Belegung 1: shift (links) und Plus

    Belegung 2: shift (rechts) und Plus


    C64 Eingabeaufforderung: Piktogramme der Stern Taste ausgeben

    Auf dem c64 ist die Sterntaste eine Primär Belegung. Mittels gedrückter shift Taste wird ein Piktogram ausgelöst,

    mittels gedrückter Commodore Taste das jeweils 2. Piktogram.


    Auf einer PC Tastatur ist es eine Sekundär Belegung der Plus Taste. Die shift Taste ist also bereits vergeben

    und kann keine Piktogramme mehr auslösen. Die der Commodore Taste zugwiesene Taste würde das 2. Piktogram der

    Plus Taste, jedoch nicht der Stern Taste auslösen.


    Belegung 1: shift ( links oder rechts ) und Plus

    Belegung 2: irgend eine freie Taste um mit Shift/Commodore Tasten Piktogramme zu erstellen.


    Die automatische Zuweisung wurde derart überarbeitet, das eine 2. Belegung mit der linken Shift Taste erscheint. (wenn sinnvoll)

    Wer die fehlenden Piktogramme (siehe Beispiel 3) benötigt, muss eine Belegung überschreiben. Da es sehr individuell ist, würde

    ich es nicht vorbelegen.


    Artefakte bei Semikolon

    -----------------------

    Hält man in der C64 Eingabeaufforderung die linke Shift Taste gedrückt und drückt zudem die Komma Taste erscheint selten

    mal eine eckige Klammer anstatt dem erwarteten Semikolon.

    Es klingt wie eine Schutzbehauptung aber das ist kein Emulationsfehler. (auch in Vice zu beobachten)

    Auf einer C64 Tastatur ist das Semikolon eine separate Taste. Auf dem deutschen Tastatur Layout ist es eine Sekundär Funktion.

    Wird die linke Shift Taste des C64 ebenso mit der linken Shift Taste der Tastatur belegt, passiert Folgendes beim Drücken beider Tasten.

    Der C64 empfängt die gedrückte Shift Taste. Es passiert erstmal nix. Zudem wird nun die Komma Taste gedrückt. Der Eingabe Manager

    übermittelt dem C64 die gedrückte Semikolon Taste, nicht mehr jedoch die gedrückte Shift Taste. Der C64 Kernal registriert

    die gedrückte Shift Taste und im nächsten Moment den Wechsel zur Semikolon Taste. Je nachdem wann er checkt, kommt er zu dem

    Schluß das beide Tasten zugleich gedrückt sind und stellt dann das Piktogramm dar.

    Eine Möglichkeit das Problem zu beseitigen, ist es entweder Semikolon oder links Shift auf eine freie Taste zu legen.


    Wechsel des Eingabe Treiber

    ---------------------------

    Beim Wechsel von Eingabe Treibern wurden mitunter Zuweisungen für Maus und Joypad entfernt, da die Treiber unterschiedliche Id's

    für die Geräte vergeben. Dies wird jetzt berücksichtigt. Dadurch sollten keine Zuweisungen beim Wechsel mehr verschwinden.

    Unter Umständen können jedoch Fehlzuweisungen bei Joypads bestehen, z.B. bei mehreren Joypads des selben Types, wenn die Treiber

    die angeschlossenen Geräte in unterschiedlicher Reihenfolge einlesen. Dann wären beim Treiber Wechsel Joypad 1 und 2 getauscht.

    Joypad Treiber sind hot plug fähig.


    weitere Änderungen

    ------------------

    Im Tab Disketten Laufwerke werden jetzt nur so viele Laufwerke gelistet, wie aktuell unter Systemverwaltung angegeben.

    Dadurch steht mehr Platz für die Auflistung des Disketteninhaltes zur Verfügung.

    Ich habe die Rechtschreibkorrekturen von Arndt eingepflegt. Eine Sache ist mir dabei für folgende Einträge aufgefallen.


    blank_memory_image = neues Speicherabbild auswählen ...

    blank_disk_image = leeres Diskettenabbild auswählen ...

    blank_tape_image = leeres Kassettenabbild auswählen ...


    Die Übersetzungsschlüssel sind dynamisch generiert. Für jedes Laufwerk besteht die Möglichkeit ein leeres Medium zu erstellen.

    Ausnahme bildet hierbei das 'memory' Laufwerk für PRG files, wo keine leeren Medien erstellt werden, sondern das aktuelle

    Programm aus dem C64 Speicher in eine prg Datei kopiert wird. Der Übersetzungsschlüssel ist unter diesem Hintergrund irreführend.

    Das muss ich in der Anwendung erst heraustrennen.


    Commandline Support

    -------------------

    Die Reihenfolge von Image Pfaden und Parameter spielt keine Rolle. Image Pfade werden ohne einleitende Parameter hinzugefügt.


    erlaubte Parameter:


    -vic-6569R3

    pal automatisch aktiv


    -vic-8565

    pal automatisch aktiv


    -vic-6567R8

    ntsc automatisch aktiv


    -vic-8562

    ntsc automatisch aktiv


    -sid-6581

    -sid-8580


    -cia-6526a

    neue Cias


    -cia-6526


    -debugcart

    für Vice Testbench. Alle Images werden vorher ausgeworfen, so das nur die per Command Line eingelegten aktiv sind.

    Cpu Killer Features werden deaktiviert. multiple Abbilder sind möglich. Manche Test brauchen ein prg und ein d64.


    -limitcycles %

    automatisches Beenden nach Anzahl Zyklen, wird jedoch nur einmal pro frame geprüft. Emulator Geschwindigkeit

    ist entsprechend der Sync Optionen.


    -no-driver

    Video, Audio, Input Treiber sind deaktiviert. Emulator läuft mit Max Speed, da sync Optionen nicht greifen.

    sinnvoll für automatisierte tests


    -no-gui

    aktiviert -no-driver, GUI Schicht läuft im dummy Modus. (keine Fenster, Widgets)

    Hier ist ein Wort der Warnung angebracht. Wenn kein -limitcycles oder -debugcart in Verwendung ist,

    läßt sich der Prozess nur noch im Task Manager beenden.


    ---------

    Beispiele

    ---------

    - Windows

    START /wait Denise.exe -debugcart -no-gui D:\c64\testprogs\drive\skew\skew.g64 D:\c64\testprogs\drive\skew\skew1.prg

    Return Code: echo %errorlevel%


    - OSX

    Denise.app/Contents/MacOS/Denise -debugcart -limitcycles 20000000 -no-gui ~/Emulation/testbench/skew.g64 ~/Emulation/testbench/skew1.prg

    Return Code: echo $?

    Hinweis: nicht den app container mittels open -W -a Denise --args starten. In dem Fall

    läßt sich der Return Code nicht raushangeln.


    - Linux

    ./Denise -debugcart -limitcycles 20000000 -no-gui ~/Emulation/testbench/skew.g64 ~/Emulation/testbench/skew1.prg

    Return Code: echo $?



    Video

    -----

    Grundsätzlich stehen 12 Basis Modes zur Verfügung, welche sich aus 3 Entscheidungen ergeben.

    1. Palette oder Farbspektrum

    2. PAL oder NTSC

    3. CRT: AUS/CPU/GPU


    Jeder Modus speichert seine eigene Konfiguration, heißt die Slider Einstellungen werden gemerkt wenn der Modus gewechselt wird. Beim Modus Wechsel wird die aktuelle Konfiguration geladen und die Slider entsprechend angepasst.

    Der Sinn des Ganzen ist es lästige Neu Anpassungen zu verhindern, wenn z.B. zwischen Palette und Farbspektrum oder PAL und NTSC gewechselt wird und dafür unterschiedliche Einstellungen verwendet werden.

    Mittels der Schaltfläche 'Reset' werden alle relevanten Slider des gerade ausgewählten Modus zurück gesetzt.


    Intern werden die Farben nicht als RGB verarbeitet, sondern YUV (PAL) bzw. YIQ (NTSC) encoded.

    Ausnahme hierbei ist: Palette an, CRT aus. Hierbei gehen die RGB Farben der Palette direkt an den Video Treiber.

    Im Gegensatz zu RGB werden bei YUV/YIQ die Helligkeit (Luminanz / Luma / Y) und Farbigkeit (Chrominanz / Chroma / UV(pal) / IQ(ntsc) ) voneinander getrennt.

    Luma ist das Schwarz/Weiß Signal. Verschiedene Spannungen dieser Leitung stehen für die Graustufen. Zudem ist es allein für die Bildschärfe verantwortlich. Chroma hat auf die Bildschärfe keinen Einfluß.

    Chroma ist das Farbsignal und wird mittels UV / IQ Koordinaten im Farbkreis beschrieben. Für NTSC ist das Koordinatensystem 33° gedreht.

    Beim C64 verlassen alle Farben gleich gesättigt das Gerät, heißt der Radius aller UV Koordinaten ist gleich. Somit reicht es aus,

    das der VIC-II neben dem Luminanz Signal nur den Winkel auf dem Farbkreis in Form einer Spannung ausgibt.


    Palette

    -------

    In der linken Ansicht sind initial alle Standard Paletten auswählbar. Diese können nicht verändert werden. Die Video Emulation verwendet die ausgewählte Palette.

    Durch die 'Erstellen' Schaltfläche wird die ausgewählte Palette in eine neue kopiert, welche sich nun bearbeiten lässt. Klickt nun einfach auf die Farbe oder den Hex Code.

    Entweder wird der Hex Code manuell überschrieben oder die 3 Farbkanäle per Slider angepasst. Läuft der Emulator sind alle Änderungen sofort sichtbar.

    Das gilt aber nur, wenn der Emu bei Fokus Verlust nicht pausiert wird, siehe globale Einstellungen. Über die Schatfläche 'Alle Änderungen speichern' werden sofort alle Anpassungen in eine separate Datei abgelegt.

    Alternativ werden die Änderungen beim Beenden des Emulators gespeichert, solange die Checkbox 'Beim Beenden speichern' nicht deaktiviert ist.

    Die Änderungen sofort zu speichern, schützt vor Datenverlust bei einem unerwarteten Absturz des Emulators.


    Farbspektrum

    ------------

    Die Grundlagen dafür sind vollständig von Pepto's neuer Colodore Variante übernommen.

    Hier beschreibt er die Zusammenhänge: https://www.pepto.de/projects/colorvic/

    Sind die Slider für Phase, Gamma, Kontrast, Sättigung und Helligkeit in der Standard Einstellung, wie nach einem 'Reset', entspricht dies exakt der Colodore Palette.

    Es gibt einige Gründe das Farbspektrum einer Palette vorzuziehen.

    Alle Farben sind immer nach den gleichen Gesetzmäßigkeiten erstellt. Z.B. die beiden Blau Töne auf dem C64 Start Bildschirm haben das gleiche Chroma aber unterschiedliches Luma.

    Verwendet man eine RGB Palette muss dies beim Zurück Rechnen der Farben nicht unbedingt stimmen.

    Außerdem wird berücksichtigt, das das PAL CRT Gamma bei 2.8 liegt. Zudem wird berücksichtigt, das VIC-II Chips nur 9 Luminanzen, ältere Chips sogar nur 5, unterscheiden.

    Dies läßt sich unter 'neuere VIC-II (9 Luminanzen)' umstellen. Bei Verwendung einer RGB Palette ist diese Option natürlich deaktiviert. Ebenso 'Phase' ist nur für Farbspektrum aktiv.

    Dies verschiebt den Startpunkt für die Farbspektrum Berechnung auf dem Farbkreis und soll somit verschiedene VIC-II Fabrikate simulieren. Natürlich sind nur einige wenige Grad realistisch.

    Grundsätzlich haben die meisten Slider einen deutlich zu hohen Wirkungsbereich. Die maximale Toleranz ist jedoch sehr subjektiv.


    Sättigung

    ---------

    Die Werkseinstellung :-) ist für PAL etwas höher um die später beschriebene Entsättigung auszugleichen.


    CRT Emulation (CPU oder GPU)

    ----------------------------

    Grundsätzlich gilt für alle Slider Funktionen, welchen eine Checkbox voran gestellt ist, das diese schnell aktiviert bzw. deaktiviert werden können. Die hat den Vorteil, das der Slider nicht auf 0

    gezogen werden muss und später, wenn wieder benötigt, auf den ursprünglichen Wert, den man sowieso vergessen hat.

    Die Cpu getriebene CRT Emulation kann und sollte in einem extra Thread ausgeführt werden um die Ressourcen besser auf alle vorhandenen Kerne zu verteilen.

    Die Option dafür befindet sich im globalen Bereich des Emulators. Einstellungen -> Video -> extra Thread

    Generell gelten alle Optionen unter Einstellungen für alle Emu Cores gleichermaßen. Das ist im Moment unwichtig, da es nur den C64 Core gibt.

    Die CRT Emulation des C64 ist hier ganz gut beschrieben: http://hitmen.c02.at/temp/palstuff/


    Chroma Subsampling

    ------------------

    Dies passiert automatisch und bedarf keiner Slider Einstellung. Chroma Subsampling kommt aus dem digitalen PAL/NTSC. Im Analogen passiert ein ähnlicher Effekt durch eine verringerte Bandbreite bei der Übertragung.

    Hierbei mischen sich die Farben mehrerer benachbarter Pixel. Da Chroma nicht für die Bildschärfe ausschlaggebend ist, nimmt das Auge den Qualitätsverlust nur gering war.


    Phasen Fehler

    -------------

    Bei der Übertragung von Chrominanz entstehen Fehler in der Phase. Dies führt bei NTSC dazu, das die selbe Farbe niemals gleich aussieht.

    Aus diesem Grund gibt es eine Einstellung für Tint/Hue um den größten Fehler am TV Gerät auszugleichen. Natürlich können somit nicht die Schwankungen ausgeglichen werden.

    Eine Tint Einstellung habe ich nicht vorgesehen. Hierfür wird einfach der Phasen Fehler verändert.


    Für PAL wird jede 2. Zeile der V-Wert des Chroma Signals invertiert übertragen. Natürlich schlägt auch hierbei der Phasen Fehler zu. Das hat zur Folge das nach der Übertragung

    der Fehler jede 2. Zeile genau in die entgegen gesetzte Richtung ausschlägt. Durch Mittelung beider Zeilen enstehen die Farben der zu übertragenden Zeile ohne Fehler,

    wenn man davon ausgeht, das beide Zeilen gleich sind und der Fehler von Zeile zu Zeile nicht nennenswert schwankt (Tatsache). Das PAL System arbeitet auf der Grundlage,

    das es mehr Ähnlichkeiten als Unterschiede von Zeile zu Zeile gibt. Zwecks Mittelung wird jede eingehende Bildzeile (Delay Line) im TV gespeichert und dann mit der nächsten eigehenden Zeile gemittelt.

    Eine Tint Einstellung ist im PAL TV somit nicht notwendig. Auf diese Weise reduziert sich die vertikale Auflösung. Zudem reduziert sich durch die Mittelung die Sättigung.

    Beide Nachteile sind weniger schwerwiegend als schwankende Farben wie im NTSC System. Im Pal System gibt es durch die Mittelung somit mehr als 16 mögliche Farben.

    demo Farbmischung für PAL (2. Programm auf der Disk): https://csdb.dk/release/?id=50556

    Thread mit Vergleich: https://csdb.dk/forums/?roomid…cid=121173&showallposts=1

    In diesem Thread sieht man ganz unten wie das Ergebnis der Demo aussehen sollte. Besonders in dem eingekreisten Bereich sind 2 Farben jeweils um eine Zeile versetzt dargestellt.

    Man erkennt es gut, wenn die CRT Emulation deaktiviert ist.

    Die Mischfarbe ist dennoch nicht gleich. Das sieht in anderen Emus nicht richtig aus. Möglicherweise habe ich die entsprechenden Einstellungen dort nicht richtig getätigt.


    Hanover Bars (nur PAL)

    ----------------------

    Ein Problem gerade bei TV Geräten bis in die 90-iger sind entsättigte Zeilen. Die Gründe dafür sind in der Literatur nicht eindeutig beschrieben. Es liegt wohl am analogen Character der Delay Line.

    Decoder späterer PAL CRT's weisen kaum noch entsättigte Zeilen auf.

    Der entsprechende Slider hat 2 Funktionsweisen. Negative Prozent Anzeigen am Slider bedeuten eine Entsättigung jeder zweiten Zeile. Positive bedeuten ebenso eine Enstsättingung jeder

    zweiten Zeile aber die jeweils andere Zeile wird mit dem selben Wert übersättigt. Dies verstärkt den Effekt.


    Scanlines

    ---------

    Um die richtige Anzahl Scanlines hinzuzufügen, wird dies vor der Skalierung in die geforderte Anzeige Auflösung erledigt. Die Anzahl der Bildzeilen bei einem CRT ist jeweils für PAL und NTSC fix.

    Größerer CRT's haben nicht mehr Scanlines sondern Dickere. Bei kleinen Auflösungen sollte 'Ganzzahl Skalierung' ebenso zugeschalten werden. Je größer die Auflösung des Ausgabefensters, desto weniger fallen Unregelmäßigkeiten in den Abständen der Scanlines auf.


    Unschärfe (Luma)

    ----------------

    Aufgrund begrenzter Bandbreite bei der Übertragung geht Schärfe verloren und die Helligkeit angrenzender Pixel oszilliert. Dies wird erreicht indem Helligkeit der Nachbar Pixel anteilig mit einberechnet wird.


    Luma Anstieg/Abfall

    -------------------

    Die Schaltkreise des im C64 eingebauten RF Modulators verursachen das Veränderungen in der Luminanz nicht sofort aktiv sind. Es dauert ca. 2 Pixel bis eine Erhöhung der Luminanz ihren finalen Wert erreicht.

    Nach einem Pixel wäre der Wert das Mittel aus alter und neuer Luminanz. Das erklärt z.B. beim C64 Start Bildschirm das Verschmieren der beiden Blau Töne an der rechten Bild/Rahmen Grenze.

    Ebenso wird die Schrift dadurch dünner, da das dunklere Blau nicht gleich auf das Helle im nächsten Pixel wechselt. Dieser Effekt verursacht also einen weiteren Schärfe Verlust.

    Zudem kann die Gesamt Helligkeit, je nach verwendeten Farben, abnehmen. Dies passiert dann wenn die Helligkeit ihren finalen Wert noch nicht erreicht hat und ein dunklerer Pixel dies auch nicht mehr zulässt.

    Hierzu gibt es eine Demo: https://csdb.dk/release/?id=81780

    Die Schrift kann man nur lesen, wenn RF Modulation zugeschalten ist.


    Palette CRT Emulation mit TV Gamma

    ----------------------------------

    Wie bereits erwähnt, ergibt die Farbspektrum Emulation in der Standard Einstellung die Colodore Palette. Wechselt man zwischen der Colodore Palette und der Farbspektrum Emulation ohne aktivierten CRT stimmt die Ausgabe überein.

    Schaltet man CRT zu, gibt es eine Abweichung im Gamma. Dies liegt daran, das die Colodore Palette auf ein Gamma von 2.2 (aktuelle Bildschirme) berechnet wurde. Mit diesem Gamma würde sie dann in die CRT Emulation reingehen.

    Die Farbspektrum Emulation basiert auf dem PAL Gamma von 2.8 und würde mit diesem Wert in die CRT Emulation eingehen. Bei Aktivierung dieser Option wird die Palette erst auf Gamma 2.8 umgerechnet

    und dann durch die CRT Emulation gejagt. Somit stimmt die Ausgabe mit der Farbspektrum Emulation wieder überein. Für NTSC besteht dieses Problem nicht, da NTSC Gamma ebenso wie das Gamma aktueller Monitore bei ca. 2.2 liegt.


    Ganzzahl Skalierung

    -------------------

    Manche Effekte, besonders Scanlines, sehen in beliebigen Auflösungen unschön aus. Die Abstände zwischen den Zeilen sind nicht gleich, wenn die Auflösung kein Vielfaches der Nativen ist.

    Bei aktiver Ganzzahl Skalierung wird die vertikale Auflösung des emulierten Systems um einen Ganzzahl Faktor hoch skaliert. z.B. x2, x3, x4 usw. Das funktioniert so:

    Die native Auflösung wird verdoppelt und geschaut ob diese noch in das angeforderte Anzeige Fenster passt. Wenn ja verdreifacht usw. Der Bereich, welcher nicht ausgefüllt werden kann, bleibt schwarz.

    Die globale Einstellung '4:3 Seitenverhältnis beibehalten' wird bei der Ganzzahl Skalierung stets berücksichtigt. In dem Fall also nicht vergessen das Fenster auch in die Breite zu ziehen.

    Wichtig: Die native Auflösung des emulierten Systems ist nicht fix, sondern wird von dem verwendeten Rahmen (der Tab neben Palette) bestimmt. Wenn man so will, wird hier festgelegt wieviel vom Rahmen der TV wegschneidet.

    Das was übrig bleibt, ist die native Auflösung, welche die Basis für die Integer Skalierung bildet. Um ein Gefühl zu kriegen, sollte man mit dem Rahmen und der Fenstergröße spielen.

    Häufig benötigen externe CRT Shader diese Option um vernünftig auszusehen. Die 'Scanlines' von Denise werden in großen Auflösungen ( >= 3x native Auflösung) auch ganz gut ohne Ganzzahl Skalierung dargestellt.

    Ich würde diese Option nicht per se zuschalten.


    GPU Shader

    ----------

    Interne GPU Shader können mit Externen kombiniert werden. Externe Shader werden nach den Internen abgearbeitet. Die Reihenfolge externer Shader wird dadurch geregelt,

    indem diese in der gewünschten Reihenfolge zugeschalten werden.

    Als Grundlage für GPU Shader wird das Bild als YUV/YIQ Signal übermittelt. (float: 32 bit je Farbkanal)

    Dies verursacht eine relativ große Datenmenge und ist daher etwas langsamer. Alternativ kann das Bild als 8 bit RGB (8 bit je Farbkanal) übertragen werden. Das stellt bei Verwendung von Farbspektren

    theoretisch einen Qualitätsverlust dar. Denn hier muss das YUV Signal erst in RGB kovertiert werden und im Shader wieder zurück in YUV gewandelt werden. In der Praxis

    sehe ich nur bei weiser Farbe einen geringen Unterschied.

    zu finden in den globalen Einstellungen: unter Einstellungen -> Video -> 32 bit je Farbkanal


    CRT Emulation mittels GPU Shader

    --------------------------------

    Diese Option berechnet die CRT Emulation mittels GPU Shader. Grundsätzlich ist der Ablauf der Gleiche mit folgenden Verbesserungen.

    CPU Ressourcen werden freigegeben, da die GPU nun dafür verantwortlich ist. Die GPU hat viele kleine parallele Rechenwerke. Auf diese Weise können viele 100 Pixel parallel berechnet werden

    und somit aufwendigere Berechnungen angestellt werden. Wird bei der CPU Variante das Chroma von 4 Pixel gemittelt um die reduzierte Übertragungsbandbreite zu simulieren,

    kommt bei der GPU Variante ein Sinc FIR Lowpass Filter zum Einsatz. Luma geht mit einer Bandbreite von 5 Mhz in den Filter ein, PAL Chroma jeweils mit 1.3 Mhz für 'U' und 'V',

    NTSC Chroma mit 1.5 Mhz für 'I' und 0.5 MHz für 'Q'.


    Folgende Optionen sind nur nutzbar, wenn CRT (GPU) aktiv ist.


    FIR Filter Länge

    ----------------

    Die 'Unschärfe' Einstellung im vorherigen Tab ist deaktiviert und durch diese ersetzt. Die Filter Länge bestimmt die Unschärfe. Je länger der Filter, desto mehr vermischen die Pixel ineinander.

    Z.b. bei dem Spiel Toki sind schwarze Pixel in den grünen Blättern. Diese sieht man deutlich wenn die CRT Emulation deaktiviert wird. Bei einer Filter Länge von 9 und größer sieht man diese kaum noch.

    In der Literatur wird erwähnt, das S-Video die gleichen Bandbreiten für Luma und Chroma bei der Übertragung benutzt wie ein einfaches Antennen Kabel. Bei S-Video wird Luma und Chroma getrennt übertragen

    und der TV PAL Decoder muss das Chroma nicht rausfiltern, was zu einer schärferen Darstellung führt.


    FIR Filter Schärfe

    ------------------

    Für Schärfe links / rechts sollte die Filter Länge relativ hoch gewählt werden. Bei diesen beiden Varianten wird der Filter auf den rechten bzw. linken Nachbar Pixel konzentriert.


    Luma/Chroma Rauschen

    --------------------

    Hier wird ein zufälliger Fehler eingebaut. Chroma Rauschen macht für NTSC (never the same color) Sinn.


    AEC, BA, PHI0, RAS, CAS Luminanz Fehler

    ---------------------------------------

    Besonders bei älteren VIC-II Chips wird das Luma verfälscht, wenn einige Pins ihren Zustand verändern. PHI0, RAS, CAS verhalten sich in allen Zyklen gleich. AEC und BA sind davon abhängig was der VIC-II genau tut.

    Wird der VIC-II ohne spezielle Tricks verwendet, verhalten sich auch diese Verfälschungen gleich. Alle 5 Pins wirken dann kombiniert zusammen. Diese Option steht nur für den C64 Core zur Verfügung.

    AEC und BA Zustände werden über den unbenutzten Alpha Kanal an den Shader übergeben.

    Die träge Luminanz Veränderung der RF Modulation wirkt sich, wie im echten System auch auf die Luminanz Fehler aus. Wird der RF Modulator aus dem C64 ausgebaut, sind die Luminanz Fehler des VIC stärker wahrnehmbar. Der RF Modulator wirkt sich also positiv auf die Verfälschungen durch diesen VIC-II bug aus.

    siehe hier: http://hitmen.c02.at/temp/palstuff/


    Bloom (Über Leuchten)

    ---------------------

    CRT's bis in die 90-iger schaffen es aufgrund ihres analogen Characters nicht sauber in der Zeile zu bleiben. Pixel blühen auf und leuchten teilweise in die leeren Zwischenzeilen.

    Mit den leeren Zwischenzeilen meine ich die Scanlines. Die Scanlines sind keine schwarzen Zeilen sondern einfach rein gar nix. Der Kathoden Beam strahlt um eine Zeile versetzt.

    Letzte Generation von CRT's weist diesen Fehler kaum mehr auf. Das ist auch der Grund, warum Scanlines dort stärker wahrgenommen werden als auf alten Röhren.

    'Radius' beschreibt den Bereich für diesen Effekt. 4 Pixel sind empfehlenswert. 'Varianz' beschreibt das Auswaschen dieses Bereiches. Je mehr Radius, desto mehr Einfluss.

    'Glühen' ist die eigentliche Einstellung für diesen Effekt und beschreibt wie stark der Pixel aufblüht. 'Gewichtung', wenn zugeschalten, verstärkt diesen Effekt noch.


    zufälliger Zeilenversatz

    ------------------------

    ganz miese Antennenkabel (Composite) können schon dazu führen, dass die Bildzeilen leicht hin und her springen.


    -------------

    Folgende Optionen sind zwar auch über GPU Shader realisiert, sind aber nicht zwingend an die CRT Emulation gekoppelt. In Bezug auf externe Shader werden die folgenden Internen nach möglichen Externen abgearbeitet.


    Licht vom Mittelpunkt

    ---------------------

    Hierüber besteht die Möglichkeit den Bildschirm kreisförmig auszuleuchten um eine abnehmende Helligkeit in den Bild Ecken zu erreichen.


    Leuchtkraft

    -----------

    Hierbei wird die Luminanz im Gegensatz zur Helligkeit am Ende der Darstellungskette angepasst.


    Lochmaske

    ---------

    Hierfür habe ich mich ziemlich an Micro64 orientiert.

    In jedem CRT steckt ca. 2 cm hinter der Mattscheibe eine Loch-, Streifen- oder Schlitzmaske. Es gibt 3 Kathodenstrahlen, einen für jede Grundfarbe (RGB). Jeder Bildpunkt auf der Mattscheibe

    besteht aus einen Tripel, also 3 Phosphor Punkte für jeweils eine Grundfarbe. Die Intensität der Strahlen regt das Phosphor an und die finale Farbe ergibt sich durch

    additive Farbmischung. Das Problem jedoch ist, das der Kathodenstrahl sich nicht ruckartig von einem zum anderen Punkt bewegt und somit für z.B. Grün auch teilweise die rote Phosphor Schicht trifft.

    Hier kommt die Lochmaske ins Spiel. Diese sorgt dafür das die richtigen Strahlen auf die entsprechenden Schichten treffen, indem diese an der Maske nur an den entsprechenden Löchern durchgelassen werden.

    Die Maske ist jeoch schwach sichtbar. Aus diesem Grund ist sie für die Emulation interessant.

    Die beiden gängigsten sind Aperture (Trinitron) und Shadow Mask (Triad).

    Der Slider 'Intensität' beschreibt wie intensiv die Lochmaske in die finale Ansicht einfließt. Ist der Slider deaktiviert, sind es die 4 folgenden Optionen ebenso.

    'Abstand' beschreibt den Abstand zwischen zwei 'Rot' Durchgängen. (horizontal bei Streifenmaske, diagonal bei Lochmaske).

    'DPI' beschreibt wieviel Bildpunkte auf einem Zoll dargestellt sind. Beide Einstellungen ergeben die Körnung und Sichtbarkeit der Maske.

    Ich habe für die Textur dieses Shaders MipMapping und anisotropische Filterung zugeschalten.


    hohe Auflösung (hires)

    ----------------------

    Hierbei wird die interne Textur verdoppelt. Kombinierte Effekte wie Scanlines + Lochmaske sehen damit in "bestimmten" Auflösungen besser aus.


    radiale Verzerrung

    ------------------

    Hiermit läßt sich die Krümmung der Röhre simulieren. Scanlines bei radialer Verzerrung sind ein Thema für sich. Sogenannte Moire patterns sind mehr oder weniger stark zu sehen.

    Besonders bei geringer Auflösung stechen die Verfälschungen hervor. Aus diesem Grund würde ich die Kombination beider features nur bei ca. 4x der nativen Auflösung empfehlen,

    da 2x der nativen Auflösung allein schon für die scanlines benötigt wird.


    Verzerrung in hoher Auflösung

    -----------------------------

    Diese Einstellung greift nur, wenn die radiale Verzerrung akiviert ist. Hierbei wird die interne Auflösung genau wie bei 'hires' verdoppelt. Dies kann das Resultat verbessern, wenn

    Scanlines und/oder die Lochmaske ebenso zugeschalten sind. Ist 'hires' bereits aktviert, wird die Auflösung ein weiteres Mal verdoppelt.

    Das kostet was, aber verbessert das Resultat noch mehr, wenn die Auflösung des Anzeige Fensters entsprechend groß ist. Ohne Scanlines ist diese Option eine Ressourcen Verschwendung.


    Interpolationsfilter

    --------------------

    Unter 'Einstellungen' im Hauptmenu befindet sich der Interpolationsfilter. Der sollte auf 'Linear' stehen.



    Was fehlt noch in Hinsicht auf Shader und Video Treiber ?

    ---------------------------------------------------------

    Die GLSL Shader funktionieren nur mit OpenGL. Ich möchte diese in Slang Shader konvertieren und neben DX9 noch DX10, 11, 12 hinzufügen. Auf diese Weise sind die Shader mit beiden kompatibel.

    Dennoch hat man aktuell unter DirectX eine umfangreiche PAL Emulation zur Verfügung. CG Shader und HLSL Shader sind veraltet und spielen für mich keine Rolle.

    Neben DirectX und OpenGL bin ich langfristig auch an Vulkan interessiert.


    Später möchte ich die Slang Shader von Retro Arch ebenso unterstützen.

    Wichtig dafür ist eine automatisiert generierte Eingabe Maske um die Parameter (defines) externer Shader zur Laufzeit bequem über Slider zu customizen.

    CRT-Royale z.B. hat zahlreiche Einstellungsmöglichkeiten.

    Ich habe vor einigen Monaten von Retro-Nerd 3 Shader bekommen, Lottes, Trinitron und Trinitron 2. Diese Shader, wie die meisten CRT Shader, kümmern sich nicht um PAL Encoding/Decoding und

    natürlich auch nicht um C64 individuelle Anomalien, wie VIC-II Luminanz Fehler oder RF Modulation bedingte Luminanz Fehler. Diese Shader kümmern sich um die physikalischen Eigenschaften der Röhre, also Scanlines, Bloom und Maske. Besonders das komplexe Zusammenspiel dieser 3 Eigenschaften wird von Shadern, wie CRT-Royale auf einem höherem Level betrieben als bei meiner Version.


    Wenn man einen externen CRT Shader verwendet, sollte man diese 3 Eigenschaften in der internen Emulation deaktivieren (Checkboxen), so dass eine reine PAL Signal Emulation

    aus interner Sicht läuft. Auf diese Weise stelle ich mir später die Kombination mit anderen RetroArch CRT Shadern vor. Natürlich kann die interne CRT Emulation auch vollständig deaktiviert werden

    und nur externe Shader aktiv sein.


    Retro-Nerd

    Ich habe diese 3 Shader mit verteilt. Wenn das nicht gewollt ist, nehme ich diese wieder raus.


    Um die Shader zu benutzen, muss der 'shader' Ordner unter Einstellungen/Video zugewiesen werden.

    Dann sind diese 3 Shader unter C64/Shader verfügbar. Beim Shader Wechsel bitte daran denken, dass der alte erst deaktiviert wird, ansonsten sind beide aktiv. Das ist lästig aber dem

    Umstand geschuldet, dass mehrere parallel aktiviert werden können.


    Wie geht es weiter ?

    --------------------

    Ich versuche die Kompilierung unter Windows zu vereinfachen.

    Das GIT Repo wird öffentlich zugänglich. Fertige Features gehen in den master branch und können dann in Form eines nightlies vor dem offizielen release gebaut werden.

    Die settings.ini muss aufgrund der nunmehr vielen Optionen Core separiert und Themen gruppiert gespeichert werden. Dann wären die Cores nicht nur UI technisch voneinander getrennt.


    [1.0.6] Das nächste release geht voll umfänglich in den Expansion Port. REU, Easy Flash, ...

    [1.0.7] Danach wird es wieder Zeit für ein Retro Arch Feature. ( frame ahead zur Reduzierung der Eingabe Latenz )

  • So, mal etwas genauer reingeschaut:


    Soweit läuft das alles problemlos.


    - Kommandozeilen Start per Gamebase z.B. geht einwandfrei.

    - Drag'n'Drop soweit auch. Nur sollte man hier wirklich den Haken unter "Settings -> Settings -> always auto start by drag'n'drop" setzen.

    - Auch die eingebaute Palettenauswahl macht genau das, was man möchte.

    - Integer Scaling: Das funktioniert mit der manuellen Border Crop Option auch sehr gut. In einer 1080p Auflösung muß man 12 Pixel oben und unten "wegschneiden", dann hat man ein integer skaliertes Vollbild bei dem auch die Shader korrekt aussehen.

    - die PAL CRT Emulation ist nicht so mein Fall. Nutze lieber Shader. Aber jetzt weiß ich endlich, warum das Bild mit den Scanlines immer so ungleichmäßig in Micro64 aussah. Die Hanover Bars waren das. Auf 0%+Scanlines sieht das recht gut aus.


    Alles in allem wieder eine tolle Version von dir. Freu mich dann auf EasyFlash Support und vor allem auf das Killer Feature "Run ahead". :)

  • Ja um bei 1080p die 4 fache native Auflösung zu schaffen, muss ziemlich viel Rahmen weggeschnitten werden.

    Gerne, ich werde guest.r in der licence Datei mit erwähnen.

    Die PAL und CRT Emulation ist mit Shadern erstellt. Der Ablauf ist grob dieser.

    1. VIC-II bedingte Luminanz Anomalien einrechnen

    2. RF Modulator bedingte Luminanz Latenz einrechnen

    3. PAL encoding

    4. Übertragung an TV mit begrenzter Bandbreite

    5. PAL decoding (Mischen zwei benachbarter Zeilen, chroma subsampling, hanover bars)

    6. CRT Emulation (physikalische Eigenschaften der Röhre: scanlines, bloom, Maske)


    Du könntest auch die PAL Emulation mit der externen CRT Emulation kombinieren. Das funktioniert aber nur vernünftig wenn das interne Maske, Bloom und Scanlines deaktiviert wird. Das macht dann der Trinitron Shader. Das hat den Vorteil das die PAL typische Mischung von 2 Bildzeilen (mehr als 16 Farben dadurch) mit emuliert wird, denn das wiederum macht der Trinitron nicht. Ich denke ohne diese Mischung geht einiges an Retro feeling verloren.

    So verschieden sind die Ansichten. Ich persönlich finde die PAL Emulation angenehmer als die CRT Emulation. Mir gefällt der starke Masken Effekt beim Trinitron nicht.

    Grundsätzlich sind mir bei der CRT Emulation (Punkt 6 siehe oben) externe Shader voraus, z.B. CRT-Royale. Ich stelle mir eine Symbiose zwischen interner PAL und externer CRT Emulation vor.

  • Ah Ok, interessant. Das mit der Mischung von Shader und CRT Emulation muß ich mal austesten.


    Quote

    Mischung von 2 Bildzeilen (mehr als 16 Farben dadurch) mit emuliert wird, denn das wiederum macht der Trinitron nicht. Ich denke ohne diese Mischung geht einiges an Retro feeling verloren.

    Hättest du mal ein schönes Bildbeispiel, wo man das gut vergleichen kann?

    Quote

    Mir gefällt der starke Masken Effekt beim Trinitron nicht.


    Die Maskenstärke ist jetzt auch nicht in Stein gemeißelt. Sowas ließe sich auch anpassen. Schau dir mal in RetroArch den Multi-Shader von guest.r an, nennt sich "crt-guest-dr-venom.glslp". Der ist noch viel komplexer, als die simple Version die er für Denise gemacht hatte. Wenn du erstmal Retroarch Shader Support eingebaut hast wird das alles noch besser aussehen.


    edit: Gerade mal mit den Trintron Shader Werten rumgespielt. Damit ist die Maskenstruktur schon deutlich schwächer ausgeprägt.



    Code
    1. #define beam_min 0.90 // dark area beam min - narrow
    2. #define beam_max 1.40 // bright area beam max - wide


    Shader und interne PAL CRT Emulation zusammen sieht dann so aus. Siehe Anhang.


    Edit2: Was verursacht eigentlich den sehr feinen Font, wenn die interne CRT Emulation aktiv ist? Sieht etwas merkwürdig aus.

    Edit3: ah, gefunden. Luminance Rise kleiner einstellen. :thumbup:

  • Quote

    Hättest du mal ein schönes Bildbeispiel, wo man das gut vergleichen kann?

    https://csdb.dk/release/?id=50556

    Das 2. Programm auf der Disk. Einfach mal ziwschen CRT aus und CRT an wechseln. Dann sieht man wie sich die grünen und roten Bildzeilen mischen. Bei NTSC gibt es diese Mischung übrigens nicht.

    Und dann probiere mal den Trinitron Shader zuzuschalten und dann dort ebenfalls zwischen CRT an / aus wechseln. Ist CRT aus, greift nur der Trinitron. Ist es aktiviert, sollten aber alle internen CRT Effekte (maske, Über Leuchten (bloom), scanlines, Licht vom Mittelpunkt, CRT Fehler) deaktiviert sein. Die restlichen Checkboxen gehören hauptsächlich zur PAL Emulation.

    Die Farbmischung der Zeilen findet dann ebenfalls statt. Ohne diese Mischung ist es eher ein NTSC shader.

    Das ist der Grund warum mir das PAL Encoding wichtig ist und ich nicht nur auf die RetroArch Shader setzen kann.

    Besser noch du nimmst dir ein Spiel mit aktiviertem Trinitron und wechselst zwischen CRT an und CRT aus.

  • Quote

    Edit2: Was verursacht eigentlich den sehr feinen Font, wenn die interne CRT Emulation aktiv ist? Sieht etwas merkwürdig aus.

    Edit3: ah, gefunden. Luminance Rise kleiner einstellen.

    Der sehr feine font wird durch den RF Modulator im C64 verursacht. Wenn du die Checkbox vor Luminanz Anstieg und Abfall deaktivierst, ist der RF Modulator komplett deaktiviert.

    Die Schaltkreise des Modulators sorgen dafür, das die Luminanz nicht sofort von einem zum anderen Pixel wechselt. Das dunkle Blau des Hintergrundes kann nicht sofort in das helle Blau der Anzeige Schrift wechseln, dadurch wird diese dünner.

  • RF habe ich seit über 20 Jahren nicht mehr am C64 genutzt. Immer nur S-Video. :D


    Hast du dir mal den Trintron Shader mit dem schwächeren Maskeneffekt mal angeschaut (Anhang)?Besser noch du nimmst dir ein Spiel mit aktiviertem Trinitron und wechselst zwischen CRT an und CRT aus.


    Quote

    Besser noch du nimmst dir ein Spiel mit aktiviertem Trinitron und wechselst zwischen CRT an und CRT aus.


    Stimmt, das sieht in der Tat besser als nur den Shader zu nutzen. Sieht man ganz gut an den grünen Bäumen bei Giana Sisters. :thumbup:

  • Quote

    Hast du dir mal den Trintron Shader mit dem schwächeren Maskeneffekt mal angeschaut (Anhang)?

    ja sieht angenehmer aus. Aber der Shader alleine wirkt zu pixelig. Hier fehlt mir das Luma Blur und Chroma subsampling. (reduzierte Bandbreite bei der Übertragung des Farbsignals)

    Besonders die letzte Generation von CRT's, wie Trinitron, finde ich für 240p content (8 oder 16 bit Systeme) unschön. Durch die beseitigten Analog Artefakte fällt die grobe Auflösung stärker auf, als bei Geräten aus den 90 igern, welche durch Effekte wie bloom die Scanlines in hellen Bereichen einfach überleuchtet haben.

  • Quote


    Hier mal ein Screenshot von Giana Sisters. Interne CRT Emulation und Trinitron Shader kombiniert. Sieht doch sehr ordentlich aus.

    ich habe mir mal den Trinitron Shader vom Code her angeschaut.

    Zuerst generiert er die Scanlines, berücksichtigt dabei die Helligkeit der Farben darüber und darunter. Mache ich auch aber er geht noch nen Schritt weiter und begrenzt die berücksichtigte Helligkeit durch beam_min und beam_max.

    Danach wird die Trinitron typische Streifenmaske ( vertikale Linien, ergeben dann eine Kachel mit Scanlines ) einberechnet. Meine Maskenberechnung und diese unterscheiden sich stark.

    Abschließend wird ein dezenter Bloom Effekt, also Überleuchten von Scanlines bei hellen Farben, einberechnet. Ich verwende Gaussian Blur für die Gewichtung der Nachbarpixel. Auf die Schnelle geschaut, sieht das beim Trinitron auch nach der Formel für Gaussian aus.

    PAL Decoding wird hier nicht berücksichtigt. (Vermischen der Farbigkeit benachbarter Pixel und Farbmischung zweier benachbarter Zeilen und Hanover Bars)

    Gut Hanover Bars sind kein Thema mehr beim Trinitron. Der PAL Decoder im TV rechnet die sauber raus. Das ist mehr ein Relikt aus den 90 igern.


    Es ist schon ganz gut das mal aus anderer Perspektive mit anderen Vorlieben zusehen.

    Ich schätze, wenn jemand in Denise einen externen Shader verwenden will, geht er davon aus die interne CRT Emulation abschalten zu müssen, da sich ja sonst was überlagern könnte.

    Und ja dieser Gedanke ist richtig, wenn bestimmte Eigenschaften wie Maske, Scanlines usw. nicht deaktiviert werden. Der user weiß in dem Moment aber nicht das bei deaktivierter CRT Emulation

    das ganze PAL Verhalten mit deaktiviert wird. Die meisten externen Shader kümmern sich nämlich nicht darum, da sie für die NTSC Welt gemacht sind.

    Ich baue das Video User Interface um, indem ich die Prozesse chronologisch ordne. Jeder Prozess ist deaktivierbar.


    [Tab 1 - Grundfarben Bestimmung]

    - Palette oder Spektrum, PAL oder NTSC, Phase, Kontrast, Sättigung, ...


    [ Tab 2 - Farbveränderungen, welche im C64/Amiga selbst passieren ]

    - ab hier und den folgenden Tabs kommen GPU Shader zum Einsatz

    - VIC Luminanz Fehler, RF Modulation, Signal Encoding


    [ Tab 3 - Signal Decoding im TV ]

    - Chroma Subsampling ( Farbveränderungen durch reduzierte Übertragungsbandbreite )

    - Hanover Bars ( nur PAL ) entsättigte Bildzeilen

    - Delay Line ( nur PAL ) Farbmischung benachbarter Bildzeilen

    - Rauschen, zufälliger Zeilenversatz durch schlechte Antennenkabel ... wers brauch


    [ Tab 4 - CRT Emulation ]

    - externe CRT Shader sind jetzt hier in einer Liste auswählbar, nicht mehr im Hauptmenu

    - Auswahl zwischen internen oder externen Shader ... keine Gefahr mehr das sich interne und externe CRT Eigenschaften überlagern

    - bei Doppel Klick auf einen Shader öffnet sich eine extra Maske mit den individuellen Eigenschaften dieses Shaders

    - in der extra Maske werden dann alle veränderbaren Einstellungen des Shaders (RetroArch support) geladen: hauptsächlich Scanlines, Beam, Maske und Bloom


    wie besprochen, Expansion Port kommt aber vorher

  • Ist sicherlich eine gute Sache, das man jeden Prozess der CRT Emulaton abschalten kann. Hast du dir den vollwertigen "crt-guest-dr-venom" Shader in RetroArch mal angeschaut? Der geht deutlich weiter als die simple Version hier. Da lassen sich sogar Farbprofile der TVs/Monitore wählen, z.b sRGB, DCI, Adobe etc. samt Farb Temperatur, dazu 6 verschiedene Maskenarten. Schätze wenn HDR bei PC Monitoren mal Standard wird (die Teile sind noch recht teuer) werden auch die Shader noch realtischer was z.B. Bloom und Pixelglühen angeht.


    Ja, PAL via RF wird da nicht berücksichtigt. So richtig störend finde ich das aber nur bei Mega Drive Spielen. Mal ehrlich, wer schließt seine alten Geräte noch per Antennenkabel an? Beim C64 nutze ich notgedrungen S-Video. Bei allen andere dann Minimum RGB.

  • Quote

    st sicherlich eine gute Sache, das man jeden Prozess der CRT Emulaton abschalten kann. Hast du dir den vollwertigen "crt-guest-dr-venom" Shader in RetroArch mal angeschaut?

    schaue ich morgen an, muss alles erstmal sauber neu installieren

    Quote

    Ja, PAL via RF wird da nicht berücksichtigt. So richtig störend finde ich das aber nur bei Mega Drive Spielen.

    Die Farbmischung der Bildzeilen bei PAL findet aber auch bei S-Video statt. Der Unterschied im TV zwischen S-Video und Composite ist, das bei S-Video Luminanz und Chrominanz

    getrennt übertragen werden. Bei Composite ist Chrominanz auf die Luminanz aufmoduliert, da nur ein Kabel. Der PAL Decoder muss das erst rausfiltern, deswegen der Quali Verlust.

    Das PAL Signal wird im YUV Format, nicht RGB, an den TV übertragen und dort in RGB encoded.

  • Ja, den Unterschied hatte ich gestern ja mit Giana Sisters gut vergleichen können. PC steht neben der Sony Trinitron Röhre. Nun gut, für C64 macht das für mich dann Sinn. Aber für die Amiga Emulation/echte Amiga Hardware z.B. ist das doch eher zu vernachlässigen, oder? Unter RGB geht ich da nicht ran. Bekommt man ja Augenkrebs per Composite.

  • ja mit dem RGB Kabel wird das Bild beim Amiga nicht mit reduzierter Bandbreite im YUV Format übertragen aber ich schätze die PAL typische Farbmischung benachbarter Zeilen passiert dennoch.


    Ich habe mir den Shader: crt-guest-dr-venom angeschaut. Der macht noch einige Sachen mehr wie Phosphor Glow, jedoch kein PAL Kram. Ist nicht schlimm, ist Aufgabe des Emu Autors.


    Beim Spiel Toki sieht man den Unterschied durch PAL Encoding in der Struktur der Bäume sehr gut.