"Für die einen sind es Demos, für die anderen die einzig wahren Applikationen auf der Welt!" ![]()
Mehr Farben vom VIC-II
-
root42 -
9. Februar 2022 um 09:45 -
Erledigt
Es gibt 411 Antworten in diesem Thema, welches 52.420 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Was heißt denn "nur" in einer Demo?

In diesem Fall: alleinig, lediglich, ausschließlich. Steht im Wiktionary sogar an erster Stelle:
Bedeutungen:
generell: unterstreicht die Betonung oder Einschränkung der Satzteilaussage
[1] drückt ausschließlichen Bezug auf einen Fokusbereich ausAber auch die Interpretation "bloß" ist im Hinblick auf die meistens nicht vorhandene Interaktivität bei einer Demo nicht unbedingt verkehrt. Und selbst das bedeutet aber nicht, dass eine Demo weniger wert als eine Anwendung oder ein Spiel sei. Man kann eben nicht alles pauschal vergleichen; das sage ich immer wieder.
-
Ergänzend zur ursprünglichen Idee mit der Schaltung:
Eine Möglichkeit wäre, dass sie alles unterhalb und inkl. der Helligkeitsstufe von "Schwarz" (0) auf "Blank Level" zieht und einen anderen Helligkeitsbereich (bspw. 9, 6 oder 9, 6, 2, B) auf "Sync".
(Eine andere wäre vielleicht das Signal zu invertieren und einen Offset zu addieren, so dass "Weiß" "Sync" ist und "3, 7, f, d" "Blank" und "Schwarz" zu "Ganz Hell" wird. Besser wäre evtl. auch die Zunahme eines anderen Ausgangs o.ä..)
Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
Der Vic hätte somit die Möglichkeit per Farbausgabe ein individuelles Sync Signal zu erzeugen.
In 292 - 312 = 20 Zeilen würde immer "schwarz" (oder "ganz hell" mit Farbe "Schwarz" in der Alternative) ausgegeben werden und die Farbausgabe im Border wäre wahrscheinlich etwas kompliziert.
Jedoch wäre theoretisch mindestens alles, was die Freespin Demo macht, auch möglich.
Links dazu:- Bitte melde dich an, um diesen Link zu sehen.
- Bitte melde dich an, um diesen Link zu sehen. Hier schreibt der Autor: "The first thing I had to do was separate the sync pulses from the video signal and generate a burst gating signal... The sync part of the luminance signal from the C64 ranges from about 0V to 0.3V, so the comparator needs to switch at a threshold of about 0.15V..."
---------------------
Ergänzung zum Testbit:Dass das Testbit im VIC-IIe als Zusatz entstanden ist, ist wegen seiner Funktion und Position einleuchtend und nachvollziehbar.
Trotzdem wäre es doch interessant auszuschließen, dass der VIC irgendwelche anderen versteckten Register oder Funktionen hat:
$d016 Bits 6-7
$d019 Bits 4-6
$d01a Bits 4-7
$d020-$d02e Bits 4-7 (hier unwahrscheinlich, da die Farbspeicher sehr wahrscheinlich nur 4-Bit Breit sind)
$d02f-$d03f Bits 0-7 (Unter Bitte melde dich an, um diesen Link zu sehen. steht "unusable")
Der Aufwand dazu ist gering. (Das könnte jemand mit einem echten C64 machen.) -
Alles anzeigen
Trotzdem wäre es doch interessant auszuschließen, dass der VIC irgendwelche anderen versteckten Register oder Funktionen hat:
$d016 Bits 6-7
$d019 Bits 4-6
$d01a Bits 4-7
$d020-$d02e Bits 4-7 (hier unwahrscheinlich, da die Farbspeicher sehr wahrscheinlich nur 4-Bit Breit sind)
$d02f-$d03f Bits 0-7 (Unter Bitte melde dich an, um diesen Link zu sehen. steht "unusable")
Das haben Heerscharen von Codern schon knapp 4 Jahrzehnte lang gemacht.
Da sind keine großen Überraschungen mehr zu erwarten.
-
Der C64 ist hier ziemlich extrem. Den kann man sowieso schlecht aufzeichnen, aber die Farbvektoren liegen alles andere als präzise 180° versetzt, und das Farbsignal ist insgesamt krumm.
In der Vektorskopdarstellung hast Du zwischen der Mitte und einer einzelnen Farbe (ein Punkt) normalerweise zwei gerade Linien. Beim C64 ist das ein Bogen. Die Effektebei Unterschlagung des PAL-Verfahrens sind vorhersehbar...
Den ersten Teil kann ich durch die Palettenbastelei bestätigen. Odd und even liegen gut 15 Grad Farbwinkel auseinander. Und der Mix liegt auch nicht auf dem Sollwert. Sprich der Fehler ist Farbwinkel-abhängig.
Beim HMOS-II ist dieser Farbwinkelunterschied wesentlich symmetrischer. Der Mix liegt hier fast (bis auf einen fast konstanten Versatz) auf dem Sollwert. Auch die Sättigunsschwankungen sind beim HMOS-II nahezu vernachlässigbar. Beim NMOS schon um die +-10 %.Hast Du evtl. Beispielbilder, die den "Bogen" auf dem Vektorskop zeigen?
mfg Tobias
-
Ergänzend zur ursprünglichen Idee mit der Schaltung:
Eine Möglichkeit wäre, dass sie alles unterhalb und inkl. der Helligkeitsstufe von "Schwarz" (0) auf "Blank Level" zieht und einen anderen Helligkeitsbereich (bspw. 9, 6 oder 9, 6, 2, B) auf "Sync".
(Eine andere wäre vielleicht das Signal zu invertieren und einen Offset zu addieren, so dass "Weiß" "Sync" ist und "3, 7, f, d" "Blank" und "Schwarz" zu "Ganz Hell" wird. Besser wäre evtl. auch die Zunahme eines anderen Ausgangs o.ä..)Die Helligkeiten werden im VIC-II durch Widerstandsbahnen erzeugt. Es gibt 3+1 Widerstände. Der "1"e ist schwarz. Kein Widerstand = unendlicher Widerstand ist weiß.
Beim R1 kann man jeden der 3 Widerstände nur jeweis getrennt anschalten. Macht die 3 Ziwschenhelligkeitsstufen.
Bei den anderen VIC-II kann man die 3 Widerstände miteinander kombinieren.
mfg Tobias
-
Hast Du evtl. Beispielbilder, die den "Bogen" auf dem Vektorskop zeigen?
Ich such' mal in den Handyfotos. Im April besuche ich auch mal meine alte Arbeit und suche Kellerschrott raus, evtl. ist ja ein altes funktionierendes Electronic Visuals abkömmlich...

