VSP

VSP (Variable Screen Positioning, auch bekannt als DMA Delay) ist ein undokumentierter Effekt des VIC-II-Chips und ermöglicht horizontales Scrollen, ohne dass größere Mengen Daten beim Scrollen umkopiert werden müssen - anders als das bei den dokumentierten Möglichkeiten des VIC-II nötig ist (XSCROLL, $D016).

Das vertikale "Gegenstück" zu VSP ist unter dem Begriff "Linecrunching" bekannt.

Eine Kombination dieser beiden Effekte wird auch mit AGSP (Any Given Screen Position") bezeichnet, um den Screen beliebig in X- und Y-Richtung zu scrollen.

Technik

In kurz ist der Ansatz, den VIC-II inmitten einer Zeile vom Idle State in den Display State springen zu lassen und ihn den am Ende des Anzeigefensters dann ungewöhnlicherweise um weniger als 40 Bytes inkrementierten VC-Zähler in Takt 58 als neuen Zeilenanfang VCBASE speichern zu lassen, woraufhin der Bildschirm im Folgenden entsprechend verschoben angezeigt wird.

Dabei sind mehrere Dinge zu beachten (Details siehe vic-ii.txt, insbesondere "3.5. Bad Lines", "3.7.1. Idle state/display state" sowie "3.7.2. VC and RC"):

• Am Anfang der Zeile muss der VIC-II im Idle State sein (ansonsten würde VC ganz normal ab Anfang des Anzeigefensters inkrementiert werden und somit am Ende die normalen 40 Bytes erreichen), RC jedoch auf 7 gesetzt sein (ansonsten würde VC später in Takt 58 nicht in VCBASE übernommen werden), und es darf kein Badline-Zustand vorliegen (ansonsten würde sofort der Display State ausgelöst).
  • Das lässt sich am einfachsten für Zeile 48 erreichen: Bis inkl. Zeile 47 gab es noch keine Badlines, also ist der VIC-II weiterhin im Idle State; RC ist noch auf 7 vom Ende des letzten Frames; durch entsprechendes Setzen von YSCROLL vor Zeile 48 (auf ungleich 0) lässt sich der Badline-Zustand in Zeile 48 verhindern.
• Das Auslösen der Badline inmitten der Zeile und damit die Transition in den Display State muss taktzyklusgenau sein (siehe Raster-Timing), weil sich daraus die Verschiebung ergibt.
  • Das Auslösen der Badline geschieht durch entsprechendes Setzen von YSCROLL, in Zeile 48 also auf den Wert 0.

Typisches Einsatzgebiet ist das horizontale Scrolling bei einem Platformer-Spiel. Gemeinsam mit dem Pixel-Scroll-Register des VIC (XSCROLL, $D016) kann nach 8 Pixel des Fine-Scrollings der Bildschirminhalt effizient per VSP "weitergeschaltet" werden. Typischerweise muss nur eine neue Spalte aufgebaut werden (inklusive jener in einem Double-Buffer sind das rund 2x25 Byte).

Die Belastung des Systems ist dabei recht gering, denn man benötigt lediglich ein stabiles Timing für Rasterzeilen-Interrupt am oberen Rand des Schirms und weitere Raster-Interrupts, um die neue Bildspalte zeitlich verteilt aufzufüllen (für Zeichen und Farbe). Der aufwändigere Teil ist dann am Bildschirmende, wenn auf den anderen Double-Buffer-Screen umgeschaltet wird. Für den Zeichen-Screen reicht zwar das Umsetzen eines VIC-Registers, aber das Farb-RAM muss vollständig umkopiert werden.

Bug

Bei bestimmten VIC-Revisionen und Boards kann es vorkommen, dass die Nutzung von VSP das RAM-Refresh des VIC stört. Genauer kann dies bei dieser Hardware immer vorkommen, wenn das Registers $D011 des VIC zu einem ungünstigen Zeitpunkt geändert wird. In diesem Fall kann es passieren, dass einige Speicherzellen die Werte von anderen Speicherzellen annehmen, was zu Fehlern und insbesondere auch zum Absturz des Computers führen kann. In selten Fällen ist es wohl sogar möglich, dass dadurch die Hardware beschädigt wird.

Beschreibung des Bugs

Das DRAM des C64 (die acht Bausteine, die den Speicher des Computers bilden) kann Daten nur für sehr kurze Zeit speichern (im Bereich von Mikrosekunden). Damit die Daten nicht verloren gehen, müssen sie in regelmäßigen Abständen neu geschrieben werden. Dies passiert automatisch jedesmal, wenn die Daten gelesen werden und dann sogar für die ganze Speicherseite (256 Bytes), die das gelesene Byte enthält, auf einmal. Da aber nicht garantiert werden kann, dass der Prozessor jede Speicherseite oft genug liest, übernimmt der VIC diese Aufgabe: Zu bestimmten Zeiten liest er nach einem bestimmten Schema einfach eine Seite aus und verwirft das Ergebnis. Dadurch ist sichergestellt, dass jede Seite oft genug gelesen (und damit erneut geschrieben) wird.

Für diese Zugriffe nutzt der VIC zwei unabhängige Leitungen: Zum einen wird die Adresse der Speicherseite auf den Bus gelegt und zum anderen wird das RAS-Signal (Row Address Strobe) gesendet. Dies passiert im VIC unabhängig voneinander an ganz unterschiedlichen Stellen im Baustein.

Direkt nach einer Änderung von Register $D011 kommt der VIC kurz durcheinander und schreibt zuerst %11111111 auf den Bus und direkt darauf %00000111. Das führt dazu, dass die ersten fünf Bits auf dem Bus keinen definierten Zustand haben, sondern zwischen 0 und 1 "hin- und herflackern", wenn das RAS-Signal gesendet wird. Dadurch kann es passieren, dass das Auslesen des Speichers auf anderen Speicherzellen passiert, als das Zurückschreiben direkt danach, was nichts anderes bedeutet, als dass die Daten von einer Speicherzelle in eine andere kopiert wurden.

Bug beheben

Es handelt sich bei dem Bug um einen Hardware-Bug. Dementsprechend kann der Bug auch nur auf Hardware-Seite behoben werden.

Üblicherweise lässt sich der Bug beheben, indem man andere RAM-Bausteine (kein DRAM) oder einen anderen VIC-Chip verwendet.

Bug am C64 Reloaded

Auf einem C64 Reloaded findet sich mitunter der VSP-Bug.

• Ein C64 Reloaded MK1 ist mit neueren VIC-II (8565) nicht 100%ig VSP-sicher.
• Ein alter VIC-II (6569) ist dagegen auf dem Reloaded MK1- 100%ig VSP-sicher.

VSP-Tests

Thema: C64 Reloaded / Bugs / Auffälligkeiten auf Forum64.de zeigt konkrete Tests

VSP-Bug beheben

• Das RAM durch SRAM (Umbau C64 auf SRAM) ersetzen. Es gibt auch eine SRAM-Platine, welche einfach in die RAM-Sockel der Reloaded-Platine passt.
• Beim VIC 8565R2: Neben der Lösung einen 6569-VIC einzusetzen, gibt es auch eine kleine Zusatzplatine, welche in den GAL-Sockel gesteckt wird und so ein verändertes Timing erzeugen kann, damit auch der 8565R2 keine VSP-Probleme mehr verursacht. 8565R2)

