Hallo Besucher, der Thread wurde 2,1k mal aufgerufen und enthält 6 Antworten

letzter Beitrag von Mike am

VC 20: Gibt es einen Trick, um den Screen RAM nutzen zu können?

  • In meinem aktuellen Programm für den VC20 habe ich den Screen RAM auf $1c00 verschoben und benötige unbedingt die regulären Screen-RAM-Adressen ($1e00-$1fff) für meinem Programmcode.

    Dabei habe ich nicht bedacht, dass nach dem LOAD und vor dem RUN der Computer natürlich im "Normal-RAM-Mode" ist.

    Meine Vermutung ist, dass die Readymeldung und der Coursor den hinterlegten Code überschreiben. Allerdings funktionieren die höheren Adressen (z.Bsp. $1fd0) auch nicht.


    Das folgende Programmbeispiel funktioniert nicht mehr sobald ich die Adresse für wait auf $1ee2 hochsetze. Wenn sich das nicht umgehen lässt, gehen mir ~285 Bytes an Speicher verloren.



    Gibt es einen Trick, wie ich den Speicher voll nutzen kann.

    Vieleicht mittels Autostart, falls es sowas gibt, oder etwas ganz anderes?


    aitsch

  • Das ist ja wirklich ein Drahtseilakt, Programmcode in den aktiven Bildschirmbereich zu laden und damit den aktuellen Bildschirmmanipulationen auszusetzen.

    Reicht es nicht nur bis 1dff zu laden und in der Startroutine, wenn dann der Screen umgestellt ist, den Bereich von 1c00 bis 1dff nach 1e00 zu verschieben (umzukopieren)?

  • In meinem aktuellen Programm für den VC20 habe ich den Screen RAM auf $1c00 verschoben und benötige unbedingt die regulären Screen-RAM-Adressen ($1e00-$1fff) für meinem Programmcode.

    Und warum das genau?


    Was spricht dagegen, wie gehabt $1E00..$1FF9 für den Bildschirm zu nutzen und dann eben $1C00..$1DFF für Code?

  • Das ist ja wirklich ein Drahtseilakt, Programmcode in den aktiven Bildschirmbereich zu laden und damit den aktuellen Bildschirmmanipulationen auszusetzen.

    Reicht es nicht nur bis 1dff zu laden und in der Startroutine, wenn dann der Screen umgestellt ist, den Bereich von 1c00 bis 1dff nach 1e00 zu verschieben (umzukopieren)?

    Ja, es ist so unglaublich knapp.

    Keine schlechte Idee. Das könnte man natürlich auch machen.

    In meinem aktuellen Programm für den VC20 habe ich den Screen RAM auf $1c00 verschoben und benötige unbedingt die regulären Screen-RAM-Adressen ($1e00-$1fff) für meinem Programmcode.

    Und warum das genau?


    Was spricht dagegen, wie gehabt $1E00..$1FF9 für den Bildschirm zu nutzen und dann eben $1C00..$1DFF für Code?

    ich habe den Bildschirm auf 30*25 Zeichen erweitert. Dadurch ergibt sich automatisch eine Verschiebung auf $1c00.

    Code
    1. lda #9 ; Bildschirmstart oben links
    2. sta $9000
    3. lda #25 ; Bildschirmstart oben links
    4. sta $9001
    5. lda #25 ; Anzahl Spalten (25)
    6. sta $9002
    7. lda #60 ; Anzahl Zeilen (2*30)
    8. sta $9003
  • ich habe den Bildschirm auf 25*30 Zeichen erweitert. Dadurch ergibt sich die Verschiebung automatisch.

    Danke. Das war das X im XY-Problem.


    Ansonsten so wie J.E.E.K. bereits geschrieben hat - im später als Screen-RAM genutzten Bereich steht eine kleine Kopier-Routine + die Daten, die später ab 7168+25*30 (=7918) bis 8191 stehen sollen, beim Programm-Start braucht das "unten" dann nur Platz für ein JSR.


    Das läßt im Original von $1C00..$1DFF vermutlich auch noch so viel Platz, daß Du da noch einige Init-Sachen mit unterbringen kannst, die Du später nicht mehr brauchst.:)



    Edit: oder alternativ - assemblier' den Objektcode so wie Du ihn dir vorstellst, mit der Lücke von $1C00..$1EED gefüllt mit Nullen und packe das Ganze anschließend mit Exomizer. Der bringt das dann problemlos unter 3,5 K (mindestens weil sich die Lücke optimal komprimieren läßt) und der Drops ist gelutscht.


    Edit 2: im Dekompressor solltest Du die Anzeige mit dem blinkenden "@" unten rechts ausschalten, da sonst $1FF9 zerhauen wird ...

  • ....

    Edit: oder alternativ - assemblier' den Objektcode so wie Du ihn dir vorstellst, mit der Lücke von $1C00..$1EED gefüllt mit Nullen

    bis hierhin verstehe ich es

    ... und packe das Ganze anschließend mit Exomizer. Der bringt das dann problemlos unter 3,5 K (mindestens weil sich die Lücke optimal komprimieren läßt) und der Drops ist gelutscht.


    Edit 2: im Dekompressor solltest Du die Anzeige mit dem blinkenden "@" unten rechts ausschalten, da sonst $1FF9 zerhauen wird ...

    ab hier nicht mehr

  • Mit Exomizer wird der ursprüngliche Code (incl. der Lücke darin) so weit komprimiert, daß das Ganze (hoffentlich) nach dem Laden nur bis $1DFF geht (die Chance ist groß, daß das Komprimat nur etwa 2 bis 2,5 KB groß ist).


    Nach dem Start mit RUN läuft dann der eingebaute Dekompressor, der stellt den ursprünglich vorgesehenen Zustand von $1001..$1FFF wieder her und startet dann dein Programm.