Edit: Nee, nüscht. Nur Luma & Filters Flat, keine Vektorskopfotos. Erinnere mich aber gut dran; wie gesagt, ich probiere demnächst mal, ein EV-4061 mitzunehmen.
-
Dass das Testbit im VIC-IIe als Zusatz entstanden ist, ist wegen seiner Funktion und Position einleuchtend und nachvollziehbar.
Mir ist es nicht einleuchtend. Wird das vom Betriebssystem gebraucht? Warum sah man eine Notwendigkeit, das einzubauen? Warum ist das so spärlich dokumentiert?
Trotzdem wäre es doch interessant auszuschließen, dass der VIC irgendwelche anderen versteckten Register oder Funktionen hat:
Es wäre wohl auch beim Analysieren der Die-Shots aufgefallen, wenn da noch was versteckt ist.
-
Dass das Testbit im VIC-IIe als Zusatz entstanden ist, ist wegen seiner Funktion und Position einleuchtend und nachvollziehbar.
Mir ist es nicht einleuchtend. Wird das vom Betriebssystem gebraucht? Warum sah man eine Notwendigkeit, das einzubauen? Warum ist das so spärlich dokumentiert?
Ich finde es einleuchtend, dass zusätzliche Register hinzugefügt wurden, um den Kern des VIC nicht zu verändern (wegen der Kompatibilität, dem Änderungsaufwand o.ä..).
Dass es keine Dokumentation des Test-Bits gibt, könnte unterschiedliche Ursachen haben- Kein direkter Nutzen für den Benutzer vorhersehbar/sichtbar (vgl. Dokumentation der Test-Bits beim SID)
- wurde wahrscheinlich nur für Qualitätssicherung oder den Fertigungsprozess benötigt.
- Evtl. Trivialitäten: Deadlines für Doku, Last Minute Änderungen o.ä.
- Eher Unwahrscheinlich: Damit keine inkompatiblen C64-Programme geschrieben werden oder Programme den Computer "beschädigen" bzw. aufhängen.
Eine Suche nach $d030 in Bitte melde dich an, um diesen Link zu sehen. lieferte nur Stellen, in denen direkt eine #0 oder Bitte melde dich an, um diesen Link zu sehen. (für die 2 MHz) hineingeschrieben wurden bzw. findet man auch eine Übertragung von Speicherstelle $0a37.
Diese wird beim Starten des Rechners auf 0 gesetzt. Ob auch das Test-Bit in diese Speicherstelle geschrieben wird, kann ich nicht sagen.
Die Kommentare um den Code für $d030 handeln von Initialisierungen, Synchronisierungen, Timing, Tape und RS-232.
Es gibt zwei Stellen, in denen auch von $d030 gelesen wird.
Eine Stelle ist Bitte melde dich an, um diesen Link zu sehen., weil dort noch ein AND #$01 steht, d.h. dass man hier wusste, dass andere Bits (oder ein Rauschen oder "1"er ?) vorhanden sind, die ausmaskiert werden müssen.
Die Adresse $d02f wird leider nur beschrieben, sonst hätte man evtl. Rückschlüsse auf die Handhabung mit den ungenutzten Bits ziehen können.
Könnte es nicht sein, dass das Test-Bild beim Starten des Computers gesetzt ist und dann durch die Initialisierungsroutine des Kernals gelöscht werden muss, d.h. ein verzögertes Einschalten des VIC-Chips war gewünscht...
Hier könnte es die unterschiedlichsten Ursachen geben:- Aufblitzen des Bildschirms beim Einschalten vermeiden
- evtl. angeschlossene Hardware kommt beim Starten in Konflikt mit dem VIC
- Der Rest des Mainboards muss vor dem VIC versorgt sein etc. pp...
Der Fantasie sind keine Grenzen gesetzt....
-------
Ich dachte zum VIC gäbe es keine Die-Shots? Okay, habe sie gefunden: Bitte melde dich an, um diesen Link zu sehen. - Kein direkter Nutzen für den Benutzer vorhersehbar/sichtbar (vgl. Dokumentation der Test-Bits beim SID)
-
So, ich hab mal die magic Farben reingehakt.
Komischweise kann ich bei mir keinen Unterschied sehen, ob nun odd/even oder even/odd.
Auch kommt es wieder bei Schachbrettmustern zu komischen Moirees bei mir. Ich hab die Pixel dann nochmal doppelt breit gemacht, bringt aber auch nix. Ist nur anders schlimm.
Ist das bei Euch am echten C64 und CRT auch so?