Den Bug via Software umgehen

Man kann Software so schreiben, dass der VSP-Bug keine Auswirkungen hat: Hierfür muss entweder sichergestellt werden, dass alle Speicheradressen jeder Speicherseite die auf 7 oder F enden, den gleichen Inhalt haben, oder dass diese nie genutzt werden, beispielsweise indem sie mit einem illegalen Opcode (NOP immediate) im Programmablauf übersprungen werden. Im Falle von Daten kann man diese Adressen auch rechtzeitig aus einer Sicherung wieder zurückschreiben. Das führt allerdings zu stark unleserlichem Code und zudem zu einer deutlich spürbaren Verlangsamung des Computers.

Seit einigen Jahren kursiert auch die Theorie der VSP-Channel. Mit Hilfe dieser Channel kann man die problematischen Teile des Speichers weiter eingrenzen. Kennt man die betroffenen Channel, müssen nicht mehr alle Speicheradressen, die auf 7 oder F enden berücksichtig werden. Allerdings kann man bis heute nicht genau sagen, wovon diese Channel genau abhängen. Unter anderem wird vermutet, dass physikalische Eigenschaften (zum Beispiel die Themperatur) beim Einschalten des Computers einen Einfluß darauf haben.

In der Praxis dürfte es sinnvoller sein, den VSP-Bug bei der Programmierung zu ignorieren. Hardware mit diesem Bug sollte auf Hardware-Ebene repariert werden.

Weblinks

• CSDb: VSP lab V1.1 (2013) Image vsplab-1.1.d64 mit Testwerkzeug, um einen VSP-Bug auf C64-Hardware festzustellen.

Blöder Anti-Missbrauch. Jetzt ist alles, was ich hier geschrieben habe, wieder weg. Hier die Links. Auf den Rest hab' ich keine Lust mehr.

https://kodiak64.com/blog/future-of-VSP-scrolling https://www.linusakesson.net/scene/safevsp/index.php

Sonstiges

In der Zeittafel der C64-Demos wird versucht, die wichtigsten Demos, bei denen Effekte wie diese zum ersten Mal verwendet wurden, in chronologischer Form zusammenzutragen.