VIC-II Revisionen

Es gab' auf jeden Fall mehr als 3 Revisionen; mir bisher bekannt, weil diese im Umlauf sind:

NMOS:
6569 R1 - 5 Luma

6569 R3 - 9 Luma
6569 R4 - 9 Luma (eher seltene Revision; wurde schnell durch R5 abgelöst).
6569 R5 - 9 Luma

HMOS-II (verbesserter NMOS):
8565 R2 - Grey Dot Bug

Und dann gibt's natürlich noch die ganzen anderen Varianten vom VIC-II für andere Fernsehsystem (z.B. NTSC)

In NTSC we had:

6567 R56A (5 luma levels, very poor contrast and video overall)
6567 R7 (9 luma levels, far improved video output)
6567 R8
6567 R9
I am unsure the differences in R7/8/9, and they all come in both ceramic and plastic DIP. The R56A is only ever in ceramic.

I do not know the revisions of the 8564.

Der 6567R56A hat auch ein anderes Timing, nachzulesen im "VIC article".

Neulich auf Twitter las ich, dass die ersten produzierten VIC-II derart fehlerhaft gewesen sein sollen (bspw. Geflacker statt dem korrekten Bild anzeigen), dass die nahezu allesamt ausgetauscht worden wären damals. Das beträfe sowohl NTSC- als auch PAL-Versionen (was sich für mich unplausibel anhört). Außer vagen Andeutungen konnte ich nichts dazu finden. Weiß hier jemand etwas darüber? Für mich hört sich das nach Gerüchteküche an, evtl. bestärkt durch fünf statt neun Helligkeitsgrade der ersten VIC-II und das fehlerhafte Setzen des Color-RAMs in frühen Kernal-Versionen.

Da gings wohl nur um die Prototypen, die auf Messen vorgeführt wurden (CES ?).

Oder es wurde mit dem VDC verwechselt, der ja genau so eine Geschichte hatte?

Zitat von -trb-

Neulich auf Twitter las ich, dass die ersten produzierten VIC-II derart fehlerhaft gewesen sein sollen (bspw. Geflacker statt dem korrekten Bild anzeigen), dass die nahezu allesamt ausgetauscht worden wären damals. Das beträfe sowohl NTSC- als auch PAL-Versionen (was sich für mich unplausibel anhört). Außer vagen Andeutungen konnte ich nichts dazu finden. Weiß hier jemand etwas darüber? Für mich hört sich das nach Gerüchteküche an, evtl. bestärkt durch fünf statt neun Helligkeitsgrade der ersten VIC-II und das fehlerhafte Setzen des Color-RAMs in frühen Kernal-Versionen.

Da kann es sich eigentlich nur um den "Sparkle-Bug" handeln. Der Auslöser war das Char-ROM.
siehe Sparkle Bug Video bzw. suche Sparkle in diesem Artikel

Zitat von The Joker

Da kann es sich eigentlich nur um den "Sparkle-Bug" handeln.

Das muss es sein. Sparkle war das Wort, das ich in dem Zusammenhang las (mittlerweile aber verdrängt hatte). Danke für die Info.

Zitat von The Joker

Der Auslöser war das Char-ROM.

'Witzig', denn

Zitat von Al Charpentier

If the spike had been a few nanoseconds shorter or longer, it wouldn't have been a problem. The spike was just wide enough that the ROM saw it as a valid address. It would ignore the next address request and give the video chip wrong data.

Anhand der Listen mit den VIC-II-Revisionen, die ich gefunden habe, konnte ich mir nicht vorstellen, dass es am VIC hätte liegen sollen.

Zitat von -trb-

If the spike had been a few nanoseconds shorter or longer, it wouldn't have been a problem. The spike was just wide enough that the ROM saw it as a valid address. It would ignore the next address request and give the video chip wrong data.

Falls es interessiert, der Artikel ist übrigens im Original'n bisschen besser lesbar als in der Wiedergabe auf Matts Seite:

https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf

Zitat von GenerationCBM

Falls es interessiert, der Artikel ist übrigens im Original'n bisschen besser lesbar als in der Wiedergabe auf Matts Seite:
https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf

Wunderbar, dankeschön!

Zitat von The Joker

Da kann es sich eigentlich nur um den "Sparkle-Bug" handeln. Der Auslöser war das Char-ROM.
siehe Sparkle Bug Video bzw. suche Sparkle in diesem Artikel