mfg Tobias
SYS12288
-
Komischweise kann ich bei mir keinen Unterschied sehen, ob nun odd/even oder even/odd.
So sollte es ja auch sein. Wenn es einen Unterschied gibt, ist das Mischverhältnis nicht optimal justiert. Ein Grafiker sollte sich jedenfalls nicht darauf verlassen, daß die unterschiedlich sind, aber dennoch damit rechnen, daß es so sein kann.
-
- Offizieller Beitrag
Komischweise kann ich bei mir keinen Unterschied sehen, ob nun odd/even oder even/odd.
Speziell bei dem Braun/Blau ist doch eindeutig ein Unterschied zu sehen. Allerdings deutlich weniger als bei mir – und vor allem viel heller.
-
Hier gibt es ein subtiler Unterschied zwischen odd/even und even/odd.
Kein CRT sondern Captures mit und ohne comb-Filter.
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
-
Naja dass nicht jeder Flachfernseher das evtl. gleich gut hinbekommt mag ja sein - aber es ging ja jetzt um das Argument, dass SEIN Fernseher ja ein Flachfernseher sei, und daher sei es unmoeglich, dass er hier PAL-Mixing verwendet, weil das ja nur auf CRTs ginge.
...dass dieser "Jason" einen TFT hat, der das PAL-Bild vernuenftig anzeigt. Von daher ist die Aussage, es koenne kein PAL-Mixing sein, weil er ja keinen CRT verwendet, unsinnig.
Man kann es auch übertreiben, mit dem drauf herumreiten.

