Mode0 auf dem C64

Es gibt 35 Antworten in diesem Thema, welches 1.188 mal aufgerufen wurde. Der letzte Beitrag (12. September 2025 um 00:12) ist von 1570.

  • Auch das ist alles schon beschrieben, u.a. hier: Bitte melde dich an, um diesen Link zu sehen. (siehe letzte Absätze).

    Beim VDC ist der Zugriff so langsam/kompliziert, weil man einfach nicht genügend IC-Pins übrig hatte. Das war schon beim VIC-II so, da hat man selbst den Reset-Pin schon weggelassen und beim Color-RAM getrickst (es hat keinen eigenen Adressbus). "Einfach mal eben ganz eigenes RAM dran" war nunmal mit den Gegebenheiten/Kostenfaktoren nicht.

    Heute wie z.B. beim Kawari kann man einfach das RAM intern haben, nur ist das auch schon wieder nicht 100%ig kompatibel, weil man dann nicht z.B. die hohen Auflösungen im Ultimax-Modus benutzen kann: Das Ultimax-Modul kann nunmal nicht die Inhalte mit der nötigen Bandbreite zuspielen.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Bedeutet das, man hätte den VIC-III wie den 68000 auf 64-Pins vergrößern müssen? Auch die 6510?

    Steht doch alles im Text. :) Wäre sicher eine Möglichkeit gewesen (die MOS Anfang der 80er nicht hatte). Aber wie gesagt, 100%ige Kompatibilität hätte man nur mit einem ausgezeichneten VIC-II-Kompatibilitätsmodus erreichen können (wenn überhaupt), ansonsten funktionieren mindestens diverse Hardware-Erweiterungen und Steckmodule nicht.

    Letztendlich war das System nicht wirklich in der Hinsicht auf Erweiterbarkeit angelegt. Der C64 kann ja noch nichtmal eine echte Speichererweiterung (= Banking) am Expansionsport. Das wäre mit ein paar kleineren Änderungen an der PLA möglich gewesen, aber das stand wohl einfach nicht im Pflichtenheft bzw. man wollte teure aufwendige REUs verkaufen oder so. Aber hey, bei zwei Monaten Entwicklungszeit inkl. der ROMs war das alles eh sehr sportlich.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • das kann man kaum schlechter machen als beim VDC.

    Das ist richtig.

    Wobei das automatische inkrement der Adresse hat was.

    Genau, das automatische Inkrement ist nicht so schlecht.

    Darüberhinaus kennt der VDC-Chip die FILL Operation. Dh wenn ich die Daten, die in den VRAM sollen, RLE-Kodiere, dann kann ich diese sehr bequem direkt in den VRAM entpacken.

    Und das ist dann schneller, als wenn der C64 seine Daten ins Sichtfeld des VIC-II schaufelt.

    Die Frage ist, hätte man (~1985) in einen RICHTIGEN C128 (auch: 2MHz, 128 kB RAM) statt dieses zusätzlichen VDC einen "VIC-III" bauen können, der meine Anforderungen von oben erfüllt

    Ein bisschen mächtiger ist der VIC-II im C128 ja, als im C64.

    Man kann das Color-RAM für den VIC-IIe in beiden RAM-Bänken ablegen.

    Wo man am C64 die REU benötigt, um blitzschnell das Color-RAM zu ändern, könnte man dem VIC-IIe einfach sagen, er soll aus der anderen Bank lesen.

    Das hat trotzdem niemand genutzt, weswegen ich davon überzeugt bin, dass die C64-Kompatibilität zwar für die Verkaufszahlen vom C128 gesorgt hat, gleichzeitig aber auch dafür, dass seine Features nie genutzt wurden.

    Der CPC kann ja im Mode0 16 Farben ohne Restriktionen darstellen. Also 4 bpp. Aus einer LUT 16 aus 27.

    ...

    Könnte jemand leicht verständich die Hintergründe erklären und ob man einen solche "unrestrikted" Modus auf dem C64 oder einem (100% kompatiblen) Nachfolger auch hätte implementieren können?

    Wenn man am VDC-Chip nur mit dem Attribut-RAM arbeitet, reduziert sich die Auflösung auf zB 160x100 (auch 200x140 sollte möglich sein).

    Und dann kann man jeden Pixel individuell mit jeder der 16 Farben ansprechen.

    Hier ist die vertikale Auflösung halt niedriger als am CPC

    Ich hab das hier schon mal erläutert: Bitte melde dich an, um diesen Link zu sehen. (bei ca 19:30 geht's um das hier relevante Thema)

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com

    Einmal editiert, zuletzt von Goodwell (11. September 2025 um 16:55)

  • Wo man am C64 die REU benötigt, um blitzschnell das Color-RAM zu ändern, könnte man dem VIC-IIe einfach sagen, er soll aus der anderen Bank lesen.

    Was hätte man damit machen können? Braucht der IIe für dieses Feature die C128-Umgebung oder hätte der so auch auf dem C64-Board funktioniert?

  • Man kann das Color-RAM für den VIC-IIe in beiden RAM-Bänken ablegen.

    Das ist doch ein Feature der C128-PLA/des Prozessorports, nicht des VIC-IIe, oder? Schon beim C64 wird die Enable-Leitung des Color-RAMs nicht vom VIC-II, sondern von der PLA angesteuert.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Was hätte man damit machen können? Braucht der IIe für dieses Feature die C128-Umgebung oder hätte der so auch auf dem C64-Board funktioniert?

    Sonic the Hedgehog nutzt das DMA der REU, um das schnelle Scrolling umzusetzen.

    Für den regulären Betrieb ist das nicht notwendig. Es wird aber zb in Basic 7 genutzt, wenn man zwischen Text- und Grafikmodus umschaltet.

    Das ist doch ein Feature der C128-PLA/des Prozessorports, nicht des VIC-IIe, oder?

    Ja genau.

    Schon beim C64 wird die Enable-Leitung des Color-RAMs nicht vom VIC-II, sondern von der PLA angesteuert.

    Das mag sein, das Color-RAM liegt aber in einem separaten Speicherbaustein. Und im Gegensatz zum Video-RAM kann das Color-RAM nicht verschoben werden. Da geht dann zB kein Double-Buffering.

    Ich wollte nur darauf hinaus, dass der C128 tatsächlich mehr als der C64 aus dem VIC-II rausholt, es aber trotzdem keinen interessiert hat.

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Sonic the Hedgehog nutzt das DMA der REU, um das schnelle Scrolling umzusetzen.

    Ich meinte, was man mit dem "doppelten" Color-RAM anstellen kann. Schnelleres Scrolling oder höhere Farbdichte?

    Aber dazu hätte es im C64 neben VIC-IIe dann auch einen andere PLA gebraucht, wenn ich das richtig verstehe.

  • Ich meinte, was man mit dem "doppelten" Color-RAM anstellen kann. Schnelleres Scrolling oder höhere Farbdichte?

    Schnelleres Scrolling durch Double-Buffering zB.

    Dh der nächste Frame wird im unsichtbaren Bereich schon gezeichnet und wenns fertig ist, wird der unsichtbare Bereich zum sichtbaren.

    Ich kann mir aber auch vorstellen, dass man auf den Röhrengeräten durch geschicktes hin- und herschalten zwischen beiden Color-RAM Bänken auch an den Farben tricksen kann. Da kenn ich mich aber zu wenig aus.


    Aber dazu hätte es im C64 neben VIC-IIe dann auch einen andere PLA gebraucht, wenn ich das richtig verstehe.

    Der herkömmliche VIC-II hätte gereicht. Der II-e hat nur zusätzliche Leitungen, weil er sich auch um die zusätzlichen Tasten am C128 kümmert (Ziffernblock und so).

    Genau, die PLA hätte da wohl was machen müssen. Evtl das obere Nybble des Color-RAM nutzen oder so. Das ist ohnehin unbenutzt.

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Ich meinte, was man mit dem "doppelten" Color-RAM anstellen kann.

    Es wird bereits vom BASIC 7 schon genutzt um eine vom normalen Textbildschirm unabhängige Farbe 3 im Multicolor-Grafikmodus zu haben. Beim C64 hatte man ohne weitere Vorkehrungen immer das Problem, daß z.B. die Rückschaltung in den Textmodus und anschließendes Benutzen des Textbildschirms diese Farbinformation zerschossen haben, selbst wenn ansonsten ein eigener "Textbildschirm" für die Farben 1 und 2 genutzt wurde.

    Und ja, beim Scrollen einer Multicolor-Bitmap mit Farbe entzerrt das zusätzliche Farb-RAM das Timing ganz erheblich: während der 8 Steps eines Softscrolls kann man nun ganz entspannt die 10 KB in die nächste Hardscroll-Position bringen (8 KB Bitmap + 1 KB Text-RAM (Farbe 1 und 2) und 1 KB Colour-RAM (Farbe 3)) und man kommt nicht während der letzten Softscroll-Position auf einmal in Zeitnot. Auf welches Farb-RAM zugegriffen wird, kann für CPU und VIC getrennt eingestellt werden und so kann man den VIC-Zugriff auf das Farb-RAM in einer Bank lassen, während die CPU abwechselnd aus der gerade dargestellten Farb-RAM-Bank liest und zum Hardscrollen um 1 Zeichen verschoben in die andere Farb-RAM-Bank schreibt. Beim Hardscroll-Schritt tauschen die beiden Farb-RAM-Bänke dann die Rollen.

  • Wo man am C64 die REU benötigt, um blitzschnell das Color-RAM zu ändern, könnte man dem VIC-IIe einfach sagen, er soll aus der anderen Bank lesen.

    Das hat trotzdem niemand genutzt

    Wimre hat eine Demo im 64er Magazin damit Bitmaps per Double Buffering gescrollt.

  • man kommt nicht während der letzten Softscroll-Position auf einmal in Zeitnot.

    Also erleichtert das "nur" die Scroll-Programmierung bzw. die Spielegeschwindigkeit?

    In Summe nix, was ich als DAU in Form von bunterer Grafik wahrnehmen kann, korrekt?

  • man kommt nicht während der letzten Softscroll-Position auf einmal in Zeitnot.

    Also erleichtert das "nur" die Scroll-Programmierung bzw. die Spielegeschwindigkeit?

    In Summe nix, was ich als DAU in Form von bunterer Grafik wahrnehmen kann, korrekt?

    Viele Spiele sind deshalb nur vierfarbig, weil sie das FarbRAM nicht mitscrollen können/wollen. Mit ColorRAM-Double Buffering waren manche vielleicht bunter, weil das Timing dadurch entspannter wird.

  • In Summe nix, was ich als DAU in Form von bunterer Grafik wahrnehmen kann, korrekt?

    Es gibt in erster Näherung eben kein "Mehr" was der VIC an Grafikdaten herausholt bzw. herausholen kann, ja. Er macht ja nur die 40 Zugriffe auf das Farb-RAM parallel zum Text-RAM in dem ersten Raster jeder Textzeile (also, der Badline) - ob die jetzt aus Bank 1 oder Bank 2 kommen, ist ja erstmal völlig Wumpe.

    Was aber z.B. noch etwas "netter" ginge, ist der HCB-Modus aus Edge of Disgrace. Das ist ein FLI alle vier Zeilen, der in der Zeit bis zum nächsten angestoßenen DMA das Farb-RAM umschreibt. Man hat also echte 4 Rasterzeilen hohe Attribute - nicht nur für die Farben 1 und 2 sondern auch für Farbe 3, die sonst auch bei FLI für die ganze Zeichenposition gilt.

    Auf dem C128 bräuchte man dazu eben nicht das Farb-RAM "on-the-fly" für die nächste Badline vorzubereiten, sondern könnte einfach die Bank umschalten. Die (auch hier wieder) freigewordene CPU-Zeit ließe sich sicher gut nutzen.

  • ...Was spart man beim C64 unterm Strich?

    ...ob man einen solche "unrestrikted" Modus auf dem C64 oder einem (100% kompatiblen) Nachfolger auch hätte implementieren können?

    Ein bisschen Hintergrund war zumindest hier noch nicht so erwähnt:
    Im Prinzip können RAM, Prozessor und VIC-II alle 2MHz, im Prinzip wären das 2MB/s Bandbreite.
    Prozessor und VIC-II teilen sich das RAM und müssen Zugriffe koordinieren, es darf immer nur einer aufs RAM zugreifen.

    Das ist so gelöst, dass sich Prozessor und VIC-II abwechseln, so dass beide 1MB/s Bandbreite für sich haben.

    Dieses einfache Prinzip musste man aber sprengen, 1MB/s hat nicht immer gereicht. Ein bisschen Bandbreite hat man gewonnen, indem der VIC-II das Farbram parallel ausliest, also eigentlich ein 12bitter ist. Und er darf den Prozessor anhalten und auf dessen Kosten Bandbreite gewinnen, typisch ~1000 Takte je Frame für den Bildschirmspeicher. Und dann musste die ganze Technik auch noch mit 40 Beinchen auskommen.

    Was ich mir für eine kompatible Alternative mit den gleichen Beschränkungen vorstellen kann:

    - Zugriff auf die ganzen internen Register, die man heute nur hintenrum a la FLI bezaubern kann.

    - Mehr Steuerung für die ganzen Auto-Increments, die dazugehören, z.B. nur 32 statt 40 Zeichen weiterzählen.

    - Freie Screen- und Charset-Basis, nicht auf glatte 1024/2048 beschränkt, gehört auch zu den "mehr Registern"

    - Bitmap-Modus, wo nicht jedes Byte 8 weiter, sondern 1 weiter ist, gehört auch dazu.

    - Diese "Unrestricted" 160*200 bei 16 Farben, 320*200 bei 4 Farben, auch wenn das viele Takte klaut.

    - Halbe X-Auflösung

    - 16 Farben auswählbar

    - Beliebige Sprite-Höhe, nicht nur 21 Pixel.

    - Sprites auch 4/8-fach X/Ypanded

    - Grafikzugriffe im Oberen/Unteren Rahmen.


  • Im Prinzip können RAM, Prozessor und VIC-II alle 2MHz

    Das RAM hat von sich aus gar keinen Takt, es liegt auch kein Phi/Systemtakt am RAM an. Der Zugriff wird über CAS/RAS/RW/OE gesteuert, die jeweils eigenes Timing haben, deswegen auch die Angaben à la "150ns" zu dem RAMs (und nicht etwa "RAM 2MHz"). CAS/RAS, also das Gros des Timings, wird übrigens vom VIC-II erzeugt. :)

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.