Hallo Besucher, der Thread wurde 2,4k mal aufgerufen und enthält 8 Antworten

letzter Beitrag von enigma am

VDC Spass / VDC fun

    Gibts irgendwo genauere Infos zu dem Chip?


    Insbesondere RFO hat gezeigt, was man aus dem Chip noch herausholen kann, leider sind davon viele Dinge nur mit genauem Timing realisierbar, was sie fuer normale Anwendungen eher nicht nutzbar macht.
    zB der 'FLI' Mode bei RFO wird dadurch erzeugt, dass Register 9 auf 0 gesetzt wird. (Bedeutet ein Zeichen ist eine Rasterline hoch) Jedoch scheint der VDC kein Bild darzustellen, wenn R9 null ist beim Beginn des Bildes, so dass man es zwischenzeitlich wieder auf 1 setzen muss.
    Interessanterweise verschwanden dabei die eingefaerbten Rasterlines...
    Ausserdem erfaehrt das komplette Bild durch den shrink der Attribute auch insgesamt ein shrink, so dass man den Sync und Anzahl der dagestellten und gesamten Rasterlines anders einstellen muss (R4, R6)
    Gibt es da irgendwelche Formeln fuer, um funktionierende Werte zu errechnen?
    Da ich leider den 80 Zeichen Schirm momentan nur auf einem Fernseher habe, ist das herausfinden von korrekten Syncs umso schwerer.


    Diese typische VIC2 FLI Sache, indem man das Attribut RAM jede Rasterzeile verschiebt, scheint beim VDC nicht zu klappen. Ich konnte nicht herausfinden ob es moeglich ist eine "Badline' zu erzeugen, damit es die Attribut Werte neu laed. Kurzes deaktivieren der Attribute erzeugt keine Badline.


    Was genau macht das Interlace Bit in R8 ?

    Ich glaube man kann auch auf einem C128 im 2Mhz Modus richtig timen. Der 2Mhz Modus ist Timingmaessig nur problematisch wenn man auf den IO Bereich $dxxx zugreift. Dabei wird bei jedem ungeraden Zyklus ein
    'Bill Herds Clock Stretching' gemacht.
    Damit sollte ein sta IO die CPU zu den IO-Bausteinen syncen, in dem Sinne, wenn man nun nur nach geradzahligen Zyklen IO Zugriffe macht, dass man immer einen IO-Chip kompatiblen Zyklus trifft, sodass dieser IO Zugriff immer dieselbe Zeit beansprucht.


    Ciao...

    Wow, Du wirfst eine Menge sehr interessanter Fragen auf, und streust dabei gleich eine Menge Infos ein, die mir völlig neu sind. Z.B. wusste ich schon auch dass man bei Zeichenhöhe 0 einen schwarzen Schirm bekommt, aber dass man das umgehen kann ist mir neu.


    Theoretisch sollten sich die vertikalen Parameter dann gleich berechnen, d.h. wenn die Zeichen nur halb so hoch sind, musst Du dafür doppelt so viele Zeichenzeilen darstellen, um auf die gleiche Wiederholfrequenz zu kommen.


    Falls Du mal ein halbwegs stehendes Bild hast, kann ich hier mit dem Oszi die Syncs genau ausmessen, wenn Du mir das Programm schickst.


    Einige Formeln sind in den Datenblättern zu den diversen Varianten des 6545/6845 enthalten, auf denen der 8563/8668 ja aufbaut. Der VDC enthält auch die meisten Register dieser Chips in identischer Form. Das lohnt sicher einen Blick. Interlace ist dort auch beschrieben, aber das funktioniert irgendwie nicht so, wie man es erwartet. Gedacht ist es so, dass die vertikale Auflösung scheinbar verdoppelt wird, indem abwechselnd geradzahlige und ungeradzahlige Zeilen verschachtelt (!) auf den Schirm gemalt werden. Natürlich flimmert es dann wie blöd. Wichtig ist, dass der VSync in der Mitte einer Zeile auftritt, da nur dann die Verschachtelung korrekt stattfindet. Der VDC achtet da natürlich nicht drauf, deshalb ist es etwas tricky die richtigen Werte zu finden. Manche Monitore sind da auch etwas pingeliger als andere. Mit den richtigen Timingwerten ist das dann im Textmodus recht unproblematisch, aber im Hiresmodus ist wieder irgendwas kaputt, so dass man die Bitmaps für die geraden und ungeraden Zeilen getrennt ablegen muss. Außerdem ist noch irgendwas anderes komisch, ich meine der einzig funktionierende Hires Interlacemodus basiert darauf auf einem Zählerüberlauf, damit im zweiten Field überhaupt etwas dargestellt wird. Das Listing dazu ist wirklich alt, stammt glaube ich noch von Fred Bowen und müsste über groups.Google.com zu finden sein.

    Wie geschrieben hatte ich als erstes versucht das Attribut RAM jede Rasterzeile zu verschieben was nichts gebracht hat, weil der VDC zusätzlich die Farbinformationen aus dem Attributram refreshen müßte. (i.e. eine neue Badline).
    Das Attributram kurz abzuschalten wirkt zwar sofort, läßt den VDC aber die Farben nicht refreshen.


    Die zweite Möglichkeit die dann noch blieb (gibts noch ne dritte?!?), war zu versuchen die Zeichen und damit auch die Farben auf eine Rasterline zu shrinken. Wenn man das jedoch einfach so macht und Register 9 auf null setzt, wird der Bildschirm schwarz. (Register 9 definiert die Anzahl der Rasterzeilen pro Zeichen minus 1, d.h. 0 bedeutet 1 Rasterline). Register9 auf 1 setzen geht und der VDC macht jedes Zeichen 2 Lines hoch. Da bei RFO jedoch genau das mit 1 Line zu sehen war, habe ich mal in den FLI-Viewer Code geschaut der bei RFO dabei ist. Wenn ich das richtig erkannt habe (hehe) ist der Trick der, dem VDC vor dem Start des Bildaufbaus auf 2 Rasterlines pro Zeichen zu schalten und erst nach Start des Bildaufbaus auf 1 Rasterline zu shrinken.
    (Anm.: Da der Char shrink pro Rasterline wirkt, koennte man sicher auch einen vertikalen FLD Schwabbeleffekt erzeugen, wenn man den VSync hinbekommt)
    Da ich nur einen Fernseher habe ist das mit VSync eh ein kleines Problem, jedenfalls das Grundproblem ist, daß man bei der Standardauflösung von 80x25 Charlines den Sync auf
    gesamter Screen: R4: 39 * vertikalPixelChar = 312
    dargestellter Screen: R6: 25 * vertikalPixelChar = 200
    hat.
    Wenn man das so übernimmt für 1 Pixel hohe Zeichen muesste man die Lines für den Gesamtscreen auf 312 setzen, was nicht geht, weil man maximal 255 reinschreiben kann. Aber R4 = 255 und R6 = 143 ergeben kein korrekt synchronisiertes Bild.


    Ein weitere seltsamer Effekt ist, daß eingefärbte Rasterlines bei 1 Pixelline hohen Zeichen verschwinden und der Hintergrund der Seitenränder schwarz wird.
    Selbst wenn der VDC in jeder Rasterline einen DMA Zugriff auf das Attributram durchführt und 80 Werte Attribut + 80 Werte Chars oder Grafik holt, braucht er dafür ca. 160? Zyklen (+DRAM Refresh Zyklen). Mit 16Mhz Clock hat er aber ca. 1000 Zyklen pro Rasterzeile Zeit...
    Hmm...


    Wenn man sich den FLI-Viewer von RFO anschaut fällt auf, daß das VDC-Bild sowohl vertikal als auch horizontal kleiner ist. Vermutlich hat das nur etwas damit zu tun, daß 16K Speicher nicht für die volle Auflösung ausreicht oder hat das auch Sync-Ursachen?
    Jedenfalls braucht man für die normale 640x200er Auflösung im geshrinkten Modus 32Kb.


    Ciao...

    Erstmal zu den Zyklen: Die 16MHz sind ja nur der Pixeltakt, der erstmal durch 8 geteilt wird und damit den Zeichentakt von 2MHz ergibt. Das ganze Timing des VDC und auch die Speicherzugriffe laufen dann mit diesen 2MHz ab. Wieviele solche 2MHz Zyklen pro Zeile vorhanden sind ist ganz einfach am Register 0 abzulesen. Davon muss man dann noch den Refresh abziehen, wobei ich nicht weiss ob das direkt der Wert im Register 36 ist, oder ob es da noch einen versteckten Anteil gibt. Damit hat man also pro Zeile nur etwa 120 Zyklen zur Verfügung, gleichzeitig 80 Zeichen Bitmap mit Attributen darzustellen geht also sicherlich nicht. Das kann schon der Grund für den schmaleren Schirm sein. Wobei mir da eh schon wieder nicht ganz klar ist, wie das auch z.B. im normalen Textmodus funktioniert: Pro Pixelzeile müssen auf jeden Fall 80 Zeichen Bitmap (Zeichensatz) gelesen werden. Dazu kommt dann noch pro Zeichenzeile 80 Zeichen Videomatrix und 80 Zeichen Attributmatrix. Da nur ca. 40 Zyklen pro Pixelzeile frei sind, müssen diese Zugriffe auf vier Pixelzeilen verteilt werden. D.h. der VDC hat in einer Zeichenzeile gleich vier Badlines? Wow, kein Wunder dass der so lahm ist!


    Das VSync Problem ist etwas knifflig. Ich denke mal dass der Zeichenzeilenzähler nicht besonders aussagekräftig ist, wenn man während des Bildaufbaus die Zeichenhöhe ändert. Im einfachsten Fall muss man dann eben die Anteile der verschiedenen Zeichenhöhen zusammenzählen und so das Timing berechnen.

    So ganz ueberzeugt mich das nicht:
    Wenn ich einen normalen 80x25 Textmodus Schirm shrinke auf 80x200 dann muss er pro rasterline:
    80 attributram + 80 Zeichencodes + 80 Zeichenmatrix + 5 Refreshadressen = 245 Zugriffe
    soviel Takte hat der doch garnicht pro Rasterline


    Wenn ich stattdessen Grafikmodus nehme fallen auch bloss 80 Zyklen weg (die Zeichencodes), macht 165 Zugriffe.


    Bei 2Mhz sollte er aber nur ca. 125 Zugriffe machen koennen ?!?


    Ciao....

    Naja, er muß ja nicht alle Daten in einer Pixelzeile holen. Der Plus/4 hat ja auch zwei Badlines pro Zeichenzeile ...


    Oder funktioniert das etwa, was Du da angibst?


    (Ich muß wohl doch den Adressbusdatenlogger bauen, um die Speicherzugriffe des VDC zu "analüsieren") :D

    Hab das vorhin mal mit dem Oszi nachgemessen: Das RAM wird wirklich nur mit 2MHz betrieben, mehr als die 120 und paar zerquetschte Zugriffe pro Zeile sind also nicht drin.

    Ich habe nochmal in Grahams Code geschaut und es wird folgende VDC Konfiguration verwendet
    (immer paar Register/Wert):
    (Im FLI-Viewer ab $1635 neben andren Tabellen, VDC-Setz-Routine ab $1008, die FLI-Anzeige Routine geht ab $1680 los)
    BYTE 0,127 ; horizontal total chars
    BYTE 1,64 ; horizontal displayed chars
    BYTE 2,$66 ; horizontal sync position
    BYTE 3,$49 ; sync width ( 9 hori , 4 verti )
    BYTE 4,38 ; vertical total
    BYTE 5,0 ; vertical total adjust
    ; BYTE 6,$08 ; vertical displayed
    ; wird vom code nahe $1680 geändert
    BYTE 6,128 ; vertical displayed
    BYTE 7,32 ; vertical sync position
    BYTE 8,0 ; interlace mode
    BYTE 9,7 ; character total vertical
    BYTE 10,$20 ; cursor mode / start raster
    BYTE 11,$07 ; cursor end scan line
    BYTE 12,>GRAFIKBASE ; display start adress hi, low
    BYTE 13,<GRAFIKBASE
    BYTE 14,$00 ; cursor position hi,low
    BYTE 15,$00
    BYTE 20,>ATTRIBBASE ; attribut high low
    BYTE 21,<ATTRIBBASE
    BYTE 23,$07 ; character displayed vertikal
    BYTE 24,%01100000 ; vert smooth scroll
    BYTE 25,%11000111 ; horizontal smooth scroll
    BYTE 26,1 ; foreground background
    BYTE 27,0 ; adress inc row
    BYTE 28,%00110000 ; character basis adress / 64k ram
    BYTE 29,$07 ; underline scan line
    BYTE 34,$7d ; display enable begin
    BYTE 35,$64 ; display enable end
    BYTE 36,$05 ; dram refresh rate
    BYTE 22,$78 ; character total displayed horizontal (8 pixel)
    BYTE $ff


    Nach dieser initialisierung werden nochmal einige Register geändert, der Einsprung erfolgt mit A=2. Ich habe noch nicht herausgefunden wozu das gut ist, für den FLI Mode geht es auch ohne. Vielleicht braucht man diesen Schritt bei einem andren Modus oder andrer VDC Revision.
    (im Viewer ab $1057)


    SETSYNC subroutine
    .1 bit VDCREG
    bpl .1
    tay
    dey
    lda TABREG4,Y
    ldx #4
    jsr WRITEREG
    lda TABREG5,Y
    lda #5
    jsr WRITEREG
    lda TABREG7,Y
    lda #7
    jsr WRITEREG
    tya
    ldx #9
    jsr WRITEREG
    ldx #23
    jsr WRITEREG
    .2 bit VDCREG
    bpl .2
    rts


    TABREG4 BYTE $9b,$9b,$67,$4d,$3d,$33,$2b,$26,$21,$1e,$1b,$19,$17,$15,$13,$12
    TABREG5 BYTE $00,$00,$00,$00,$02,$00,$04,$00,$06,$02,$04,$00,$00,$04,$0c,$08
    TABREG7 BYTE $80,$80,$55,$40,$33,$2b,$25,$20,$1c,$1a,$17,$15,$14,$12,$11,$10


    Danach wird noch dies gesetzt:
    4 ,218 ; vertical total
    1 ,60 ; horizontal displayed
    27,4 ; adress row inc
    7 ,168 ; vertical displayed
    36,0 ; dram refresh


    Das entspricht genau deinen Oszi-Werten:
    60 Zeichen im Grafikmodus + 60 Attributwerten + 0 Refreshwerten.
    (Anm: Ich habe mal gehört die Speicherspalten erhalten beim Speicherzugriff des VDC einen Refresh?!? )


    Danach kommt noch ein kleiner Trick im 1Mhz Modus:
    Man wartet bis der VDC mit dem Bildschirmaufbau beginnt, wartet 77 Zyklen und setzt Register 9 auf 0, dann wartet man wieder und setzt am Ende Register 9 wieder auf 1.
    Der Code dazu sieht so aus (im Viewer ab $17d4) :


    lda #0
    sta $d030


    lda #26
    sta VDCREG


    .BEGSCREEN lda #%00100000
    and VDCREG
    bne .BEGSCREEN
    lda #17 ; now on screen
    nop
    nop
    ldx #14
    .WAIT dex
    bne .WAIT
    lda #9
    sta VDCREG
    lda #0
    sta VDCDATA

    ldy #7
    ldx #32
    .WAIT1 dex
    bne .WAIT1
    dey
    bne .WAIT1
    ldx #8
    .WAIT2 dex
    bne .WAIT2

    lda #1
    sta VDCDATA
    nop
    lda #26
    sta VDCREG

    .ENDSCREEN lda VDCREG
    and #%00100000
    beq .ENDSCREEN

    jmp .BEGSCREEN


    Jedenfalls sieht es bei mir danach trotzdem noch nicht ganz so wie beim FLI-Viewer aus.(Bei mir hat das Bild keinen oberen und unteren Rand und die letzten Farben ziehen sich durch den VSYNC)
    Irgendwo ist da sicher noch ein Trick.


    Vielleicht sieht es ja jemand ?
    Oder Graham schreibt noch was dazu...


    Ciao...