Ich dachte da in erster Linie auch nur an von eben der Crt Röhre selbst erzeugte z.B. Farbmischeffekte von zwei nebeneinanderliegenden Pixeln*, nicht diesen anderen (ich persönlich nie real gesehenen Trisckserei Krempel mit Interlace Bildern, das wären dann ja nur hoschgezüchtete Demos) Kram. Und das kann halt nur eine Röhre und kein Flach TV. Das meinte ich.
*Weil die Pixel leuchten, je nach Farbe mehr oder weniger das nebenstehende überstrahlend. Auch das ist bei einem Flach TV kaum bis eher nicht so. Diese so entstehende Mischfarbe dann nachzustellen, kann ein Flach TV unmöglich hellseherisch vorherahnen. Dazu müsste er schon in der Quantenintelligenzwelt, oder so, intern zu Hause sein, um das haargenau vorherberechen zu können, wie ein Röhrenbild von außen betrachtet in jedem Moment aussähe
.---
Bisher habe ich btw. auch noch keinen Flach TV gesehen, der wirklich sync deinterlacen kann. Irgendwann nach mehreren Sekunden zuckt der z.B. Text-Scroller dann doch. Weil der Flach TV nicht progressiv 1:1 wie 'ne Röhre arbeitet.
Der Röhre ist das etwas krumme non PAL konforme 50Hz eines u.a. C64 daher egal - wird von einer solchen einfach so genommen und dargestellt wie's ankommt.
-
So, ich hab mal die magic Farben reingehakt.
Komischweise kann ich bei mir keinen Unterschied sehen, ob nun odd/even oder even/odd.
Auch kommt es wieder bei Schachbrettmustern zu komischen Moirees bei mir. Ich hab die Pixel dann nochmal doppelt breit gemacht, bringt aber auch nix. Ist nur anders schlimm.
Ist das bei Euch am echten C64 und CRT auch so?

mfg Tobias
SYS12288
Ich bekomme deine Programme zum Verrecken nicht zum laufen. Laden und dann SYS12288 macht nix. RUN macht nix. Was muss ich da tun?
-
So sollte es ja auch sein. Wenn es einen Unterschied gibt, ist das Mischverhältnis nicht optimal justiert. Ein Grafiker sollte sich jedenfalls nicht darauf verlassen, daß die unterschiedlich sind, aber dennoch damit rechnen, daß es so sein kann.
Messtechnisch liegen die Farben ja nach Zeile beim C64 aber nicht unerhelblich auseinander. Also macht es zumindest theortisch einen Unterschied, in welcher Reihenfolge man die beiden Farben jeweils kombiniert.
Speziell bei dem Braun/Blau ist doch eindeutig ein Unterschied zu sehen.
Ja, das stimmt. Ich war wohl wieder zu fixiert auf das Moiree der Hölle.

Allerdings deutlich weniger als bei mir – und vor allem viel heller.
Du hast wieder den 6569R3 benutzt? Heller als?
Hier gibt es ein subtiler Unterschied zwischen odd/even und even/odd.
Kein CRT sondern Captures mit und ohne comb-Filter.
Danke mathop. Mein Screenshots sind von einem 6569R5 im C64II.
Ich muss das mal an nem 1802 anschauen, vielleicht "glättet" mein SONY CRT TV die Farben ja etwas mehr, als er in diesem Fall sollte.
Ist der Capture vom 8565R2 heller oder nur blasser?
Jedenfalls scheint das Moiree-Muster vom VIC-II zu kommen und nicht nur von meinem C64 und/oder meinen Monitoren.
mfg Tobias
-
Alles anzeigen
So, ich hab mal die magic Farben reingehakt.
Komischweise kann ich bei mir keinen Unterschied sehen, ob nun odd/even oder even/odd.
Auch kommt es wieder bei Schachbrettmustern zu komischen Moirees bei mir. Ich hab die Pixel dann nochmal doppelt breit gemacht, bringt aber auch nix. Ist nur anders schlimm.
Ist das bei Euch am echten C64 und CRT auch so?

mfg Tobias
SYS12288
Ich bekomme deine Programme zum Verrecken nicht zum laufen. Laden und dann SYS12288 macht nix. RUN macht nix. Was muss ich da tun?
SYS12288 eingeben. Ist ein NUFLI.
-
Alles anzeigen
Naja dass nicht jeder Flachfernseher das evtl. gleich gut hinbekommt mag ja sein - aber es ging ja jetzt um das Argument, dass SEIN Fernseher ja ein Flachfernseher sei, und daher sei es unmoeglich, dass er hier PAL-Mixing verwendet, weil das ja nur auf CRTs ginge.
...dass dieser "Jason" einen TFT hat, der das PAL-Bild vernuenftig anzeigt. Von daher ist die Aussage, es koenne kein PAL-Mixing sein, weil er ja keinen CRT verwendet, unsinnig.
Man kann es auch übertreiben, mit dem drauf herumreiten.

