Beiträge von PiCiJi

    Hallo Dirk,


    Ja das timing, besonders zwischen Blitter und CPU, ist nicht ohne. Ich bin seit einigen Jahren raus. Ich verstehe kaum noch meinen eigenen Amiga Code. Ich schaue mir gerade Fragmente meines Blitter Codes an.

    Zur Frage: Verwendest du den aktuellen 68k Core in Denise, ist die Wahrscheinlichkeit recht hoch, dass du ihn debuggen musst, weil irgendwas nicht geht.

    Beim portable sind die opcodes sehr intensiv unit getestet und die Zyklen vom Patent übernommen.

    Die Fehler beschränken sich dort auf das exception handling. Ich schätze das ist machbar, wenn man sich nicht unbedingt mit der CPU emulation beschäftigen will.

    Ich meine nicht alle Änderungen in den portable überommen zu haben, als ich damals meinen A500 Emulator schrieb.

    Ich würde dir im Anhang den CPU Code von meinem A500 Emulator mitgeben, denn das ist die letzte Version des portable. Außerdem läuft damit die Amiga Emulation an, auch Spiele.

    Vieles startet jedoch noch nicht. Das muss aber nicht am CPU Core liegen. Das wollte ich gerade herausfinden, jedoch musste ich dann länger pausieren.

    Natürlich könntest du auch das Zyklen timing an den Musashi Core binden aber ich glaube das sich dann nicht alle Situationen sauber abbilden oder zumindest nur dreckig in Code bringen lassen.


    Was ich noch sagen wollte, der Hauptgrund warum ich den portable neu geschrieben habe, ist Software Design. Der 68k kann einen opcode bei bestimmten exceptions an Ort und Stelle verlassen ohne die restlichen Zyklen abzuarbeiten. Das hatte ich mit einem Performance hungrigen try/catch gelöst. Im neuen Design ist das durch einen dummy Context ersetzt.

    Dateien

    • 68k.zip

      (18,28 kB, 8 Mal heruntergeladen, zuletzt: )

    m68000 portable ist outdated und hat bugs im IRQ handling.

    Die Vergleichs Daten für die Unit Tests sind von einem echten Amiga 500 gesampelt.

    Nach Veröffentlichung dieses Projektes habe ich einen Zyklen genauen Amiga Emulator geschrieben (unveröffentlicht).

    Jedoch habe ich es versäumt alle Änderungen am CPU Kern in das portable Projekt einzuarbeiten.

    Nach einer längeren, ungeplanten Pause begann ich mit der Entwicklung eines Multi Emulator Systems in Hinsicht auf Plattform Unabhängigkeit.

    Im Anschluss habe ich den 68000 Core neu geschrieben, welcher sich bereits in den Sourcen von Denise befindet.

    Diese Weiterentwicklung ist aber kaum getestet.

    Ich habe dann die Amiga Emulation unterbrochen um meinen ursprünglichen Wunsch, nämlich die Emulation meiner beiden Lieblings Systeme in einem Programm zu vereinen, wieder aufzunehmen.


    Das m68000 portable Projekt wird verschwinden oder ersetzt, wenn ich meinen Amiga Emulator weiterentwickle.


    Beide Projekte sind GPL und können gerne weiter verwendet werden. Ich komme aber erst in 2020 dazu die 68k Emulation zu finalisieren.

    Zitat

    In Bitbucket kann man übrigens auch den kostenfreien Issuetracker aktivieren, dann kann man da auch Issues etc. empfangen.

    gut zu wissen.

    Im nächsten release kommt EasyFlash. Ich habe jetzt ne gute Stunde auf der Seite des Autors von EasyFlash verbracht.

    Besonders interessant ist die Technik wie EF3 einen echten Kernal replacement durchführt.

    ## 1.0.6

    polished OS X UI ... looks ok now for Mojave dark theme

    Windows command line support is now independant from working directory of caller

    added option to manually save settings

    reworked expansion port emulation

    added REU support with additional 8k rom

    added Action Replay MK2, MK3, MK4, V4.1 and higher

    support Cartridge bin format

    GIT repo is public now: https://bitbucket.org/piciji/denise/src/master/

    simplified build process



    Expansion Port

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

    Unter Systemverwaltung wird die Art der Expansion oder keine ausgewählt. Auf diese Weise müssen keine roms mehr ausgeworfen werden um die Expansion zu deaktivieren.

    Für REU wird ein Slider zur Einstellung der Speichergröße direkt darunter aktiviert.

    Sämtliche roms für den Expansion Port lassen sich unter Software, direkt neben Disketten / Kasetten auswählen. Hierbei können pro Thema mehrere roms eingelegt werden.

    Ein Auswahl button zeigt an, welches bei einem power/reset verwendet wird.

    Ja auch für das REU können roms zugewiesen werden. Das REU board hat einen Sockel für 8 KB große roms.

    http://www.cbmhardware.de/reu/

    Das zweite rom auf der Seite kann nicht direkt verwendet werden.

    Der Author hat sein REU so umgebaut, dass ein 16 kb großes rom verwendet werden kann. Per extra Schalter wird dem System gesagt,

    welches der beiden 8 kb chunks verwendet wird. Für die Emulation macht das Vorgehen wenig Sinn, da hier die Eproms virtuell sind und schnell getauscht werden können.

    Um dieses rom zu verwenden, muss es in zwei 8 kb chunks aufgeteilt werden. Unglücklicherweise hat der Author das PRG Format für eine CRT/BIN gewählt.

    Das bedeutet die ersten 2 bytes müssen abgeschnitten werden.


    Spiel Module und Action Replay

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

    Jetzt wird auch das BIN Format unterstützt. Im Gegensatz zum CRT Format gibt es hier keine header Informationen, welche das PCB beschreiben.

    Der Emulator hat dann keine Ahnung, welches mapping das Modul verwendet. Hierbei kommt die Auswahlbox ins Spiel. Die Auswahl wird beim CRT

    Format ignoriert.


    Speicher

    --------

    Neben PRG's besteht die Möglichkeit Speicherabbilder für das REU einzulegen. Da gibt es ein DEMO mit einem 16 MB großen REU image.


    Action Replay

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

    Der Freeze button ist im Hauptmenu unter Soft Reset.



    für Selbst Kompilierer

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


    There is a makefile in 'drivers' folder. There you can remove some drivers, you don't need

    or don't want to install, like SDL2, freetype or openal. simply ignore removed drivers in following installation guide.

    For example you could remove all audio drivers. The emulator will be running without audio.


    WINDOWS (XP and higher)

    -------

    install mingw32 or 64 (includes gnu compiler, directx, opengl, hid ... almost everything)

    https://sourceforge.net/projects/mingw-w64/

    run installer, prevent spaces if you want to change installation folder, select following options

    Version: latest

    Architecture: x86_64, select i686 only if you want to build a 32 bit version of Denise

    Threads: posix

    Exception: seh (64 bit) or dwarf (32 bit)

    Build Revision: latest


    NOTE: in the following we need to include more headers / libraries to our mingw

    installation folder. The first include / lib folders you see in mingw main folder are NOT the

    target folders, therefore change to subfolder: x86_64-w64-mingw32 (64 bit) or i686-w64-mingw32 (32 bit)


    openal: install sdk: https://www.openal.org/downloads/

    remeber installation folder and look into it

    copy 32 or 64 bit lib OpenAL32.lib in mingw lib folder

    create folder AL in mingw include folder and copy all header files into it


    freetype: download and unpack latest source code

    copy contents of freetype include folder to mingw include folder

    i have already compiled a static link library for 32 and 64 bit.

    copy it from denise source: data/libs/static/win(32)64/libfreetype.a to mingw lib folder


    install MSYS if you haven't already.

    https://sourceforge.net/projec…oad?use_mirror=netcologne

    MSYS is a collection of GNU utilities such as bash, make, gawk and grep

    to allow building of applications which depend on traditionally UNIX.

    run installed msys to get a command line prompt.


    read on at 'now build Denise'. after compilation copy all contents in subfolder 'out' to any place you want.


    OSX

    ---

    opengl, openal should already installed (system frameworks)

    don't forget to update commandline tools, when upgrading OS: xcode-select --install


    install brew: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.…ew/install/master/install)"

    brew install pkg-config

    brew install sdl2


    compile freetype

    download latest source

    ./configure --enable-static --without-zlib --without-bzip2

    make

    sudo make install


    read on at 'now build Denise'


    LINUX

    -----

    please install following dependencies if you haven't already


    GTK+ 2: apt-get install libgtk2.0-dev

    OpenGL: apt-get install mesa-common-dev

    OpenAL: apt-get install libopenal-dev

    Pulseaudio: apt-get install libpulse-dev

    SDL2: apt-get install libsdl2-dev

    Udev: apt-get install libudev-dev


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

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


    now build Denise

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

    change to projects root folder and type:


    make -f makefile [windows, linux, osx]

    make install [windows, linux]

    make uninstall [linux]

    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.

    Zitat

    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

    Zitat

    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.

    Zitat


    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

    Zitat

    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.

    Zitat

    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.

    Zitat

    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.

    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.

    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 )

    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.

    kurzes update.


    Ich versuche mich gerade an CRT emulation. komplettes Neuland für mich. Jetzt sehe ich endlich Licht am Ende des Tunnels.
    Es dauert aber noch ne Weile.
    command line support, drag'n'drop, integer scaling, Farb Paletten, Farb Spektrum nach Art des neuen Pepto (Colodore) (pal, ntsc) sind fertig.

    Zitat von GoDoT

    Ja, weil es Abkürzungen sind, gehören die Buchstaben alle groß: PAL, NTSC.

    Ok, ändere ich ab.

    Zitat

    Hab rausgefunden, dass es reicht, wenn man z.B. die Tasten für oben und links gleichzeitig drückt

    Ja, es ist nicht notwendig diagonale Richtungen extra zu mappen.


    Zitat

    Tolle Leistung, deine Denise!

    Danke. :-)

    Zitat

    Ist ja schon geschehen (s. Dateianhang in Post 90). Allerdings sind einige Captions hartkodiert und nicht in german.txt enthalten (z.B. "Pal", "Ntsc" und noch einige andere).

    Es sollten nicht mehr allzu viele Captions hart verdrahtet sein, dank meinem Übersetzer ins Französische. Würdest du für pal/ntsc etwas Bestimmtes im Deutschen schreiben wollen?


    Ja ich könnte die Richtungstasten als Vorgabe für Joysticks einstellen.
    Joystick in 8 Richtungen ? als Maus Ersatz ? Aktuell kann die emulierte Maus / Light Gun / Pen auch auf ein Analog Joystick gemappt werden. Die Prezission ist dabei jedoch deutlich geringer als bei einer Maus.

    Zitat

    Mein Wunsch wäre ein 1581 Support...

    ich setze es mal auf die todo Liste. (leider mit niedriger Prio)

    Zitat

    Ja, noch was: Das Pagefox-Modul (läuft auf VICE) tut's nicht, Simons' Basic aber schon.

    Expansion Port emulation ist aktuell schwach bei Denise. Im Moment werden nur die standard Module und die meisten Spiele Mapper (ocean, system3, ...) emuliert.
    Das übernächste release gilt gänzlich dem Expansion Port: REU, Easy Flash 3, ...

    Zitat

    Mit Maus und Joystick denk ich vielleicht falsch: Wird die Windows-Maus nicht als C64-Maus emuliert? Und wird ein Joystick zukünftig über die Zifferntasten ansteuerbar?

    Für Maus 1351 und Neos Software sollte ja ein vom c64 generierter Maus Zeiger existieren. Die Windows Maus wird dann über die mittlere Maus Taste (konfigurierbar über Schnelltasten) gefangen. (unsichtbar geschalten)
    Oder was genau meinst du mit der 1. Frage ?
    Ein Joystick kann bereits über die Zifferntasten angesteuert werden. Jedes emulierte Eingabe Element oder Hotkey kann auf jedes reale Eingabe Element konfiguriert werden.
    Z.b. lege ich mir die Hotkeys für Spielstände (Laden, Speichern, Slot Up/Down) auf die Schulter Tasten meines GamePads.
    Für Light Gun / Pen kann die reale Windows-Maus verwendet werden, wenn die Maus nicht gefangen wird. Andernfalls ist es ein in C64 Auflösung emulierter Cursor.

    Zitat

    GoDot läuft sauber auf Denise. Wäre schön, wenn demnächst eigene Farbpaletten (also z.B. die von GoDot) und eine REU-Emulation reinkämen, dann wär ich glücklich!

    Farbpaletten kommen im nächsten release.

    Zitat

    Ach ja, weil mich Fehler in Beschriftungen immer ärgern, hab ich die german.txt überarbeitet. Wer will...

    Ich versuche die Änderungen zu erkennen und einzuarbeiten.

    ich verwende gnu makefiles. Das aufwendigste unter Windows ist freetype zu bauen. Das wird ausschließlich für Bildschirmtexte unter openGL verwendet.
    Wenn Texte in der Statuszeile ausreichen, kann unter driver/makefile folgende Zeile auskommentiert werden: drv += freetype
    Ebenso kann openAl unter driver/makefile auskommentiert werden.


    There is a makefile in module 'drivers'. There you can remove some drivers, you don't need
    or don't want to install, like SDL2, freetype or openal. There are alternatives.
    For example you could remove all audio drivers. The emulator will be running without audio.


    WINDOWS (XP and higher)
    -------
    install mingw32 or 64 (includes gnu compiler, directx, opengl, hid ... almost everything)


    NOTE: in the following we need to include more headers / libraries to our mingw
    installation. The first include / lib folders you see in mingw main folder are NOT the
    target folders, therefore change to subfolder: x86_64-w64-mingw32


    [openAL]
    install openal sdk: https://www.openal.org/downloads/
    copy 32/64 bit lib OpenAL32.lib in mingw 32/64 lib folder
    create folder AL in mingw 32/64 include folder and copy all header files into it


    [openGL freetype]
    download and unpack latest freetype source code v:2.9.1 at the moment
    install MSYS if you haven't already.
    MSYS is a collection of GNU utilities such as bash, make, gawk and grep
    to allow building of applications which depend on traditionally UNIX.
    first run postinstall/pi.bat from msys install folder, follow the dialog
    and input the mingw installation path.
    afterwards there should be a file in msys etc folder /etc/fstab
    if the postinstall procedure isn't working properly rename /etc/fstab.sample
    in /etc/fstab and insert the mingw folder by yourself.
    hints: use slashes instead of backslashes, in my case it looks like this:
    C:/mingw64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64 /mingw
    now start msys and you get a special cmd
    switch to freetype folder
    input: ./configure --enable-static --without-zlib --without-bzip2
    mingw make isn't working here, use msys make instead
    in my case it looks like this: C:/msys/1.0/bin/make
    finally we get a static library in freetype folder: objs/.libs
    copy objs/.libs/libfreetype.a to your mingw lib folder
    copy all files from freetype include folder to your mingw include folder
    NOTE: keep in mind if you want to build Denise as 32 or 64 bit version.
    freetype have to be build the same version. therefore assign a 32 or 64 bit
    mingw installation in the before mentioned fstab file.
    NOTE: maybe you have to reinstall msys when building an app for 32 and 64 bit
    in my case changing mingw path in fstab file wasn't detected a second time.
    NOTE: antivir interrupts configure task with a false positive.
    disabling antivir afterwards and try again isn't enough so do it before.
    otherwise remove the file from quarantine, delete freetype,
    unpack it again, disable antivir and try again.
    running in all these problems make installing freetype a tedious task.


    OSX
    ---
    opengl, openal should already installed (system frameworks)
    [SDL2 framework]
    install libsdl2
    cp /opt/local/bin/sdl2-config /usr/bin/


    [freetype]
    download latest source
    ./configure --enable-static --without-zlib --without-bzip2
    make
    sudo make install


    LINUX
    -----
    please install following dependencies if you haven't already


    GTK+ 2: apt-get install libgtk2.0-dev
    OpenGL: apt-get install mesa-common-dev
    OpenAL: apt-get install libopenal-dev
    Pulseaudio: apt-get install libpulse-dev
    SDL2: apt-get install libsdl2-dev
    Udev: apt-get install libudev-dev


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


    now build Denise
    ----------------
    change to projects root folder and type:


    make -f makefile [windows, linux, osx]
    make install [windows, linux]
    make uninstall [linux]

    Zitat

    Es fühlt sich bei manchen Sprüngen mit Gianna oder Turrican halt seltsam und unhomogen an.

    ne das passt schon. die Gianna Tante springt doch immer wie auf dem Mond unabhängig vom Input Lag.


    Zitat

    Aber Rechte Shift nach wie vor nicht intuitiv. Warum rechte?

    guter Punkt. ich verwende immer shift Rechts + Taste. Ich baue das so um, das auch shift links + Taste möglich ist, jedoch als alternative mappings.
    Alles auf ein Element zu legen, wäre zu kompliziert, da user es jederzeit überschreiben können.
    Also keine mappings in der Form: ( alt left und Taste ) oder (alt right und Taste)


    Zitat

    Zum Schluss noch ernsthaft, seit über 10-15 Jahren quäle ich mich immer mal wieder durch versch. Viceversionen, selbstkompilieren, Windows/Linux, xy64, micro, hoxs etc. um den Kram FLÜSSIG ans Laufen zu kriegen.

    da ich kein Freund von closed source bin, bleibt das so. vice selbst kompilieren geht gerade noch so. für winuae brauch man schon viel Geduld. micro und hoxs ? Ich dachte die sind closed source.