Komm doch mit Argumenten ....
Ich glaub, jetzt haben wir alles gesagt. xionum mag TSB - und das ist super. Ich wollte lediglich ein paar kritische Anmerkungen loswerden, aber kein Fass aufmachen. Und am Ende bleibt es wie immer: Ich hab natürlich Recht - aber ich sag’s keinem weiter. 
Hier ein Auszug aus dem TSB-Handbuch...
Wenn du das für strukturierte Funktionen hältst, dann wundert mich nichts mehr. He he he! 
Für mich passt alles in TSB ziemlich gut.
Das ist hervorragend. 
Deine Erwartungshaltung kommt von Software auf aktueller Hardware.,
Nein.
Dann beziehe dich bitte auch nur auf die Prozeduren und spreche TSB als ganzes nicht ab, das es Funktionen zum strukturierten arbeiten enthält.
Welche Funktionen zum strukturierten Arbeiten hat TSB?
Du legst zu viel Wert auf diesen einzelnen Aspekt und verteufelst zu Unrecht TSB.
Ich verteufele überhaupt nichts - das liegt mir fern. Wenn man sich zum ersten Mal mit Simons Basic oder TSB beschäftigt und die Befehle überfliegt, entsteht durchaus der Eindruck, es handle sich um eine BASIC-Erweiterung mit strukturierten Programmieransätzen: Es gibt PROC, ENDPROC, LOCAL, GLOBAL – Begriffe, die aus anderen Sprachen vertraut sind und dort bestimmte Erwartungen wecken. Nur: Diese Erwartungen erfüllt TSB eben nicht.
Das muss man nicht schlimm finden - solange einem bewusst ist, worauf man sich einlässt. Wer mit diesen Einschränkungen leben kann oder sie gar als kreative Herausforderung sieht, dem möchte ich keinesfalls den Spaß daran nehmen. Ich versuche lediglich, xionum (oder anderen, die hier mitlesen) unverbindlich darauf hinzuweisen, dass TSB strukturell deutlich hinter dem bleibt, was die Begriffe suggerieren.
Und wenn man nach diesem Hinweis immer noch Freude daran hat, mit TSB zu programmieren - umso besser! Mir geht es nicht darum, irgendjemandem etwas auszureden, sondern nur darum, ein realistisches Bild davon zu vermitteln, was TSB ist - und was eben nicht. Gerade auf einem System mit so engen Grenzen wie dem C64 hilft es, wenn man keine falschen Erwartungen an die Werkzeuge hat.
Aber wie TD1334 und Lynx sagen, wir reden hier über den C64 mit kleinem Speicher.
Es gibt auf dem C64 durchaus richtige strukturierte Programmiersprachen.
Und ohne Plan geht es einfach nicht.
Klar, ein Plan kann sicher nicht schaden - aber ich muss zugeben: Ich gehe meistens ohne konkreten Plan an ein Projekt ran. Meistens notiere ich mir ein paar Stichworte auf einem Stück Klopapier (wenn’s gut läuft), und dann hoffe ich einfach auf eine glückliche Fügung.
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.
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.
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.
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.
Übrigens, wenn goloMAK keine Werbung für seine genialen Tools macht
Verräter! Zur Strafe programmiert nie wieder jemand etwas mit TSB. 
Hier ist eine in BASIC (deckt alle Eventualitäten ab): ...
Nein. Das entspricht in keinster Weise den Anforderungen.
Die Idee ist folgende.
PRINT BSC$(161)
=> druckt das Zeichen mit dem Bildschirmcode 161 auf den Bildschirm.
oder
PRINT BSC$(161,162,163)
=> gibt die drei Zeichen mit den Bildschirmcodes 161-163 hintereinander aus.
A$=BSC$(161,165,170)
=> weist der Variable A$ die drei Zeichen mit den angegebenen Bildschirmcodes zu.
Die ist vor allem ideal, um damit per MAP 2x2-Kacheln ausgeben zu können.
Ich will mal ganz ehrlich sein: Der Map-Befehl ist zwar nützlich aber auch äußerst speziell und schwierig zu verstehen. Ich glaube, es gibt nur eine Person, die damit umgehen kann.
So eine BSC$-Funktion, wie oben kurz angerissen, wäre schon deutlich nützlicher und massentauglicher. Und genau so eine Funktion hat in BASIC schon immer gefehlt.
xionum: Ich habe in Post#49 alles beschrieben, was man wissen muss. Zum Beispiel wie man den Groß/Kleinbuchstaben-Zeichensatz auf Diskette speichert. Und dann kannst du ihn in ZeichenEd bearbeiten. Und in deinem Programm kannst du ihn auch als Groß/Kleinbuchstaben-Zeichensatz wieder laden (das habe ich auch beschrieben).
Fazit: Der ZeichenEd bietet alles, was das Herz begehrt. Er stellt sozusagen die Quintessenz der Zeichensatzeditierung dar.
Und dann muss man noch bedenken: Wenn man mit TSB programmiert, dann sollte man auch Tools benutzen, die mit TSB programmiert worden sind. Alles andere wäre ein Stilbruch und auf der künstlerischen Ebene nicht vertretbar.
Alles anzeigen
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.
Zum Beispiel S-BASIC 65 für den MEGA65 kann das.
Nein. Das ist nicht wirklich das, was man braucht. Denn wir wissen ja: Es gibt nicht für jeden Bildschirmcode einen ASCII-Code.
Was man wirklich und wahrhaftig braucht, ist eine Funktion, der man den Bildschirmcode übergibt und die dann das entsprechende Zeichen zurückliefert. Dabei müssen alle 256 Zeichen berücksichtigt werden, auch die inversen.
Und ideal wäre es, wenn man der Funktion gleich mehrere Bildschirmcodes übergeben kann, damit man nicht PRINT BSC$(161)+BSC$(162)+BSC$(163) schreiben muss, sondern kurz und prägnant: PRINT BSC$(161,162,163).
Aber ich merke schon: Das wird hier nichts. Um so etwas zu realisieren, muss man nämlich äußerst klug und brillant sein. Und wer ist das schon? 
Da stimme ich dir zu, Omega .
Ich hab früher schon nicht verstanden warum das so ist.
Du willst PRINT BSC$(...), also eine Funktion, die dir aus einem Bildschirmcode direkt das passende Zeichen auf den Screen druckt - ganz wie CHR$, nur eben mit Bildschirmcodes?
Tja. So etwas gibt’s leider nicht.
Aber jetzt kommt der Trick: 
Frag einfach GoDot.
Natürlich solltest du das nicht einfach so direkt machen. Nein, nein.
Du musst schon ein bisschen die Kunst der subtilen Schmeichelei beherrschen:
Sag ihm, wie unfassbar geil TSB schon jetzt ist. Streu Sätze ein wie "Wenn das einer kann, dann du!" und "Das ist bestimmt nur ein Einzeiler für jemanden wie dich."
Und vergiss auf keinen Fall zu erwähnen, dass GoDot das coolste Bildbearbeitungsprogramm ist, das je für den C64 geschrieben wurde - mindestens!
Wenn du’s geschickt anstellst, hat er vielleicht schon beim zweiten Kompliment die Routine im Kopf und beim dritten beginnt er zu coden.
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.
Zu meinem Post Nr. #55 muss ich noch etwas loswerden. Meine Behauptung, dass sich der Bildschirmcode 161 zum ASCII-Code 225 übersetzt ist falsch. (Ich habe mich zur Strafe bereits ausgepeitscht.)
Folgendes muss ich dazu noch ergänzen:
Es gibt nicht für alle Bildschirmcodes eine Entsprechung als ASCII-Code. Die inversen Zeichen gibt es nicht als ASCII-Codes. Man muss sie mit den Steuerzeichen RVS-ON und RVS-OFF erzeugen.
Mit diesem Gedanken im Hinterkopf habe ich folgende erweiterte Routine erstellt um Bildschirmcodes in ASCII umzuwandeln. Es wird dann entweder ein ASCII-Zeichen oder drei ASCII-Zeichen ermittelt (drei weil ggf. noch RVSON und RVSOFF enthalten ist).
Also im Falle von deinem Bildschirmcode 161 ergeben sich in Wirklichkeit die folgenden drei ASCII-Codes:
Was du hier mir peek(display+1) ausliest, ist der Bildschirmcode. Und was du bei chr$() übergibst, ist der ASCII-Code.
Das sind zwei verschiedene Kodierungen.
Du müsstest den Bildschirmcode in ASCII-Code umrechnen, damit du das Zeichen mit chr$ printen kannst.
Dazu könntest du die zweite der folgenden beiden BASIC-Funktionen benutzen.
Wenn du z.B. die zweite Funktion mit
print fn ba(161) aufrufst, dann verrät dir die Funktion, dass der Bildschirmcocde 161 dem ASCII-Code 225 entspricht.
Omega gibt es die Möglichkeit im ZeichenEd den Zeichsatz umzuschalten? Ich würde ungern nur mit Großbuchstaben arbeiten wollen.
Der ZeichenEd arbeitet immer mit 256 Zeichen, also Großbuchstaben und PETSCII. Ein Umschalten ist nicht möglich.
Du kannst aber in deinem Programm festlegen, ob dieser Zeichensatz als Großbuchstaben/PETSCII oder als Groß/Kleinbuchstaben geladen wird.
Das machst du in TSB mit folgendem Code:
Mit $e0 legst du fest, dass der Zeichensatz als Großbuchstaben/PETSCII geladen werden soll.
Die 8 gibt die Anzahl der zu ladenden Pages an (1 Page = 256 Byte). Ein Zeichensatz ist 2KB groß (=8 Pages).
Wenn du statt $e0 => $e8 verwendest, dann wird der Zeichensatz als Groß/Kleinbuchstaben in dein Programm geladen.
dn$ ist der Dateiname. Der Rest ist immer gleich.
Wenn du dir eine Kopie der Groß/Kleinbuchstaben aus dem Speicher ziehen möchtest (zur Bearbeitung in ZeichenEd), dann kannst du das in TSB mit folgendem Code machen:
Die Parameter sind die gleichen wie beim Laden.
Achtung: Hier darfst du nicht das ",p,w" hinter dem Dateinamen vergessen. Das ist beim Speichern zwingend erforderlich.
Aber jetzt ist wirklich Pause bis Montag, auch wenn es mir schwer fällt.
Tja, mein Lieber. So geht das eben nicht! Wenn man mit TSB entwickelt, kann man nicht einfach an Sonn- und Feiertagen Pause machen. Da wird jeden Tag programmiert von 04:00 Uhr morgens bis 03:00 nachts bis das Spiel fertig ist.
So, goloMAK , jetzt mach du auch deine Werbung!
Also, wenn ich der Entwickler von TSB wäre, würde ich mich doppelt freuen, wenn jemand zwei vollständige Editoren komplett in TSB geschrieben hat - und diese auch noch öffentlich empfiehlt. Gerade weil es nicht viele Tools gibt, die auf dieser Basis entstehen, wäre das doch die perfekte Gelegenheit gewesen, TSB mal ins Rampenlicht zu stellen.
Wenn wir stattdessen auf andere Projekte verweisen, die mit TSB gar nichts zu tun haben... na ja - dann besteht die Gefahr, dass irgendwann selbst der letzte TSB-Entwickler leise das Boot verlässt und irgendwo anders hinpaddelt.