Ich dachte da in erster Linie auch nur an von eben der Crt Röhre selbst erzeugte z.B. Farbmischeffekte von zwei nebeneinanderliegenden Pixeln*, nicht diesen anderen (ich persönlich nie real gesehenen Trisckserei Krempel mit Interlace Bildern, das wären dann ja nur hoschgezüchtete Demos) Kram. Und das kann halt nur eine Röhre und kein Flach TV. Das meinte ich.
*Weil die Pixel leuchten, je nach Farbe mehr oder weniger das nebenstehende überstrahlend. Auch das ist bei einem Flach TV kaum bis eher nicht so. Diese so entstehende Mischfarbe dann nachzustellen, kann ein Flach TV unmöglich hellseherisch vorherahnen. Dazu müsste er schon in der Quantenintelligenzwelt, oder so, intern zu Hause sein, um das haargenau vorherberechen zu können, wie ein Röhrenbild von außen betrachtet in jedem Moment aussähe
.---
Bisher habe ich btw. auch noch keinen Flach TV gesehen, der wirklich sync deinterlacen kann. Irgendwann nach mehreren Sekunden zuckt der z.B. Text-Scroller dann doch. Weil der Flach TV nicht progressiv 1:1 wie 'ne Röhre arbeitet.
Der Röhre ist das etwas krumme non PAL konforme 50Hz eines u.a. C64 daher egal - wird von einer solchen einfach so genommen und dargestellt wie's ankommt.
Mir gings nicht drum, drauf herumzureiten, ich wollte nur spezifizieren, was genau meine Aussage war, da es offenbar ein Missverstaendnis gab.
Zum Thema selbst, vermutlich wird ein TFT nicht "haargenau vorherberechnen" was ein CRT macht (sonst waere jeder TFT ja ein hervorragender CRT-Emulator), aber irgendwas wird er tun, um ein PAL-Bild moeglichst korrekt anzuzeigen. Es waere mal interessant, wenn jemand auf einem TFT z.B. Mayhem in Monsterland spielen koennte und davon ein Foto machen koennte. Oder eine der juengst geposteten Farbmisch-Demos.
Auf der anderern Seite, wenn TFTs im allgemeinen wirklich null Anstrengungen unternehmen wuerden, um da irgendwas zu "richten" - was waere denn dann ueberhaupt eine moegliche Erklaerung fuer Jasons Technik? Also wenn das jetzt etwas waere, was NUR auf einem TFT ginge (er selbst hat es ja bisher nur auf TFTs demonstriert), was sollte das denn dann ueberhaupt sein? Ich denke es waere wirklich das sinnvollste, wenn jemand mal die Probe aufs Exempel machen koennte und ein bekanntes Farbmisch-Demo oder -Spiel auf einem echten C64 an einem TFT zeigen koennte, dann wuessten wir schonmal mehr und wuessten auch, zu was ein TFT in der Lage ist.
-
Zum Thema selbst, vermutlich wird ein TFT nicht "haargenau vorherberechnen" was ein CRT macht (sonst waere jeder TFT ja ein hervorragender CRT-Emulator), aber irgendwas wird er tun, um ein PAL-Bild moeglichst korrekt anzuzeigen. Es waere mal interessant, wenn jemand auf einem TFT z.B. Mayhem in Monsterland spielen koennte und davon ein Foto machen koennte. Oder eine der juengst geposteten Farbmisch-Demos.
Im Detail reagieren unterschiedliche Monitore, vaD. vom Funktionsprinzip, unterschiedlich. Und nochmal unterschiedlich für Composite und S-Video.
Anbei mal ein paar Screenshots.
Leider hab ich bei dem anderen Monitor die zweite Bildversion genommen. Vielleicht hole ich das nochmal nach für alle Kombinationen.
Auf dem TFT sieht man mit S-Video auch im Startbildschirm ein schönes Schachbrettmuster. Am CRT gar nicht. Der HP TFT mochte das S-Video-Signal afair nicht wirklich.
mfg Tobias
-
Man sieht auf jeden Fall, dass die meisten Mischfarben, die durch horizontale Linien erzeugt wurden, absolut homogen erscheinen. In dem Fall muessen Deine TFTs ja irgendeine "Magic" machen, die dem entspricht, was auf einem CRT auch passieren wuerde.
-