Ich bin so frei, und klaue mir die RGB-Werte des VC20 aus dem Excel, wenn es gestattet ist?
Wird für die Textmodi von VC20 im C64Studio eingesetzt.
Hallo Besucher, der Thread wurde 25k mal aufgerufen und enthält 157 Antworten
letzter Beitrag von androSID am
VC20 Farbpalette als RGB Werte
- aitsch
- Erledigt
-
-
Ich bin so frei, und klaue mir die RGB-Werte des VC20 aus dem Excel, wenn es gestattet ist?
Wird für die Textmodi von VC20 im C64Studio eingesetzt.
Wer sollte Dich daran hindern?
Spaß beisieite. Wir machen den ganzen Aufwand mit den PALettten ja nicht nur zum Selbstzweck, sondern damit möglchst viele User davon profitieren können. Ich denke da z.B. an Emulatoren wie VICE (besonders interessant dürften hier die ODD/EVEN PALettenpaare sein) oder auch Entwickler wie Dich. Meine persönliche Motivation war und ist die Bildkonvertierung von 24bit auf C64-Farben bzw. generell das C64-Pixeln auf Nicht-C64.
Wenn wir die Resultate für uns behalten oder finanziell verwerten wollten, würden wir die Findungsphase sicherlich nicht so detailiert öffentlich führen.
Die aktuellste hier gepostete VC-20 PALette ist aber noch nicht final. Sofern würde ich an Deiner Stelle noch etwas warten bzw. die Option offenhalten, die PALette in C64Studio jederzeit upzudaten.
-
Nachdem ich nun auch mal ein Videokabel bekommen habe, konnte ich meinen letztens erstandenen VC20 auch mal ausprobieren. Das Bild sieht gar nicht so übel aus, wie befürchtet (im Produktbild war er an einem TFT angeschlossen).
Das Backsteinmuster zwischen Rahmen und Hauptscreen ist wohl normal, wenn man andere VC20 Screenshots ansieht.
Pünktlich zum 40. Geburtstag des Geräts bin also auch eher ungewollt zum VC20 Besitzer geworden.
-
Das Backsteinmuster zwischen Rahmen und Hauptscreen ist wohl normal, wenn man andere VC20 Screenshots ansieht.
Dieses "Backsteinmuster" ist genau das, was man mit einem S-Video mod (zum Glück!) wegbekommt.
-
Dieses "Backsteinmuster" ist genau das, was man mit einem S-Video mod (zum Glück!) wegbekommt.
Ich kenne bisher nur den Einschaltbldschirm und da ist es ja nur am Rand.
Muss mal sehen, wie weit ich mit dem VC20 "arbeiten" werde. Habe den ja eher in einer Art Übersprungshandlung gekauft.
Bahnen auf der Platine durchkratzen würde ich eigentlich eher ungern. Wenn, dann käme nur die Variante mit Zwischensockel in Frage.
-
So, ich hab jetzt auch mal das Lumatest Programm gestartet.
Bei mir ist das Cyan etwas dunkler als es soll. Und zwischen hellem lila und hellem orange kann ich keinen Helligkeitsunterschied feststellen. Gibt wohl von Gerät zu Gerät Unterschiede, wie schlimm die Farbe die Hellikeit versaut.
-
Vllt. ist dieser VIC ja noch mehr ein Wackelkandidat als der II.
Was meinst Du mit Wackelkandidat?
Zitat von Bob YannesSince all of this was based on selecting different resistor values and resistance varied from chip lot to chip lot, there was variation from one Commodore 64 to another. It wasn't as bad as it could have been though, since all of the Chrominance selection was based on resistor ratios, which could be kept constant even if the actual resistor values varied. Luminance was more of a problem. A trimmer resistor should really have been used to pull up the output. This would have allowed the Luminance to be adjusted for consistency from unit to unit, however Commodore didn't care enough about consistency to bother with adjusting each unit.
so was
Gibt wohl von Gerät zu Gerät Unterschiede, wie schlimm die Farbe die Helligkeit versaut.
und so was
Den Begriff "Wackelkandidat" hab ich von Johann König.
-
Ein klares Jain.
Yannes bezog sich dabei auf die absoluten Helligkeiten. Die Widerstände auf dem Chip, die für die Helligkeit sorgen, bilden mit dem Gedöns auf dem Board/im Modulator einen Spannungsteiler. Und wenn da jetzt die Chipcharge und/oder die Toleranz des externen Widerstand zusammenkommen, kann die absolute Helligkeit von C64 zu C64 schonmal etwas variiieren. Um das umzugleichen, wäre das Poti auf dem Board gut gewesen.
Die Verhältnisse (Längen) der einzelnen Widerstände der Farben auf dem Chip zueinander bleiben aber gleich. Also bleibt auch die Helligkeitsreihenfolge gleich.Bei VC20 spielen mehrere Dinge ungünstig zusammen:
a) Die Helligkeiten liegen teils sehr nahe beieinander, ist gibt nicht die großen Sprünge/Stufen wie beim C64. Wir sprechen hier teilweise von ca. 1 %!
b) Beim C64 sind die Farbamplituden für alle Farben identisch. Beim VC20 sind sie für alle Farben unterschiedlich, dann nochmal unterschiedlich für helle und dunkle Farben. Macht für die Farbeerzeugung eigentlich Sinn. Aber:
Die Farbinformation schwingt ja um die pro Farbe konstante Helligkeitsinformation. In der Theorie ist der Mittelwert der Farbschwingung also die konstante Helligkeitsinformation. Dreht man die Sättigung runter, dürfte nur noch die Hellligkeitsinformation übrig bleiben. Leider sind die Farbschwingungen nicht immer saubere Schwingungen, die Amplitude variiert über den zeitl. Verlauf und auch eine 100%ige Symmetrie ist nicht immer gegeben.
Daher ist der gemittelte Verlauf der Farbschwingung dann etwas unter/über dem eigentlichen Helligkeitspegel, den der Helligkeitsbereich auf dem Chip vorgibt. Liegen die Helligkeiten eh nah beieinander, kann das die Reihenfolge von Nachbarn schonmal durcheinander bringen.Hab ich das jetzt irgendwie verständlich beschreiben können?
Mit Wackelkandidat hast Du also recht, aber die Helligkeitsabteilung des Chips selbst kann da vermutlich nix für, ein Poti hätte das auch nicht verhindert.
mathop hat ja das Farbsignal bei seinem NTSC-Board abgetrennt, und da bekommt man einen sauberen Helligkeitsverlauf.
VC20 Farbpalette als RGB Werte
Schuld ist wohl der unsaubere Farbanteil, der da reinpfuscht. Ob der Farbschmutz schon bei der Erzeugung im Chip entsteht oder erst bei der externen Zusammenmischung zum Composite-Signal, dafür habe ich zu wenig Nachrichtentechnik studiert.
-
Der NTSC VIC20-CR den ich hier in den USA habe hat das Potentiometer. [via Google Translate]
-
Der NTSC VIC20-CR den ich hier in den USA habe hat das Potentiometer. [via Google Translate]
Ja, die V(I)C20 haben Einstellmöglichkeiten.
Ein C64, auf den sich Bob Yannes bezog, nicht.Indeed, all VIC20 have options to ajust the video signal somehow.
Just all C64s, which Bob Yannes was referring to in his email to Pepto, do not have any possibilities.
-
Ich habe aktuell die Vermutung, dass die (je nach Modell unterschiedlich starken Abweichungen der Helligkeiten) von einem Null-Offset der zugemischten Farbanteile im Composite-Signal veruracht werden.
Die Farbamplitude ist vereinfacht gesagt bei dunklen Farben doppelt soch hoch wie bei den hellen. Wird auch der Farb-Null-Offset bei den dunklen Farben verdoppelt, bekäme man diese "Sägezahn"-Ausreißer, wie man es bei einigen Messungen beobachten kann.
Besonders bei VC20 mit S-Video-Mod sieht der Helligkeitsverlauf bisher stetig aus.
-
Nach etwas Pause wird das hier demnächst zu einem (Zwischen-) Ende gebracht. Ich musste mich erstmal wieder selbst reinfinden.
Bis es evtl. nochmal Verfeinerungen durch zusätzliche Messungen geben wird, werde ich die Modelle für die VIC20 PALette erstellen.
Bei den Helligkeiten wird die Anpassung am besten, wenn ich ausgehend von einer Basishelligkeitskurve NUR auf die dunklem Farben einen Offset addiere. (NICHT auch auf die hellen Farben einen halben Offset, wie im Post darüber))
Ein guter/idealer VIC Chip oder mit S-Video-Mod verhält sich wie die Basiskurve, ein schlechterer wird sich eher wie die Kurve mit dem Offset verhalten.
Damit kann auch erklärt/simuliert werden, warum die Reihenfolge von grün und hellblau je nach VC20 am Bildschrim vertauscht werden müsste.Es wird also zwei Paletten geben, die sich aber nur in den Helligkeiten unterscheiden werden.
Jede dieser Paletten wird dann natürlich noch zwei zusätzliche Paletten für ODD/EVEN haben. Könnte z.B. für Emulatoren ganz witzig sein.
Im Anhang die Helligkeitskurven nach jetzigem Stand. -
Hallo,
was lange währt....
Anbei nun mal die vorerst finale Version der VIC20-PALetten.
Danke an alle, die hier dazu beigetragen haben.
Feedback von VIC20-Usern aus der Praxis wäre natütlich sehr hilfreich.
Danke und ein paar erholsame Feiertage.
Bleibt gesund.
Tobias -
-
[edit - falsche Palette hinuzgefügt - versuche das später nochmal]
-
NTSC VC20 Palette
Danke! Diese Farben sehen gut aus -- ich weiss nicht, aus welcher Quelle ich meine bisherige NTSC-Palette hatte, aber jetzt passt's!
Das Odd-Even-Scanline-"Artefakt" ist PAL-spezifisch, oder tritt das bei NTSC auch auf?
-
-
-
Kannst Du die Rohdaten von der Capture Card bitte auch posten? Am liebsten Farbwinkel.
Dann schaue ich bei Gelegeheit, was es für Analogien zum PAL-VIC1 gibt.
Gibt's hier auch Unterschiede zwischen odd und even?
mfg Tobias
-
Rohdaten:
Alles anzeigenCode- 109 ycbcr: 16 128 128 rgb: 000000 vpp: 0.00 angle: nan
- 110 ycbcr: 16 128 128 rgb: 000000 vpp: 0.00 angle: nan
- 125 ycbcr: 235 128 128 rgb: ffffff vpp: 0.00 angle: nan
- 126 ycbcr: 235 128 128 rgb: ffffff vpp: 0.00 angle: nan
- 141 ycbcr: 62 68 174 rgb: 7e2700 vpp: 0.48 angle: 133 X
- 142 ycbcr: 62 68 174 rgb: 7e2700 vpp: 0.48 angle: 133 X
- 157 ycbcr: 168 198 88 rgb: 71b6ff vpp: 0.49 angle: -39 X
- 158 ycbcr: 168 198 88 rgb: 71b6ff vpp: 0.49 angle: -39 X
- 173 ycbcr: 94 144 196 rgb: c61d7b vpp: 0.53 angle: 80
- 174 ycbcr: 94 144 195 rgb: c61d7b vpp: 0.53 angle: 80
- 189 ycbcr: 149 129 44 rgb: 14de9b vpp: 0.65 angle: -90
- 190 ycbcr: 149 128 44 rgb: 14de9b vpp: 0.65 angle: -90
- 205 ycbcr: 56 210 136 rgb: 3c08d4 vpp: 0.45 angle: 8
- 206 ycbcr: 57 210 136 rgb: 3c08d4 vpp: 0.45 angle: 8
- 221 ycbcr: 187 2 125 rgb: c3fb00 vpp: 0.69 angle: -178 X
- 222 ycbcr: 187 2 125 rgb: c3fb00 vpp: 0.69 angle: -178 X
- 237 ycbcr: 107 34 175 rgb: b56900 vpp: 0.62 angle: 145 X
- 238 ycbcr: 107 34 175 rgb: b56900 vpp: 0.62 angle: 145 X
- 253 ycbcr: 172 93 172 rgb: fba06f vpp: 0.38 angle: 120
- 254 ycbcr: 172 93 172 rgb: fba070 vpp: 0.38 angle: 120
- 269 ycbcr: 159 112 169 rgb: e78b86 vpp: 0.32 angle: 106
- 270 ycbcr: 159 112 169 rgb: e78b86 vpp: 0.32 angle: 106
- 285 ycbcr: 203 156 92 rgb: a1ebff vpp: 0.31 angle: -61 X
- 286 ycbcr: 203 156 92 rgb: a1ebff vpp: 0.31 angle: -61 X
- 301 ycbcr: 170 164 166 rgb: ef87fc vpp: 0.35 angle: 56
- 302 ycbcr: 170 164 165 rgb: ef87fc vpp: 0.35 angle: 56
- 317 ycbcr: 192 100 83 rgb: 85fd94 vpp: 0.38 angle: -114
- 318 ycbcr: 192 100 83 rgb: 85fd94 vpp: 0.38 angle: -114
- 333 ycbcr: 148 182 117 rgb: 888eff vpp: 0.31 angle: -16 X
- 334 ycbcr: 148 182 117 rgb: 888eff vpp: 0.31 angle: -16 X
- 349 ycbcr: 219 56 149 rgb: fff85c vpp: 0.42 angle: 158 X
- 350 ycbcr: 219 56 149 rgb: fff75c vpp: 0.42 angle: 158 X
Also kein Unterschied zwischen odd und even.
