Sender: boose@unixserv.rz.fh-hannover.de
Received: from deneb.dfn.de by dub-img-1.compuserve.com (8.6.9/5.941228sam)
        id GAA07567; Mon, 16 Jan 1995 06:49:15 -0500
Received: from unixserv.rz.fh-hannover.de (rzgw.rz.fh-hannover.de) by
deneb.dfn.de (4.1/SMI-4.2)
        id AA01063; Mon, 16 Jan 95 12:47:15 +0100
Received: by unixserv.rz.fh-hannover.de (AIX 3.2/UCB 5.64/4.03)
          id AA22748; Mon, 16 Jan 1995 12:47:36 +0100
Date: Mon, 16 Jan 1995 12:47:36 +0100 (NFT)
From: Andreas Boose <boose@unixserv.rz.fh-hannover.de>
Subject: VC/RC
To: 100112.220@compuserve.com
In-Reply-To: <941124202434_100112.220_BHA82-3@CompuServe.COM>
Message-Id: <Pine.3.89.9501161230.B31952-0100000@unixserv.rz.fh-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hallo Wolfgang!

Wir diskutieren schon die ganze Zeit in einer lokalen deutschen Gruppe
über den VIC und dessen VC/RC. Es ist wirklich interessant, kannst Du sie
nicht lesen? Im folgenden Artikel hat Christian (er programmiert einen
C64-Emu auf dem Amiga, der jetzt verbessert wird.) mal einen kleinen
Zwischenstand über den VC/RC zusammengefaßt, mit dem wir jetzt schon ALLES
$d011-mäßige, was auf allen 64'ern läuft, erklären können.

Es sind aber noch nicht die endgültigen Definitionen, da muß noch dran
gefeilt werden, aber Du sollstest schon mal so einen Überblick bekommen,
wie der VC/RC implementiert werden sollte, damit alle Tricks
funktionieren. Erfreulicher Weise ist Christian auch zu dem Schluß
gekommen, daß es 2 VCs gibt. :-)

Wenn von X-Koordinate die Rede ist, so ist das die Sprite X Koordinate,
die 24 Pixel vor der linken Rahmengrenze liegt.

Und was habe ich gehört, Compuserve soll billiger werden?

MfG Andreas


Empfaenger : /Z-NETZ/RECHNER/C64+C128/HARDWARE
Absender   : Cebix@NG-BOX.WWB.SUB.DE  (Christian Bauer)
Betreff    : Re: VIC-Interna
Datum      : Do 12.01.95, 19:16  (erhalten: 15.01.95)
Groesse    : 7894 Bytes
----------------------------------------------------------------------
A.BOOSE@LDB.han.de (Andreas Boose) schrieb am 10.01.1995
zum Thema "Re: VIC-Interna" folgendes:

AB> Hast Du Dir denn schonmal Gedanken gemacht, wo die Zeile mit den @@@@@
AB> abgeblieben ist? ;-)

Das ist einfach. In Zeile $33 machst du den #$19->$d011 vor X-Koord. 0,
also wird das Display eingeschaltet ($d011 steht noch auf #$1b von
Zeile 255, also Bad Line Condition), aber der RC wird nicht auf Null
gesetzt und es werden keine neuen Zeichenzeiger geholt, also stellt er
die 7.Pixelzeile der letzten Bildschirmzeile dar (man sieht sie ja auch
noch oben als Leerzeile, wenn man vorher ein POKE16383,255 macht) und
bei X-Koord. $160 wird das Display wieder abgeschaltet, da der RC auf 7
steht (warum der VC um 40 erhöht wird, siehe unten).

