Beiträge von Mike im Thema „Scroll- und Type-Routinen in BASIC V2“

    Zitat von BIF

    Bytebreaker:
    Die Funktion holt einfach nur die Stringadresse aus 34/35. Der Rest sorgt dafür, daß die Adresse in 34/35 auftaucht.
    (a$..) ist immer Null, so daß peek(34/35) nicht geändert wird, sorgt aber dafür, daß die Stringadresse in 34/35 auftaucht.
    Ansonsten denke ich, daß peek schneller ist als read oder asc(mid .


    Also wieder das gleiche Spielchen: ein "Trick", der auf einer Nebenwirkung beruht, die aus dem Programmtext als solches nicht hervorgeht. Das wäre ja an und für sich nicht schlimm, aber Du wirfst dieses Programmfragment einfach so in den Thread rein, trägst aber nichts zur eigentlichen Problemlösung bei, und läßt dir die Erklärung der Funktionweise deiner Programmfragmente auch noch gerne aus der Nase ziehen.

    Es muß hier wirklich von Programmfragmenten gesprochen werden, denn was Du im Regelfall ablieferst, sind ja nicht mal für sich ablauffähige Programme. Und was bringt es, wenn das Programm in Post Bitte melde dich an, um diesen Link zu sehen. einfach nur die Codenummer von "H", bzw. "H" selbst ausgibt? Das kann ich auch haben, ohne mir die Adresse von A$ zu holen - mit ASC(A$) und LEFT$(A$,1).

    Ich weiß auch, daß dich selbst diese Einwendungen einen S********ck interessieren werden, darum schreibe ich das hier weniger für dich, sondern als Bitte an Bytebreaker, dich nicht mit noch mehr Kartoffeln zu füttern.

    Hi, Bytebreaker,

    der Assemblercode in Post Bitte melde dich an, um diesen Link zu sehen. dient nur zur Doku. Er steht bereits komplett ausführbar in dem BASIC-Programm in der ersten DATA-Zeile drin, wird von da aus in den Speicher geschrieben und der Vektor von USR() geändert, so daß USR() auf diese Hilfsroutine verweist.

    Für so eine kleine Routine geht sich noch ein Direktassembler (hier: der Monitor in VICE) aus.

    Ein größeres Maschinenprogramm schreibt man sinnvollerweise in einem symbolischen (Cross-)Assembler der das Ergebnis dann als Datei ablegt, und wenn man diese von einem BASIC-Programm aus verwenden will, gibt's auch Methoden diese Datei in einen (geschützten) Bereich nachzuladen, kurz nachdem man das (BASIC-)Hauptprogramm gestartet hat.

    Zitat von ByteBreaker

    Wie machen die Leute das außerdem, dass wenn man LIST eintippt, eine SYS-Anweisung steht mit einer Sprung-Adresse auf den Maschinencode?


    Da steht am Anfang tatsächlich dieses kurze BASIC-Programm im Speicher. Man schaut sich an, wie das ab $0801 aussieht (es endet irgendwann mit 3 Nullen) kopiert das mit .BYTE-Direktiven (oder so wie's der jeweilige Assembler unterstützt) in den Quellcode und schreibt direkt dahinter das Maschinenprogramm.

    Weiteres dann gern in der Assemblerrubrik. ;)

    Zitat von Hexworx

    Jetzt ist mir biffig... :S


    Ja, echt. Wenn man ihn mal brauchen könnte, muß man doch alles selber machen... :aerger:


    Das kleine Hilfsprogramm in Maschinensprache ermittelt die Adresse einer Zeile, deren Nummer als Argument in einer USR()-Funktion angegeben wird. Mit der Zeilennummer und der Adresse der Zeile werden dann die Werte in 63..66 gesetzt. Existiert die Zeile nicht, so gibt's einen ?UNDEF'D STATEMENT ERROR (leider ist die dort angegebene Zeilennummer zur Fehlersuche nicht brauchbar, wenn man RESTORE in das Unterprogramm packt ...):

    Code
    JSR $B7F7 ; Float in FAC#1 nach Integer in $14/$15 umwandeln
        JSR $A613 ; Programmzeile suchen
    +-- BCC       ; nicht gefunden? dann Sprung
    |   LDY $5F
    |   LDA $60
    |   JMP $B391 ; Integer in (A/Y) nach Float in FAC#1 umwandeln
    +-> LDX #$11  ; ?UNDEF'D STATEMENT
        JMP $A437
    Zitat von Bytebreaker

    Ich bekomme [...] eine "Out of Data" Meldung sobald sich das Programm an den "umgestellten" DATA-Zeigern bedienen soll.

    Sind die Adressen 63-66 wirklich die richtigen? Wenn ja liegt es an mir und ich muss nochmal in den Code gucken.


    Ich hab' das gerade mal mit einem Minimal-Programm ausprobiert und es funktioniert.

    Zitat

    Oder aber das Programm verändert sich dynamisch im Speicher [...]


    Das kannst Du ruhigen Gewissens ausschließen. Weder ändert der der Interpreter beim Programmlauf irgendetwas am (tokenisierten) Programmcode noch 'schaufelt' er etwa Programmzeilen wild durch die Gegend. Nur nach einem LOAD werden eventuell die Linkzeiger korrigiert, wenn das Programm an eine andere BASIC-Startadresse geladen wird, als von wo es gespeichert wurde.

    Ich tippe eher mal darauf, daß Du zwischendrin aus Versehen D1..D4 noch für was anderes verwendest. :)