Bildschirmspeicher unter das BASIC-ROM verschieben?

Es gibt 24 Antworten in diesem Thema, welches 1.351 mal aufgerufen wurde. Der letzte Beitrag (4. Dezember 2024 um 10:48) ist von Computerbastler.

  • Hallo,

    ich versuche seit einiger Zeit erfolglos, den Bildschirmspeicher nach $B000 zu verschieben, das kopierte Character-ROM liegt bei $A000.

    Mein Vorgehen:
    Über den CIA2 wird der VIC-Adressraum nach $8000-$BFFF verlegt. Funktioniert soweit.

    Mit dem VIC-Register $18 wird der Zeichensatz nach $A000 verschoben (klappt auch, der kopierte Zeichensatz kann dort verändert werden). Der Bildschirmspeicher liegt dann standardmäßig bei $8400. Bis hierher funktioniert es auch.

    Natürlich muss dem BASIC-Interpreter auch die neue Lage des Bildschirmspeichers mitgeteilt werden: Poke 648,Highbyte Adresse Bildschirmspeicher.

    Sobald ich aber versuche, den Bildschirmspeicher nach $B000 zu verschieben, geht es schief. Ich kann noch mit dem Testprogramm in BASIC, mit dem ich die Manipulationen vornehme, in der letzten Zeile ein LIST ausgeben, was auch funktioniert, wenn ich aber mit dem Cursor über den Programmtext fahre, werden alle überfahrenen Zeichen durch Schrott ersetzt. Ein Return im freien Bereich unterhalb des Listings führt auch zu einem Syntax Error (weil nicht die Leerzeichen, sondern derr Schrott interpretiert wird). Sobald der Bildschirm nur um 1 Zeile gescrollt wird, ist das ganze Listing Schrott.

    Nach meiner Meinung müsste das aber funktionieren:

    Der VIC sieht von $8000-$8FFF RAM (VIC-Adressraum $0000-$0FFF), von $9000-$9FFF sieht er das Character-ROM an Adresse $D000-$DFFF (VIC-Adressraum $1000-$1FFF) und von $A000-$BFFF sieht er wieder RAM (VIC-Adressraum $2000-$3FFF)

    Der Prozessor leitet im gesamten Adressraum (außer I/O) Schreibzugriffe aufs RAM, der BASIC-Interpreter wird aber aus dem ROM gelesen und funktioniert daher trotzdem. Dass der Bildschirmspeicher dann vom Prozessor aus nicht ohne Weiteres (Umschalten der Speicherkonfiguration über Adresse 1) gelesen werden kann, ist mir klar. Wäre aber egal, solamge der VIC das RAM sieht.

    Liege ich da falsch? Ich habe jetzt mehrere Bücher und das Internet konsultiert und komme immer zu dem Schluß, dass mein Vorgehen richtig sein müsste. Ist es aber wohl nicht. Wo liegt mein Denkfehler?

    Zu Nachvollziehen: Wenn der VIC erfolgreich nach $8000 verschoben ist, dann folgt ein POKE 53272,201 (Bildschirmspeicher und Characterdefinition verschieben) und ein POKE 648,176 (BASIC-Interpreter Bildschirmseicheradresse mitteilen).

    Bisher ist das alles nur zu Versuchszwecken, wenns dann in BASIC mal funktioniert möchte ich das natürlich in Maschinensprache umsetzen.

    Natürlich könnte ich den VIC und den Bildschirmspeicher auch woanders hinlegen, aber ich denke, dass das er beste Ort wäre, wo BASIC und die anderen freien Bereiche voll nutzbar blieben und gleichzeitig das Kernal im RAM patchbar wäre.

    Ich will einfach verstehen, wo mein Denkfehler liegt.

  • Da musst du deinen Code hier reinstellen.

    Könnte nämlich auch ein Tippfehler sein

    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
  • KERNAL und BASIC lesen auch häufiger aus dem Bildschirmspeicher, z.B. beim Cursor-Blinken (da ja gelesen, invertiert, geschrieben werden muss), beim Bewegen des Cursors (dito), beim Scrollen des Bildschirminhalts oder auch im Bildschirmeditor beim Drücken von RETURN. Das klappt nicht (richtig), wenn der Bildschirmspeicher unter dem ROM liegt, weil dann aus dem (BASIC-)ROM statt dem (Bildschirm-)RAM gelesen wird.

    Nur PRINT alleine aus einem Programm sollte aber korrekt funktionieren.

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

    2 Mal editiert, zuletzt von 1570 (3. Dezember 2024 um 15:16)

  • Wenn ich das richtig verstehe, willst Du in Basic den Bildschirmspeicher unter das ROM schieben. Das kann nur schief gehen. Beim Zeichensatz dürfte es aber keine Probleme geben.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Das kann nur schief gehen

    Das ist eigentlich ziemlich gängig.

    Der VIC-II liest ja nur aus dem RAM, dem ist egal, was die PLA der CPU zeigt.

    Und jede Schreiboperation landet ohnehin im RAM, selbst wenn das ROM sichtbar ist.

    Von daher eigentlich sogar fast schon genial würd ich meinen :smile:

    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
  • Siehe Bitte melde dich an, um diesen Link zu sehen. , Überschrift "Einschränkungen".

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

  • Bisher ist das alles nur zu Versuchszwecken, wenns dann in BASIC mal funktioniert möchte ich das natürlich in Maschinensprache umsetzen.


    Natürlich könnte ich den VIC und den Bildschirmspeicher auch woanders hinlegen, aber ich denke, dass das er beste Ort wäre, wo BASIC und die anderen freien Bereiche voll nutzbar blieben und gleichzeitig das Kernal im RAM patchbar wäre.

    Ich will einfach verstehen, wo mein Denkfehler liegt.

    Wie andere schon geschrieben haben, sind die Lesezugriffe auf den Bildschirmspeicher das Problem. Diese greifen nämlich nicht auf den Bildschirm sondern auf das ROM zu. Alle Befehle, bei denen du sicherstellen kannst, dass sie keinen Lesezugriff auf den Bildschrim tätigen, kannst du so aber nutzen. (Bei deinem Beispiel mit dem LIST am Ende des Programms: Das funktioniert auch nur deswegen, weil das Listing komplett auf den Bildschirm passt, wäre es länger wäre plötzlich wieder alles voller "Schrott", nämlich genau dann, wenn das Scrolling beginnt.)

    Wenn du Maschinensprache nutzt, geht das besser, weil du dann die Lesezugriffe selbst kontrollieren kannst. Das heißt, du kannst dann vorher auf RAM switchen (via $01) und hinterher wieder zurück. Bei Aufrufen von Routinen im BASIC-ROM musst du aber nach wie vor darauf achten, dass dort keine Lesezugriffe stattfinden.

  • So, habs mal abgetippt. Hier der BASIC-Code:

    10 POKE 56334,0:POKE 1,51 : REM INTERRUPT SPERREN / ZUGRIFF AUF CHARROM

    20 FOR K=0 TO 4095:POKE 40960+K,PEEK(53248+K):NEXT K: REM CHARROM INS RAM KOPIEREN

    30POKE 1,55:POKE 56334,1 : REM STANDARD SPEICHERKONFIGURATION / INTERRUPT FREIGEBEN

    40 POKE 56576,197 : REM VIC 16K-BLOCK $8000-$BFFF AUSWÄHLEN

    50 POKE 648,176: REM BILDSCHRIM-RAM NACH 45056 ($B000)

    60 POKE 53272,201: REM CHARACTER GENERATOR / BILDSCHIRMSPEICHER UMSCHALTEN

    70 PRINT CHR$(147) : REM BILDSCHIRM LOESCHEN

    80 PRINT"(648):";PEEK(648)

    90 PRINT"(53272):";PEEK(53272)

    100 LIST


    Danke an alle, die mir hier weitergeholfen haben.

    Das war mir nicht klar, dass der BASIC-Interpreter bzw. das Kernal da zwischendurch immer wieder fälschlicherweise aus dem ROM liest (na klar: Cursor...). Mit den Erklärungen und dem Wiki-Artikel ists klar, dass die angedachte Speicherkonfiguration so nicht sinnvoll ist. Blöd ist halt, dass man sich bei anderen Konfigurationen immer den zusammenhängenden Speicher segmentiert und damit den verfügbaren BASIC-Speicher reduziert. Mir reicht das für das, was ich im Moment machen will trotzdem (zumal ich es in Maschinensprache machen will), es war ein Versuch, ein Stück wiederverwertbaren Code zu schreiben.

    Einmal editiert, zuletzt von Computerbastler (3. Dezember 2024 um 18:56) aus folgendem Grund: Dank an die Schreiber, die die Erklärung geliefert haben

  • An 56578 muss man evtl die Datenrichtung der Bits 0 und 1 vom CIA auf Ausgang stellen:

    POKE 56578,3

    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
  • Goodwell Nee, nicht nötig, macht der KERNAL schon (Bitte melde dich an, um diesen Link zu sehen. Punkt 4.1), außerdem würde das so die Konfiguration für die Floppy/IEC-Leitungen verstellen.

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

  • Blöd ist halt, dass man sich bei anderen Konfigurationen immer den zusammenhängenden Speicher segmentiert und damit den verfügbaren BASIC-Speicher reduziert. Mir reicht das für das, was ich im Moment machen will trotzdem (zumal ich es in Maschinensprache machen will), es war ein Versuch, ein Stück wiederverwertbaren Code zu schreiben.

    Nö.

    Bei Bank 3 und Bildschirmspeicher irgendwo bei C000++ verlierst du vom BASIC-RAM nix.

  • Das ist richtig - aber dafür den 4k-Block, in dem ich normalerweise meinen Maschinensprachemonitor geparkt habe. Den brauche ich zwar später (zur Laufzeit des Programms) nicht, aber zum Programmieren ists doch ganz praktisch, den einmal zu laden und dann jederzeit wieder aufrufen zu können.

  • Computerbastler Den Monitor solltest Du aber auch unter z.B. den KERNAL bekommen (mit einem kleinen Trampoline irgendwo, also sofern der Monitor der Wahl natürlich nicht den KERNAL benutzt). Oder halt ein Cartridge benutzen. Was man so hört, ist der Monitor im Action Replay ganz gut.

    Oder einfach Turbo Macro Pro nehmen mit einem zweiten C64 als Runtime. Oder eine REU. Dann ist Speicheraufteilung nicht mehr so Thema.

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

    Einmal editiert, zuletzt von 1570 (3. Dezember 2024 um 21:09)

  • 1570 Der Monitor der Magic Formel ist auch ziemlich fähig. Ist damals immer wieder sogar als der beste Monitor eines Freezers bezeichnet worden.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • SMON gibt es für "an $9000".

    Der kann sich selber in jeden beliebigen 4k-Block verschieben :wink:

    Auch das noch.

    Wie hätte unser Kaiser, Gott hab ihn selig, gesagt: "Mir bleibt auch nichts erspart!"