AB> [Cebix' VC-Schrott gelöscht]
AB> Wie willst Du das mit einem sich stetig erhöhenden VC erklären?

Gar nicht (beim Bitmap-Modus würde das sowieso total fehlschlagen).
Ging mir ja auch weniger um den VC, als um die Tatsache, daß VC und
40-Zeichen-Puffer-Adressierung getrennt sind und nicht irgendwie
durch (VC MOD 40) gewonnen wird. Aber das ist ja evident.

AB> Ich habe für sowas mal ein Testprogramm geschrieben [...]
AB> Der VC liest also zwei mal ab $0400, der FLI Effekt. Erklär' das mal mit
AB> einem VC, der auch noch synchron zum "Zähler im internen 40-Byte-
AB> Zeichenpuffer" erhöht wird. :-)

Hier ist meine neue, zusammengefaßte RC- und VC-Definition (tataaa! :-):

1. Eine "Bad Line Condition" ist, wenn RASTER >= 48 und RASTER < 248
   und die unteren drei Bits...etc... (wie gehabt).

2. Tritt eine Bad Line Condition ein, egal wann, wird das Display
   eingeschaltet. Dies kann auch mitten in einer Zeile geschehen.
   "Display ein" heißt bei mir, daß er innerhalb der Textspalte nicht
   $3fff darstellt, sondern Textzeichen oder Bitmap.

3. Der VC läßt sich nicht widerspruchsfrei durch ein einziges
   Register beschreiben, es müssen zwei sein. Ich nenne sie hier
   mal VCBASE und VCCOUNT, die beide 10 Bit breit sind. VCBASE ist
   ein einfaches Datenregister, VCCOUNT hat zusätzlich einen Zähleingang.
   Das "VC", das auf den Adreßbus gelegt wird, ist immer VCCOUNT.

4. Der RC ist ein einfacher 3-Bit-Zähler mit Reset. Er entspricht
   direkt dem "RC" auf dem Adreßbus.

5. Beim VBlank wird VCBASE auf Null gesetzt, RC bleibt unverändert.

6. Bei Takt 0 jeder Zeile wird VCBASE->VCCOUNT gemacht.

7. Liegt bei Takt 0 eine Bad Line Condition vor, wird der
   RC auf Null gesetzt.

8. Das Lesen der Zeichenzeiger (Videomatrix-Zugriff) wird gestartet,
   wenn eine Bad Line Condition vorliegt und der Takt zwischen
   0 und 39 liegt. Es wird bei Takt 40 gestoppt.

9. Ist das Display an, wird in der Textspalte auf den Grafikspeicher
   zugegriffen (mit VCCOUNT in der Adresse) und nach jedem Zugriff
   VCCOUNT um eins erhöht (dies gilt sowohl für Text als auch Bitmap).
   Ist das Lesen der Zeichenzeiger aktiv, werden auch die Daten aus
   der Videomatrix (und dem Farbram) in den 40-Zeichen-Puffer gelesen.
   Das VCCOUNT-Erhöhen ist aber an den Grafikzugriff gekoppelt.

10. Bei Takt 44 wird geprüft, ob der RC = 7 ist. Wenn ja wird das
    Display ausgeschaltet und VCCOUNT->VCBASE gemacht. Danach wird geprüft,
    ob das Display eingeschaltet ist. Wenn ja, wird der RC um eins erhöht.
    Hinweis: Liegt eine Bad Line Condition vor, ist das Display _immer_
    eingeschaltet. Der RC wird dann auch noch erhöht, wenn er auf 7 steht.
    Es sei auch darauf hingewiesen, daß man durch diesen Mechanismus
    keine "ADD 40"-Hardware beim VC braucht.

Puh! Wenn ich nichts übersehen habe und alles so beschrieben ist, wie
ich es meine, sollte das die endgültige RC- und VC-Definition sein.
Zumindest kann ich _alle_ Effekte, die deine beiden D011-Test-Programme
hervorbringen, damit erklären (außer den drei $ff und den wilden
Verknüpfungen natürlich), auch wenn man bei beiden Programmen den
Bitmap-Modus einschaltet (dann sieht man sowieso viel besser, was abgeht,
da der VC in jeder Zeile benötigt wird) und wenn man aus dem
dekrementiellen einen inkrementiellen D011-Effekt macht.

Die beschriebenen Algorithmen sind mit ein paar Zählern, Komparatoren
und Flipflops leicht in Hardware umzusetzen.

Interessant ist auch, daß es in beiden Programmen genau eine Stellung
gibt, in der die erste Bad Line Condition gar nicht eintritt, wenn
nämlich das #$18->$d011 genau dann erfolgt, wenn $d012 gerade auf #$39
gesprungen ist (oder unmittelbar davor steht, sich zu erhöhen? Kommt
darauf an, wann das STA wirksam wird und wann die Bad Line Condition
geprüft wird). In den Stellungen unmittelbar davor und danach ist
eine Bad Line da, weil entweder $d012 noch #$38 oder schon #$39 ist.
Dies ist ein Hinweis darauf (nicht der einzige), daß das "Bad Line->
Display On" bei der positiven Flanke von Phi0 geschieht, aber nagel
mich nicht darauf fest.

AB> [CPU-Zyklenzähler]
AB> Was ist, wenn die Befehle unterschliedlich lange dauern? (Pagegrenzen)

Der Pagegrenzen-Extrazyklus wird nicht berücksichtigt (man kanns ja
auch übertreiben :-) Das wird erst wirklich wichtig, wenn man VIC und CPU
zyklenweise emuliert). Aber der Bcc-Extrazyklus ist drin.

