Posts by Tobias

    Sorry falls Offtopic, könnte jermand bitte mal erklären, warum man diese EasyFlash-Versionen braucht bzw. was daran anders (besser?) ist als bei "normalen CRT-Files? Die Möglichkeit, Spielstände zu speichern?
    Hab mir die Wiki-Seite angesehen, aber steige da nicht wirklich durch, da es mehr die Verfahren der Übertragung beschreibt.
    Ist das Ziel, aus D64 oder PRG files, die es nie als CRT hab, letzteres zu generieren?
    Laufen die Easy-Flash-Versionen nur auf jener oder auch auf einer U2+ ?
    Sollte ja eigentlich gehen:
    https://1541u-documentation.re…asyflash-cartridge-images


    Danke und Gruß,

    Tobias

    Hallo. Ich suche den C64 Zeichensatz in einer goßen Darstellung, in der man jeden einzelnen Pixel erkennen kann, so wie in dem Bild. Aber für jedes Zeichen von CHR$(0) bis CHR$(255). Hintergrund ist, dass ich die Zeichen des kompletten Zeichensatzes in einen von mir erstellten Grafikeditor auf dem PC von Hand übertragen möchte. Gibt es da etwas Fertiges, das einigermassen übersichtlich ist?


    Groß ist das nicht, aber vielleicht kannst Du den ja selbst ohne Aliasing vergrößern.
    https://www.c64-wiki.de/wiki/Zeichen

    Wobei das in der Summe total richtig ist. Letztendlich zerlegst Du eben das Problem in verschiedene Teilprobleme. Dass die Leute, die ..äh... die Systeme kreativ nutzen, das an bestimmten Displays mit bestimmten Eigenschaften tun, die sich von den Displays, die sich das Geschaffene dann ansehen, möglicherweise gravierend unterscheiden, geht dadurch nicht weg.

    Trotzdem finde ich die Idee nicht schlecht, sozusagen eine technisch optimale Neutralpalette zu schaffen, wo dann eben nur noch der Einfluss der Displays der unterscheidende Faktor ist.

    Allerdings hätte ich diese Geduld dafür nicht aufgebracht. :rolleyes:^^

    Dass fast jeder seinen Monitor etwas in die Richtung gedreht hatte und hat, wie er/sie es für richtig hält, ist klar.
    Meine Motivation war auch eigentlich nie, eine Anschaupalette für jedermann zu optimieren, sondern eine, mit der man möglichst genau umwandeln kann.:)

    Ja, allerdings ist das ein Effekt, der dafür eigentlich nicht gedacht ist. Das sollte bei ordentlichen PAL-Empfängern funktionieren, tut es aber nicht immer.

    Bei ordentlichen Röhren mit funktionierenden Verzögerungsgliedern für das Abzapfen und Nachverwerten der Farbe jeder Zeile geht das, aber verschiedene Hersteller, gerade im Bereich von Flachbildschirmen oder Röhren mit volldigitaler Bildverarbeitung -also schon die meisten 100 Hz - Geräte- haben das neuzeitlich unterschiedlich interpretiert/implementiert.


    Klar, die sollen die Displays ja auch nicht zeigen. Das ist ja die Essenz von PAL, Farbvektorfehler in Farbsättigungsfehler zu verwandeln.

    Die Kenntnis, dass und vaD. wie zwei Zeilen unterschiedliche Farbfehler haben, hilft,

    a) zu berechnen, wie eine Mischfarbe von zwei unterschiedlichen Farben (gleicher Helligkeit) sein wird

    b) zu berechnen, wie genau die Mischfarbe einer flächigen Farbe sein wid (das, was man auf dem PAL-TV/Monitor sehen wird). Die Abweichungen liegen ja idR. nicht symmetrisch zum eigentlichen Zielwert (das, was auf dem "Chip ist").

    Um ehrlich zu sein habe ich die Drive Sounds im UII+ deaktiviert, da sie sehr unangenehm klingen und so gar nicht wie meine 1541 (deutlich dumpfer)

    Möglicherweise liegt es am Klangkörper in dem kleinen Cartridge.

    Sie waren bei mir by default relativ laut und somit nervig, ja.
    Ich hab die Lautstärke ziemlich runtergedreht und bin eigentlich ganz zufrieden damit.
    Ich "höre", wenn was geladen wird, mehr brauche ich eigentlich nicht.

    Schon den hier gesehen? https://geoffg.net/maximite.html

    Jetzt ja. ;)


    "up to1920x1080 pixels with up to 16 million colours"


    Das halte ich fürs Pixeln von Hand eher unpraktisch.

    Was die erste Generation (bzgl. Farben) wohl zu spartanisch war, schießt die aktuelle über's Ziel hinaus.


    https://en.wikipedia.org/wiki/Maximite

    "Colour VGA with eight colours"

    https://upload.wikimedia.org/w…_with_daughter_board..jpg

    https://geoffg.net/OriginalColourMaximite.html

    Tobias soweit mir bekannt ist, ist 640x480 im HDMI-Standard als "Fallback-Aufloesung" integriert.

    "Die Spezifikation von HDMI schreibt nur 480p und zwei Audiokanäle vor. Alle anderen in der Spezifikation genannten Merkmale sind dagegen optional. Das gilt ausnahmslos für alle HDMI-Versionen."

    https://www.elektronik-kompendium.de/sites/com/1205041.htm

    Wäre trotzdem spannend, ob das auch wirklich noch alle 2K Monitore und TVs akzeptieren und ob die das breitziehen oder schwarze Ränder haben.

    480p geht wohl auch noch. Aber irgend eine handfeste Doku, was HDMI wirklich (nach unten hin) annimmt, gibt es anscheinend nicht, oder doch?

    Ich hab zumindest auch nix brauchbareres gefunden. Wo steht das mit HDMI und 480p? Ist HDMI nicht immer 16:9?

    Ob ein aktueller 16:9 TV auch 480p per HDMI "kennt"?


    Aber mir gefällt 720 ganz gut. Das ist, wie 1080, ein vielfaches von 360 bzw. 180. Und 180 wäre eine schöne Vertikal-Auflösung für Retro-Games. Und für Anwendungen dann halt 360 – das wären 45 Zeilen, wenn man nah genug am Bildschirm sitzt. Das einzige, was an 180 px nervt, ist, dass es kein Vielfaches von 8 ist. Da könnte man sich evt. damit behelfen, dass man jeweils unten und oben 2 schwarze, kaum auffallende Pixelzeilen hätte und als Netto-Auflösung dann 176 Pixel.

    Vielleicht habe ich da zuviel C64 im Kopf, aber weniger Auflösung als beim C64 finde ich schade. Vorwärts immer, rückwärts nimmer. ;)


    Mir ist auch noch keine ideale Auflösung eingefallen, die man nehmen könnte. Im Normalmodus sollten das ca. 320x200 sein, im "Editormodus" 640x400.

    16/9=1.777

    1920/1080=1.777

    320/1.7777=180

    Hmmm....:whistling:

    Hi,


    ich hatte ja schonmal den FLI-Bug angesprochen, der in einem MUIFLI zwangsläufig wieder auftaucht. Hier muss man am linken Rand mit grau leben, einer anderen Farbe und deren geinterlacete Mischfarbe.

    Anbei mal ein paar Beispiele (MUIFLI, Start mit SYS12288).
    Es geht hier um Graustufen des C64, wenn man die Sättigung am Monitor ganz runterdreht. Somit kann man aus den 9 Stufen des C64 durch Interlace und Dithering bis zu 25 verschiedene Helligkeitsflächen erhalten, wenn ich mich nicht verzählt habe.


    Wie auch schon angesprochen, gibt es in Mufflon wohl einen Algorithmus, der Flackern reduziert, indem er flächige Anteile nicht abwechselnd als Vollflächen darstellt, sondern jeweils als Schachbrettmuster, welches im 2. Frame um einen Pixel versetzt ist.

    Zumindest an the real Hardware klappt das nur bedingt gut, was die "Farbechtheit" betrifft. Die derart generierten Flächen passen nicht in der Helligkeit zu dem, was man erwarten würde und man sieht auch deutlich ein Muster.


    Den Dr. Snuggles habe ich bewusst teils in FLI-Bug, teils daneben sehr klein mit nur 3 Helligkeiten gepixelt.
    Eigentlich müsste die geinterlacete Farbe im FLI-Bug die gleiche Helligkeit haben wie Vollfarbe außerhalb. Ist aber nicht so, vielleicht wegen der Generierung der Fläche als Hires-Schachbrettmuster. Black bleed?


    mfg Tobias

    Anbei mal die Trilace Schnellschüsse, die ich damals zum Probieren gemacht hatte.
    Die mit längerem Filenamen sind Optionen, um das Flackern zu minimieren. Ich finde, es flackert zwar anders, aber nicht unbedingt besser. Nur die Farbauflösung wird dabei deutlich reduziert.
    Das mit kurzem Filenamen hat schon eine recht beeindruckende Farbvielfalt finde ich. Flackert eben nicht wenig.


    Ich mache jetzt mal nen neuen Thread auf, wir haben Stefans Crazy Fotos schon genug zugespammt. :)

    Du hast ja selbst gemerkt, dass das Zustandekommen der Sättigung in den Displays unterschiedlich gehandhabt wird.

    Gerade die modernen Displays versuchen, den Farbpegel auf die eine oder andere Weise auf ein Normal zu ziehen.

    Beim 64er ist sowohl der Gesamtpegel wie auch das Verhältnis Burst <-> Pegel "krumm". Also, genau wie alle anderen Bildbestandteile. ;-))

    Ja, aber mich wundert, mit welcher "Intelligenz" die TVs dann trotzden eine "richtige" Sättigung darstellen.

    Beispiel:

    Eine Farbe habe bei einen Burst von 300 mVpp die Sättigung von 450 mVpp.

    Der VIC-II gäbe mal angenommen hier im Beispiel einen Burst von 450 mVpp aus (x1.5) , das Farbsignal von oben mit 1012.5 mVpp (x1.5x1.5). Der Empfänger könnte anhand des Burst ja das Farbsignal linear runterskalieren (/1.5), aber wie "merkt" er, dass das Farbsignal nochmal zusätzlich zuviel Pegel hat?

    Die 330 Ω in der Chroma-Leitung verhindern bei manchen Geräten das Übersteuern des Eingangs, das ist alles.


    Die 75Ω sind aber keine Impedanz sondern das ist der Wellenwiderstand. Da geht es um das Verhindern von Signalreflexionen. Wenn das Kabel mit einem Widerstand abgeschlossen wird, der seinem Wellenwiderstand entspricht, verhält es sich so, als wäre es unendlich lang, es würde also niemals eine Reflexion zurückkommen. Reflexionen sind auch beim analogen TV ziemlich gemein, weil sie, je nach Länge des Kabels, das gleiche Bild zeitversetzt (also weiter rechts bzw. unten) in vermiderter Qualität wieder auf die Leitung bringen.

    Ok. Macht Sinn mit der Dämpfung. Also haben die 330 Ohm erstmal keinen Bezug zum Wert "75 Ohm", richtig?
    Bestimmt wurde der Wert 330 Ohm sicherlich durch Probieren. Hat ja einen einen Grund, warum das keine 5 Ohm oder 5 MegaOhm sind. :D Doch irgendwie muss man doch auch berechnen können, warum der gerade so groß ist (bzw. in dieser Größenordnung) und um wieviel der Widerstand das Ausgangssignal des C64 abschwächt.:whistling:

    Den Subcarrier-Fehler hattest Du ja m.E. auch schon bemerkt (dass der Farbwinkel der angrenzenden Zeile eben nicht genau 180° verdreht ist).

    So würde ich das nicht behaupten, dass ich das bemerkt habe.;)

    Ich bin über die Jahre stets nicht ganz zufrieden mit den gängigen C64-Paletten. Da hatte ich vor gut 20 Jahren erstmal für meine damaligen Konvertierungen auf dem PC per ConGo eine eigene Palette erstellt, weil die Konvertierungen mit der GoDot-Palette am C64 dann deutlich anders aussahen, als am PC.
    Nun hat mich nach etwas Ruhepause der C64 wieder fasziniert und ich habe mich mit dem Thema erneut befasst. Man findet dazu mittlerweile ja eine Menge interessanter und guter Infos im Netz. Nur ist mir da am Ende immer noch zuviel Mystik wie "das sind genau durch 16 bzw. 32 teilbare Helligkeiten bzw. Farbwinkel", "kann man nicht genauer beschreiben", am Bildschirm kommt eh was ganz anderes raus wie am C64 Signal"... Mit dieser Unschärfe kann ich als Naturwissenschaftler schlecht umgehen.8o
    Farben gleicher Helligkeit kann man in PAL zeilenweise gut mischen und bekommt dadurch zusätzliche Farben. Diese Mischfarben sind durch die "schlechte" Ausgabe des C64 unterschiedlich, je nachdem, welche Farbe in welcher Zeile ist. So die Info, was man finden konnte.
    Dazu findet man dann auch eine Seite mit einem Screenshot, aber eine Erklärung oder genauere Beschreibung gibt es nicht für diese Phänomen.
    Dann bin ich auf mathops zeilweise gesampelten Paletten gestoßen. Diese habe ich analyisiert und bemerkt, dass die Farbwinkel (und auch die Farbamplituden) für ungerade und gerade Bildzeilen je nach Lage im Farbkreis um wohl gar nicht so willkürlich festgelegte Zielfarbwinkel pendeln und dass auch bei diesem Pendeln ein "System" dahinter steckt.

    Das habe ich bemerkt, ja. Aber als User am C64 wäre mir selbst nie aufgefallen, dass es da zeilenweise Farbunterschiede gibt.;)
    Mathop hat dazu auch eine Theorie, die mir schlüssig scheint. Der nächste Schritt wäre, die Zeilen-Farb-Abweichungen anhand der Theorie zu berechnen und mit den tatsächlichen Werten zu vergleichen. Ich bin da zuversichtlich.
    Wenn es irgendeine Dokumentation von Commodore/MOS zur Videoausgabe gäbe, wäre es weniger aufwändig, die Signale des VIC-II zu beschreiben. Die Farben und Toleranzen müssen ja irgendwo mal definiert worden sein vor dem Chip-Design.

    Ist aber so auf der anderen Seite auch wieder spannend, das selbst gemeinsam Stück für Stück zu ergründen. 8)

    So kann man mMn. auch die Entwicklung der VIC-Chips nachvollziehen. Z.B. beim 8565R2 merkt man, dass sich Commodore den Zielfarbwinkeln annähern wollte und die Zeilen-Farb-Abweichungen durch Änderungen auf dem Chip (wovon ich Null Ahnung habe) "symmetrischer" gestaltet hat als bei den 6569 Chips. Die beim 8565R2 nochmal reduzierte Sättigung mag nicht jeder C64 Freund.

    ius
    Bist Du Nachrichtentechniker? Zumindest verstehst Du von der Sache deutlich mehr als ich.
    Kannst Du uns mal diesen berühmten 330 Ohm Drosselwiderstand erklären bzw. um wieviel er das Signal abschwächt?
    Mit der 75 Ohm Impedanz des "Empfängers" bildet der in Reihe geschaltete Widerstand einen Spannungsteiler?
    https://www.digikey.de/de/reso…alculator-voltage-divider
    Bei R1=330 Ohm und R2=75 Ohm würden nur noch ~18.5% angekommen.
    Ist das Verständnis so richtig? :whistling: Danke.

    Aber nur, wenn die TVs den Absolut-Farbpegel verwenden und nicht, wie sie es sollen, den Burst als Referenz nehmen.


    Ich hab es nichtmehr ganz im Kopf, da wir mit den VC-20 -Farben etwas abgeschweift sind. Aber ich glaube, das Verhältnis Farbpegel zu Burst war beim C64 Chroma auch deutlich höher, als es für die Farben des C64 angebracht wäre.

    Aber vielleicht ist das Chroma-Signal eines C64G auch nicht mehr ganz so heiß. Da fehlt mir der Vergleich.

    Ich kann mir nicht vorstellen, dass da was geändert wurde.

    Bleibt die Frage: Ist der höhere Signalpegel nun schädlich für das angeschlossene Endgerät (TV) oder wirkt es sich höchstens auf die Farbtreue aus?

    Kaputt geht da nix. Kann halt sein, dass er das Signal gar nicht akzeptiert oder die Farben zu gesättigt sind.