Hello, Guest the thread was viewed233k times and contains 3520 replies

last post from Omega at the

Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.

  • GoDot: Ja. Danke. Das habe ich gesucht.

    Bei der Version, die ich mir vor ein paar Tagen heruntergeladen habe, bringt RETRACE folgende Ausgabe:


    ad86

    2.20605


    Und bei der Version, die ich mir heute heruntergeladen habe steht:


    ad86

    2.20627


    Dazu habe ich zwei Fragen:


    1.) Was bedeutet "ad86"?

    2.) Sind von der letzten zur aktuellen Version 22 Verbesserungen/Änderungen hinzugekommen? Oder ist die Differenz zwischen 605 und 627 nur willkürlich?

  • Sind von der letzten zur aktuellen Version 22 Verbesserungen/Änderungen hinzugekommen? Oder ist die Differenz zwischen 605 und 627 nur willkürlich?

    Arndt hat in Github/TSB bislang alle Änderungen bis ins kleinste Detail dokumentiert. Da wird er sicher auch demnächst die neue Version 2.20627 einpflegen. Wenn Du dort auf die Versionsnummer klickst, werden die Unterschiede zur Vorversion gelistet.

  • Was bedeutet "ad86"?

    AD sind meine Initialen, und 86 ist das erste Release-Jahr von TSB.

    Oder ist die Differenz zwischen 605 und 627 nur willkürlich?

    Nein. ;-)


    warum steht da oben rechts in dem Befehlskasten eine 1?

    Weil es noch einen zweiten Artikel zum Befehlswort gibt.

    Was ist eigentlich mit dem original Retrace-Befehl? Hat der nichts getaugt?

    Der Nachverfolgungsbefehl heißt ja TRACE. Im original Simons' Basic erschien dann eine Liste der letzten vier vom Programm verwendeten Basic-Zeilen oben rechts (rechts, glaube ich). Wenn du TRACE beendet hattest und den Bildschirm löschtest, war diese Anzeige weg. Mit RETRACE konntest du die letzte Anzeige vor dem Ende von TRACE noch einmal anzeigen. Da in TSB der TRACE-Befehl eine ganz und gar andere Anzeige produziert, hatte der RETRACE-Befehl keinen echten Sinn mehr. Deshalb hab ich ihn umgewidmet zu etwas eher Brauchbarem. :-)


    Auf deine Anregung hin hab ich jetzt eine Update History geschrieben. Sie geht erstmal bis Februar 2020 zurück...


    Arndt

  • Oder ist die Differenz zwischen 605 und 627 nur willkürlich?

    Nein. ;-)

    Heißt das, dass 22 Änderungen notwendig waren um den Fehler im Verify-Befehl zu beheben?

    Auf deine Anregung hin hab ich jetzt eine Update History geschrieben. Sie geht erstmal bis Februar 2020 zurück...

    Das ist sehr interessant, was da alles hinzugefügt wurde.

    Ich finde es super, dass Du eine Software die 1983 entwickelt wurde heute immer noch so tatkräftig weiterpflegst und die Anwender unterstützt.

    Toll! Ob das der Simon auch weiß? Hast Du ihn mal getroffen oder kontaktiert?

  • Heißt das, dass 22 Änderungen notwendig waren um den Fehler im Verify-Befehl zu beheben?

    Nein, das waren die zwei POKEs, die ich dir genannt habe. Aber vielleicht kommst du ja noch drauf? ;-)


    Ob das der Simon auch weiß? Hast Du ihn mal getroffen oder kontaktiert?

    Der gute Mann heißt Simons (David Simons). Für einen 16-jährigen Nerd war das Basic eine ungeheure Leistung, finde ich. Ich hätte das nicht hingekriegt. Und nein, ich kenne ihn nicht persönlich. Und ob er überhaupt von mir weiß? :gruebel


    Arndt

  • Nein, das waren die zwei POKEs, die ich dir genannt habe. Aber vielleicht kommst du ja noch drauf? ;-)

    Oh, eine Herausforderung. Lass mich mal nachdenken...

    Das Jahr 2022? Nein, das wären ja nur die letzten beiden Ziffern davon.

    Ali Baba und die 22 Räuber? Nee, das sind ja 40.

    Schneewittchen und die 22 Zwerge? Nein, auch nicht.

    Ich geb's auf. :nixwiss:

    Für einen 16-jährigen Nerd war das Basic eine ungeheure Leistung, finde ich.

    Finde ich auch.

    Ich hätte das nicht hingekriegt.

    Nein, natürlich nicht. Du hast lieber gleich die verbesserte und erweiterte Version programmiert.

    Und ob er überhaupt von mir weiß? :gruebel

    Er würde sich bestimmt freuen wenn es wüsste, dass jemand sein Basic weiterentwickelt und pflegt und supported.

  • Ich habe mal eine Frage zur Umrechnung von Zahlensystemen in TSB.

    Mit den Befehlen % und %% kann man ja im Direktmodus Binärzahlen in Dezimalzahlen und umgekehrt umrechnen.

    Und im Programm kann man problemlos Binärzahlen als Konstanten verwenden, indem man ihnen ein % voranstellt.


    Ich habe mich nun gefragt, ob diese Umrechnung auch mit den Werten von Variablen in einem Programm durchgeführt werden kann.


    Wenn ich dezimal nach binär umrechnen möchte geht das. Und zwar so:

    10 X=16

    20 A$=%%X

    30 PRINT A$


    Wenn ich aber binär nach dezimal umrechnen möchte, dann kriege ich das nicht hin.

    10 A$="00010000"

    20 X=%A$

    30 PRINT X


    Das zweite Experiment führt zu einem ?not binary char error in 20. Der %%-Befehl akzeptiert anscheinend eine Variable als "Parameter", der %-Befehl aber nicht. Gibt es einen Weg, wie man im Programm einen Binärstring in eine Dezimalzahl umrechnen kann?


    Ich meine: Klar könnte ich in einer Schleife den String abgrasen und selbst einen Algorithmus programmieren, der das macht. Aber ich fände es eleganter (und wahrscheinlich auch erheblich schneller) wenn man die ohnehin schon vorhandenen TSB-Funktionen dafür benutzen könnte. Das wäre sehr nützlich, wenn man beispielsweise einen Zeichensatz- oder Spriteeditor mit TSB programmieren möchte.

  • Das machst du mit der NRM-Funktion...

    Das ist ja phänomenal! Du hast bei der Entwicklung von TSB aber auch wirklich an alles gedacht. Und die Funktion erkennt sogar automatisch, ob es sich um hex oder binär handelt. Toll! 8o

    Wenn ich richtig in der PDF-Anleitung gesucht hätte, dann hätte ich das auch selbst entdecken können. Es steht ja drin.

    Ich wäre allerdings niemals drauf gekommen, dass NRM ein geheimes Doppellleben hat.


    In diesem Zusammenhang möchte ich gleich noch eine Frage loswerden, die mich seit gestern plagt:


    In einem Programm schalte ich den MEM-Modus ein. Dann POKE ich bei $e000 eine 1 rein.

    Das dies funktioniert, sieht man sofort an dem veränderten @-Zeichen auf dem Bildschirm.

    Wenn ich die Speicherstelle bei $e000 aber nun mit PEEK auslese, dann kommt da 133 raus. Und nicht 1.


    Das verstehe ich nicht. Ist das ein Zaubertrick? :emojiSmiley-145:

    Code: Wo geht die 1 hin? Und wo kommt die 133 her?
    1. 10 print chr$(147)
    2. 20 mem
    3. 30 cset 0
    4. 40 print"@"
    5. 50 poke $e000,1
    6. 60 print peek($e000)
  • Das verstehe ich nicht. Ist das ein Zaubertrick? :emojiSmiley-145:

    Natürlich nicht! ^^


    Aber PEEK liest im Bereich $a000 bis $bfff und $d000 bis $ffff nicht das RAM, sondern das ROM aus. Im ROM steht an der Stelle $e000 der Befehl STA $56, wobei STA den Zahlenwert 133 ($85) hat. Und das wird dir gezeigt.


    Arndt

  • Gibt es denn eine Möglichkeit, im MEM-Modus das RAM im Bereich $e000 bis $efff auszulesen? I

    Ja, mit der Funktion TEST. Für TEST musst du am Anfang einmal HIRES eingeben (sonst liefert dir TEST - außer bei Koordinate 0,0 - immer 8 als Ergebnis, was bedeutet: "außerhalb des gültigen Bereichs"). Der HIRES-Aufruf setzt die Grenzwerte korrekt. Wenn du den HIRES-Befehl lästig findest (die Grafik blinkt kurz auf und MEM ist wieder aus), gibst du die beiden Werte für die maximale X- und Y-Koordinate per POKE vor: poke $c52d, $3f: poke $c52e,1 für X und poke $a4,200 für Y. Dann kriegst du mit test(x,y) raus, ob ein Punkt gesetzt ist oder nicht, also für dein Beispiel (1 an $e000) müsstest du x=test(7,0):print x eingeben (1 ist im Byte an $e000 dann ganz rechts, also an x-Position 7). Wenn das Bit an ist, kriegst du die Antwort "1", sonst "0".


    Arndt


    Edit: Den Maxwert für Y brauchst du gar nicht zu POKEn! Einfach weglassen!

  • Wenn das Bit an ist, kriegst du die Antwort "1", sonst "0".

    Wenn ich Deine Ausführungen richtig verstehe, müsste man bei jedem einzelnen Bildpunkt separat abfragen, ob er gesetzt ist oder nicht.

    Ich verstehe dabei jedoch noch nicht, wie sich diese erwähnten Koordinaten auf bestimmte Zeichen anwenden lassen. Wie zum Beispiel könnte man herausfinden, welche "Koordinaten" das Zeichen mit Zeichencode 132 hat? Ohne Mathematik-Studium.


    Ich hatte mir das eigentlich so vorgestellt, dass ich den Wert im RAM bei $e000 auslese und dann ein ganzes Byte, also alle acht Pixel zurückbekomme. Das heißt wenn ich die ersten 8 Bytes ab $e000 auslese, dann habe ich alle 64 Pixel des Zeichens mit Zeichencode 0, die nächsten 8 Byte sind Zeichencode 1 usw. Und mit der Dezimal zu Binärumrechnung kann man dann in acht Schleifendurchläufen ein ganzes Zeichen flott auf den Bildschirm ausgeben.


    Macht es überhaupt Sinn, dass man mit peek($e000) den Wert aus dem ROM bekommt?

    Als Basic-Programmierer interessiert mich doch eigentlich gar nicht, was im ROM drin steht.

    Wäre es nicht sinnvoller, wenn man zumindest im MEM-Modus mit PEEK($e000-$efff) die Werte aus dem RAM zurückbekommen würde?


    Oder könnte man nicht zumindest eine Art "Schalter" integrieren, der es ermöglicht, festzulegen, ob man mit PEEK aus dem RAM oder aus dem ROM liest?

    Na, ja. Wahrscheinlich stelle ich mir das alles zu einfach und naiv vor. Ist ja auch nur so eine Idee von einem, der nicht viel davon versteht. :idea:

  • Mit dem kleinen TSB-Programm hier kann du ab der Adresse AD (Zeile 105) beliebig lange das RAM auslesen (bis Tastendruck). Es wird hier nach $02c0 gePOKEt, ist aber relokatibel (läuft auch woanders, sogar in einem String). Vielleicht nutzt dir das was?

    Arndt

  • Erstmal vielen Dank.

    Habe ich das richtig verstanden? Zuerst muss das Maschinenprogramm bei $0c20 "installiert" werden.

    Und jedesmal wenn ich eine bestimmte (nicht zusammenhängende) Speicheradresse im RAM lesen möchte, muß ich den folgenden Code im Basic-Programm ausführen:


    10 ad=$e000: lo=mod(ad,256): hi=div(ad,256)

    20 poke $b2,lo: poke $b3,hi: poke198,0

    30 sys $02c0

    40 print peek(2)


    Das ist ganz schön viel Code um eine Speicheradresse zu lesen. Findest Du nicht?

    Aber wenn es nicht anders geht, dann muss es wohl so sein... :huh:


    EDIT: Ich würde mir als Verbesserungsvorschlag in zukünftigen TSB Versionen wünschen, dass man komfortabel auf Speicheradressen im RAM zugreifen kann. Zum Beispiel mit einem Befehl =RPEEK(Adresse). Denn das ist doch eigentlich die Intention von Simons' Basic/TSB: Das umständliche POKEs und DATAs durch komfortable, leicht verständliche Befehle ersetzt werden.