AB> [PHI0, BA, S/LUM-Diagramm]
AB> Ich könnte ja auch einen Fototransistor an der Bildröhre
AB> befestigen [...]

Bei mir wars ein Zweikanal-Oszilloskop. :-)
Beim Fototransistor werden dieselben Koordinaten herauskommen, wegen der
Lightpen-Geschichte.

AB> Will sagen, S/LUM und Fernsehbild sind doch schon längst Vergangenheit für
AB> die Gegenwart des Busses. Für die Tabelle, der das Timing des Bussystems
AB> zu Grunde liegt, ist es doch völlig uninteressant, wieviel Stunden es
AB> braucht, bis das Signal 'Textanfang' endlich mal am S/LUM Ausgang
AB> erscheint.

Doch, es ist interessant. Erstens kann man darüber und über die Sprite-
Koordinaten ermitteln, was der VIC an welcher _X_-Koordinate macht (man
kann dann auch z.B. bei deinem D011TEST.PRG die Zyklen des DEC D020 am
Bildschirm auszählen und nur dadurch konnte ich ermitteln, wie RC und VC
funktionieren (dabei hab ich auch schon festgestellt, daß Markos Diagramm
in diesem Punkt falsch ist)). Zweitens hat Marko es herausgefordert, indem
er in seinem Diagramm beides eingezeichnet hat, aber anscheinend nicht
ganz richtig.

AB> [Raster-IRQ-Komparator]
AB> Vergleicht er denn $D012 für den IRQ? Das wird so angenommen, aber wissen
AB> tut es keiner. :-)

Was denn sonst? :-)

AB> ["The Making of $DE00"]
AB> Ich wußte, wie man die RAM Adressen 0 und 1 lesen kann - mit dem
AB> Spritekollisionstrick auf dem Hiresschirm. Wir haben dann darüber
AB> nachgedacht, wieso die beiden Bytes überhaupt auf dem Hiresschirm flimmern
AB> - und manchmal wieder nicht.

0 und 1 vom Prozessor aus lesen? Um das Flimmern zu sehen, reicht
doch schon ein POKE53272,4. Was für ein Spritekollisionstrick?

AB> [RMW-Befehle machen zwei Schreibzugriffe]

Hab mir jetzt auch mal das 64doc besorgt. Komisch, daß erst die
CMOS-Versionen zwei Lesezugriffe machen. Erinnert mich etwas an den
68000, der bei einem "clr" erst mal aus der Adresse gelesen hat,
bevor er die Null hineingeschrieben hat. Was ist das überhaupt für
ein komisches Design beim VIC und 6502, das in _jedem_ Zyklus auf
Biegen und Brechen hinaus unbedingt zugreifen muß, selbst wenn es
total unnötig ist?

Noch was: Ich hab mir mal das D011TEST.PRG näher angesehen. Ich finde
es stellenweise etwas konfus, mit den BCSs und RORs. Was für eine Methode
verwendest du da, um den 6510 zyklengenau zu synchronisieren? Ich dachte
immer, sowas macht man mit dem Lightpen-Interrupt!?!

MfG,
Christian

-- TicroDom 1.10
  / Christian Bauer, Langenaustr. 65, 56070 Koblenz, Germany
\/ EMail: <cebix@ng-box.wwb.sub.de> or <cbauer@mzdmza.zdv.uni-mainz.de>