Sehr interessanter Artikel. Also war das Ur-NTSC-Timing ein Bug.

Spannend finde ich auch, daß der Pixeltakt in letzter Minute erhöht wurde, um auch 40 Zeichen auf bescheidenen Bildschirmen mit sehr großzügigen Overscan zu garantieren. Wie wohl das exakte Timing beim Prototyp ausgesehen hat? Vermutlich insgesamt langsamer mit ca. 360 Pixel pro Zeile (inklusive Rahmen), was bei der Konkurrenz nicht unüblich war.
Atari hatte dieses Problem ja auch bemerkt und sich entschieden, nur 38 Zeichen zu nutzen, und IBM hat das Problem wohl gleich komplett ignoriert, und trotzdem 40 Zeichen genutzt, was auf deren eigenen Monitoren ja auch funktioniert.
Interessanterweise hat Commodore dann beim Amiga dieses Problem ebenfalls ignoriert. Zu dem Zeitpunkt konnte man dann aber wohl auch davon ausgegangen, daß man Bildschirme verwendet, wo man den Overscan passend justieren kann.

Erwähnt wird auch, daß es mal Probleme gab, wo Sprites erst mit bis zu 4 Pixel Verzögerung dargestellt wurden. Gibt es von diesem Bug auch ein Video? Diesen Fehler habe ich noch nie gesehen.

Zitat von CommieSurfer

Wenn man unter Basic 'was mit Sprites macht ("Ballon" aus dem C= Handbuch und auch unendlich weitere Bps.), verschwindet das Sprite in Bewegung ja schonmal für ein oder auch mehr Frame(s), rein optisch.
Also für einen kurzen Moment, zufällig aber immer nur. Wie kommt das eigentl. zustande ?

Das passiert, wenn die Zugriffe auf die Spriteregister "irgendwann" statt zu den richtigen Zeitpunkten erfolgen, es ist also ein Fehler des Programmierers und nicht des VICs. Beispiel: Man ändert die Y-Koordinate des Sprites von 100 zu 95, während der VIC gerade Rasterzeile 96 darstellt. In diesem Frame wird das Sprite also gar nicht dargestellt werden, da die Start-Rasterzeile nie mit der aktuellen übereinstimmt.. Oder man ändert die x-Position von "unter 256" zu "über 255" (oder umgekehrt), wofür ja zwei Registerzugriffe nötig sind: Zwischen diesen beiden Zugriffen gibt es ein Zeitfenster, in dem das Sprite eine x-Position außerhalb des sichtbaren Bereichs hat.
Macht man alle Zugriffe im Rahmen (oder bei Multiplexern über/unter den Sprites), klappt alles wie gewünscht.

Zitat von r.cade

I am unsure the differences in R7/8/9, and they all come in both ceramic and plastic DIP. The R56A is only ever in ceramic.

There's also a R5 (without the '6' appended):

Zitat von CommieSurfer

Ok, verstehe. Aber "Fehler des Programmierers" ist etwas übertrieben, unter Basic kann man es in normaler Machart ja kaum anders lösen.

Mit dem WAIT-Befehl müßte das gehen, aber das würde so ein BASIC-Programm natürlich noch langsamer machen, als es ohnehin schon ist. Man merkt dem BASIC halt an, daß es nicht für solche Sachen gemacht ist. Steht ja auch im verlinkten Artikel, daß man zum einen wegen der ROM-Kosten nicht mehr wollte, und zum anderen auch ohnehin nur das allernötigste an Software im Gerät haben wollte. Da ist es schon fast ein Wunder, daß man das BASIC nicht gleich auf LOAD, RUN und SYS reduziert hat. Dann hätte es sicher noch ins KERNAL-ROM mit reingepasst und man könnte das BASIC-ROM komplett weg lassen. Ein ganzes BASIC könnte man ja als Modul nachrüsten, zumal so ein Modul wegen der Max Machine ja ohnehin entwickelt wurde.

Zitat von androSID

There's also a R5 (without the '6' appended):

[Attach = 151828] [/ attach]

Never seen that in the wild. Is that in a prototype?

Zitat von r.cade

Never seen that in the wild. Is that in a prototype?

No... no prototype. Even SID is in plastic already.