Xionum nutzt jetzt TSB

Es gibt 120 Antworten in diesem Thema, welches 5.869 mal aufgerufen wurde. Der letzte Beitrag (6. September 2025 um 15:39) ist von GoDot.

  • Was spricht denn dagegen, sowas als Prozedur zu programmieren?

    Die Geschwindigkeit.

    Das tolle an TSB ist ja, dass man damit seine eigenen Prozeduren für den konkreten Anwendungsfall programmieren kann!

    Die sog. "Prozeduren" in TSB sind dafür nicht geeignet. Das, was man hier brauchen würde, ist eine Funktions-Prozedur. So etwas gibt es in TSB nicht. In TSB gibt es noch nicht einmal Parameter bei den Prozedurdefinitionen.

  • Da kommt was in rollen... :thumbsup:

    Bitte melde dich an, um diesen Anhang zu sehen.
    1. Lokomotive

    2. Flachwagen (leer)

    3. gedeckter Güterwagen

    4. Kesselwagen

    5. offener Güterwagen (leer)

    6. offener Güterwagen (mit Kisten oder sowas)

    7. Flachwagen (beladen)

    8. Schüttgutwagen

    9. Flachwagen mit Autos

    10. Containerwagen

    11. Kühlwagen

    12. Langholztransport

    13. Kabelrollen

  • Die sog. "Prozeduren" in TSB sind dafür nicht geeignet. Das, was man hier brauchen würde, ist eine Funktions-Prozedur. So etwas gibt es in TSB nicht. In TSB gibt es noch nicht einmal Parameter bei den Prozedurdefinitionen.

    Hier wäre eine geeignete Stelle, um verbotene Schleichwerbung für COMAL zu machen. :D

  • Den COMAL Thread lese ich auch mit und finde das auch sehr interessant, aber eins nach dem anderen.

    Selbst der Großmeister der Spieleprogrammierung ( Omega ) musste erst zwei(!) Spiele in TSB abliefern, bevor er die heiligen Hallen des COMAL betreten durfte. :prof:

  • Eigentlich bräuchte man ein Gegenstück zur CHR$-Funktion, mit dem man nicht den ASCII-Code sondern den Bildschirmcode PRINTen kann. Das würde so manches vereinfachen.

    Also sowas wie =BHR$(Bildschirmcode). Das würde die BASIC-Programmierung revolutionieren.

    Am allerbesten wäre es noch, wenn man gleich mehrere Bildschirmcodes hintereinander angeben könnte.

    Z.B. PRINT BHR$(161,162,163,164).

    Ja, das wäre was. Dann hätte man auch einen sauberen, gut lesbaren (und druckbaren) Code ohne diese dümmlichen PETSCII-Hieroglyphen im Listing.

    Danke für diese Idee. Ich habe die gleichmal in mein PABasic umgesetzt. Sowohl der CHR$( als auch der neue SCRCHR$( verstehen nun mehrere Parameterangaben) :thumbsup:

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

  • Snoopy , die Prozeduren sind auch klasse. Das sehe ich wie du, das macht den Programmierer aus.

    Ich versteh immer die Entwickler bei der Arbeit nicht wenn die für alles eine Lib brauchen anstelle mal selber was zu schreiben.

  • Snoopy , die Prozeduren sind auch klasse.

    Bei dem, was TSB als Prozeduren bezeichnet, handelt es sich nicht wirklich um Prozeduren. Zwar kann man mit PROC und ENDPROC Programmabschnitte definieren, die ähnlich wie bei GOSUB und RETURN angesprungen und wieder verlassen werden, doch der Funktionsumfang bleibt stark eingeschränkt.

    Es gibt keine Möglichkeit, im Prozedurkopf Parameter zu übergeben, weder per Wert noch per Referenz. Ebenso existieren keine lokalen Variablen - alles, was innerhalb der Prozedur geschieht, wirkt sich direkt auf den globalen Namensraum aus.

    Damit fehlt praktisch alles, was echte Prozeduren in anderen Programmiersprachen ausmacht: Kapselung, Wiederverwendbarkeit mit unterschiedlichen Werten, klar definierte Ein- und Ausgabeschnittstellen.

    Intern handelt es sich letztlich um einen GOSUB-Mechanismus mit syntaktischem Zucker. Wer mit moderneren Sprachen vertraut ist, wird den Begriff "Prozedur" hier wahrscheinlich für irreführend halten. Es ist daher treffender, von Pseudo-Prozeduren zu sprechen.

  • Ich habe dafür einfach Variablen definiert.

    Prozeduraufrufe sehen dann immer so aus:

    mx=5:my=5:t$="ich bin eine textbox":exec msgbox

    Ob die Parameter jetzt vorn oder hinten stehen ist nicht schlimm.

    Und im Grunde ist es meine Konvention mx, my und t$ nicht anders zu verwenden.

  • Ich habe dafür einfach Variablen definiert.

    Prozeduraufrufe sehen dann immer so aus:

    mx=5:my=5:t$="ich bin eine textbox":exec msgbox

    Ob die Parameter jetzt vorn oder hinten stehen ist nicht schlimm.

    Und im Grunde ist es meine Konvention mx, my und t$ nicht anders zu verwenden.

    Klar, was anderes bleibt ja eigentlich auch nicht übrig, wenn es keine lokalen Variablen gibt. :)

    Die andere Frage ist, ob es überhaupt so zielführend ist, eine C64-BASIC-Erweiterung, die noch dazu auf reiner Software basiert, mit "modernen" Sprachen auf viel leistungsfähigeren Plattformen zu vergleichen. Dann könnte man auch z.B. sagen, dass Vizawrite keine echte Textverarbeitung ist.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Hm... also, ich meinte jetzt schon eine unter BASIC zur Verfügung stehende Funktion

    Einfach auf BIF warten, der wird uns schon zeigen, wie man durch POKEs den KERNAL nutzen kann, um die Umwandlung vorzunehmen. :syshack:

    Ich habe mich mal versucht: Ziemlich dreckig, aber funktioniert:

    Code
    POKE 780,SC:POKE 782,PEEK(216)+1:SYS 58942:POKE 211,PEEK(211)-1:PE=PEEK(215)

    Damit wird der Screencode in SC in den PETSCII-Code in PE umgewandelt. Dreckig ist es vor allem, weil die RTS-Adresse vom SYS-Befehl vom Stack geholt wird und eine Ebene "höher" zurückgesprungen wird. Das ist aber nicht schlimm, weil SYS nur wenig macht (die Register nach 780-783 zurückschreiben)

    Ausserdem wird die aktuelle Cursorposition in $D3 inkrementiert. Deshalb muss 211 neu gePOKEd werden, um das rückgängig zu machen.

    782 (= Y-Register) wird angefasst, weil es eine Sonderbehandlung am Ende einer Zeile gibt, dann wird CR rückgegeben. Damit das nicht zuschlägt muss ich dafür sorgen, dass der Inhalt von Y nicht gleich $D8 (216) wird, was mit dem +1 erreicht wird.

  • Ich habe mich mal versucht: Ziemlich dreckig, aber funktioniert

    Funktioniert *prächtig*! :thumbsup:

    Code
    10 sc=224
    20 poke780,sc:poke782,peek(216)+1:sys58942:poke211,peek(211)-1:pe=peek(215)
    30 dump
    
    run:
    
    sc= 224
    pe= 160
    
    ready.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Wer mit moderneren Sprachen vertraut ist

    Dieser Thread ist ausdrücklich auf TSB bezogen. Da sind deine Hinweise auf COMAL nicht sachdienlich. Du könntest stattdessen deine Erfahrungen mit TSB hier zu jedermanns Freude einbringen.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Dieser Thread ist ausdrücklich auf TSB bezogen. Da sind deine Hinweise auf COMAL nicht sachdienlich.

    Nur zur Klarstellung: Ich habe in diesem Thread kein einziges Mal die strukturierte Programmiersprache aus Dänemark mit den fünf Buchstaben erwähnt - mein Beitrag bezieht sich ausschließlich auf die Prozedur-Implementierung in TSB. Und meine persönliche Erfahrung mit TSB ist leider, dass man gerade wegen der fehlenden Parameterübergabe und der komplett globalen Variablengültigkeit sehr schnell den Überblick verliert.

    Was auf den ersten Blick wie eine echte Prozedur aussieht, entpuppt sich in der Praxis als kaum isolierbarer Programmteil. Früher oder später beißt man sich dann in den Hintern, weil irgendwo eine Variable nicht mehr das enthält, was man erwartet. Das mag für ganz einfache Programme noch vertretbar sein, wird aber bei wachsender Komplexität zum echten Problem. Das ist keineswegs als Angriff gemeint - sondern eine schlichte und nüchterne Beobachtung.

    Du könntest stattdessen deine Erfahrungen mit TSB hier zu jedermanns Freude einbringen.

    Ich bringe meine Erfahrungen mit TSB gern ein - auch wenn ich nicht sicher bin, ob es zu jedermanns Freude ist, wenn ich dabei auf Schwächen hinweise. Aus meiner Sicht ist gerade das Prozedurkonzept in TSB problematisch, weil es Kapselung nur vortäuscht. Das mag in kleinen Programmen noch gutgehen, wird aber bei wachsender Komplexität schnell zur Fehlerquelle - und dann hält sich die Freude erfahrungsgemäß in Grenzen.

  • Also wenn man, salopp gesagt, zu blöde, faul, kurzsichtig, sonstewas ist, sich erst einen Plan über die zu verwendenden Variablen zu machen, dann hat man vermutlich auch nicht die Intention oder Fähigkeit, ein komplexes Programm zu erstellen - in Basic, mit ca. 30 kb Speicher, und überhaupt auf dem C64. ^^ Es gibt sicherlich erstaunliche Programme, die viel aus dem C64 herausholen, aber am Ende ist und bleibt es ein kleiner C64.

    "Frage nicht, was die Programmiersprache für dich tun kann, frage dich, was du mit der Programmiersprache tun kannst."

  • Ich bringe meine Erfahrungen mit TSB gern ein - auch wenn ich nicht sicher bin, ob es zu jedermanns Freude ist, […]

    Bedauerlich.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Also wenn man, salopp gesagt, zu blöde, faul, kurzsichtig, sonstewas ist, sich erst einen Plan über die zu verwendenden Variablen zu machen, dann hat man vermutlich auch nicht die Intention oder Fähigkeit, ein komplexes Programm zu erstellen - in Basic, mit ca. 30 kb Speicher, und überhaupt auf dem C64. ^^ Es gibt sicherlich erstaunliche Programme, die viel aus dem C64 herausholen, aber am Ende ist und bleibt es ein kleiner C64.

    Manche Kommentare zu den Fähigkeiten anderer erspare ich mir lieber - mir geht es darum, sachlich über das zu sprechen, was TSB kann und was nicht. Und genau da möchte ich meine Erfahrung einbringen.

    Wer statt dem üblichen V2-BASIC zu TSB greift, könnte auf den ersten Blick meinen, damit stünden einem bessere Werkzeuge zur Verfügung, um komplexere Programme strukturierter zu schreiben. Begriffe wie PROC, ENDPROC, aber auch LOCAL und GLOBAL erwecken den Eindruck, dass man es hier mit echten prozeduralen Sprachmitteln zu tun hat.

    In Wirklichkeit ist das aber trügerisch. TSB bietet letztlich keine echten strukturierten Möglichkeiten - die sogenannten Prozeduren sind eher als optisch aufgepeppte GOSUBs zu verstehen. LOCAL und GLOBAL haben keine funktionale Wirkung im Sinne eines lokalen Namensraums. Am Ende steht man vor denselben Problemen wie beim klassischen C64-BASIC: Globale Variablen, keine Parameter, keine Rückgabewerte - und damit auch keine saubere Trennung von Programmteilen.

    Das heißt nicht, dass man mit TSB nichts Sinnvolles machen kann - aber wer glaubt, damit strukturiert programmieren zu können, wird früher oder später feststellen, dass einem die BASIC-Erweiterung dabei nicht unterstützt.

  • Das heißt nicht, dass man mit TSB nichts Sinnvolles machen kann - aber wer glaubt, damit strukturiert programmieren zu können, wird früher oder später feststellen, dass einem die BASIC-Erweiterung dabei nicht unterstützt.

    Strukturiert programmieren beinhaltet mehr als nur Prozeduren. Du legst zu viel Wert auf diesen einzelnen Aspekt und verteufelst zu Unrecht TSB. Wir bewegen uns immer noch auf einem C64 mit sehr eng gesteckten Grenzen was Leistung und Speicher angeht.

    Wie Lynx schon erwähnte, man sollte sich einen Plan machen wenn man gewisse Grenzen hat, sonst ist nicht die Software das Problem sondern die Person vorm Bildschirm.

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

  • Und ich meinte das in keiner Form böse oder abwertend. Ich schliesse mich ja mit ein. Jede/r kann, wie sie/er kann und macht, wie sie/er macht. Man wächst an den Aufgaben und die Fähigkeiten nehmen zu. Retro-Programmierung bringt uns Spaß, Ablenkung vom Alltag und Unterhaltung, gerade wegen der Unzulänglichkeiten und der simplen Form im Vergleich mit den modernen Entwicklungsumgebungen.

  • Omega ich weis du meinst es nur gut.

    Aber wie TD1334 und Lynx sagen, wir reden hier über den C64 mit kleinem Speicher.

    In TSB habe ich jetzt aktuell noch knapp 27kb frei, wenn das Programm läuft sind es 26kb.

    Es würde niemandem etwas nützen, wenn alle modernen Ansätze vorhanden wären aber dann nur noch 5 Kb für das Programm übrig bleiben. Da kann man die tollen Features nicht nutzen.

    Und ohne Plan geht es einfach nicht.

    Ich Pflege nebenbei eine Textdatei in der alle Prozeduren mit ihrer Startzeilennummer, den verwendeten Variablen, den Variablen die für den Aufruf notwendig sind, und in welcher Variable ein Rückgabewert abgelegt wird.

    Variablen-Recycling steht ganz oben an.

    Es ist wirklich schön so mit TSB zu arbeiten. Da hat GoDot sehr gute Arbeit geleistet.